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
