Re: [PATCH net-next v3 7/7] net: lan966x: Add support for XDP_REDIRECT

[Horatiu Vultur]

The 11/22/2022 13:04, Alexander Lobakin wrote:
> 
> From: Horatiu Vultur <horatiu.vultur@xxxxxxxxxxxxx>
> Date: Mon, 21 Nov 2022 22:28:50 +0100
> 
> > Extend lan966x XDP support with the action XDP_REDIRECT. This is similar
> > with the XDP_TX, so a lot of functionality can be reused.
> >
> > Signed-off-by: Horatiu Vultur <horatiu.vultur@xxxxxxxxxxxxx>
> > ---
> >  .../ethernet/microchip/lan966x/lan966x_fdma.c | 83 +++++++++++++++----
> >  .../ethernet/microchip/lan966x/lan966x_main.c |  1 +
> >  .../ethernet/microchip/lan966x/lan966x_main.h | 10 ++-
> >  .../ethernet/microchip/lan966x/lan966x_xdp.c  | 31 ++++++-
> >  4 files changed, 109 insertions(+), 16 deletions(-)
> 
> [...]
> 
> > @@ -558,6 +575,10 @@ static int lan966x_fdma_napi_poll(struct napi_struct *napi, int weight)
> >               case FDMA_TX:
> >                       lan966x_fdma_rx_advance_dcb(rx);
> >                       continue;
> > +             case FDMA_REDIRECT:
> > +                     lan966x_fdma_rx_advance_dcb(rx);
> > +                     redirect = true;
> > +                     continue;
> 
> I think you can save a couple lines here and avoid small code dup:
> 
> +               case FDMA_REDIRECT:
> +                       redirect = true;
> +                       fallthrough;
>                 case FDMA_TX:
>                         lan966x_fdma_rx_advance_dcb(rx);
>                         continue;

I will save only a line but I will add this change in the next version
as I like it more than what I wrote.

> 
> The logics stays the same.
> 
> >               case FDMA_DROP:
> >                       lan966x_fdma_rx_free_page(rx);
> >                       lan966x_fdma_rx_advance_dcb(rx);
> 
> [...]
> 
> > @@ -178,6 +180,7 @@ struct lan966x_tx_dcb_buf {
> >       struct net_device *dev;
> >       struct sk_buff *skb;
> >       struct xdp_frame *xdpf;
> > +     bool xdp_ndo;
> 
> I suggest carefully inspecting this struct with pahole (or by just
> printkaying its layout/sizes/offsets at runtime) and see if there's
> any holes and how it could be optimized.
> Also, it's just my personal preference, but it's not that unpopular:
> I don't trust bools inside structures as they may surprise with
> their sizes or alignment depending on the architercture. Considering
> all the blah I wrote, I'd define it as:
> 
> struct lan966x_tx_dcb_buf {
>         dma_addr_t dma_addr;            // can be 8 bytes on 32-bit plat
>         struct net_device *dev;         // ensure natural alignment
>         struct sk_buff *skb;
>         struct xdp_frame *xdpf;
>         u32 len;
>         u32 xdp_ndo:1;                  // put all your booleans here in
>         u32 used:1;                     // one u32
>         ...
> };

Thanks for the suggestion. I make sure not that this struct will not
have any holes.
Can it be a rule of thumb, that every time when a new member is added to
a struct, to make sure that it doesn't introduce any holes?

> 
> BTW, we usually do union { skb, xdpf } since they're mutually
> exclusive. And to distinguish between XDP and regular Tx you can use
> one more bit/bool. This can also come handy later when you add XSk
> support (you will be adding it, right? Please :P).

I think I will take this battle at later point when I will add XSK :)
After I finish with this patch series, I will need to focus on some VCAP
support for lan966x.
And maybe after that I will be able to add XSK. Because I need to look
more at this XSK topic as I have looked too much on it before but I heard
a lot of great things about it :)

> 
> >       int len;
> >       dma_addr_t dma_addr;
> >       bool used;
> 
> [...]
> 
> > --
> > 2.38.0
> 
> Thanks,
> Olek

-- 
/Horatiu