netdev - Re: ndo_xdp_xmit - on which queue to transmit the packet (if core_id >= total_xdp

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <8736h9yqyg.fsf@toke.dk>
Date:   Fri, 06 Sep 2019 23:56:07 +0100
From:   Toke Høiland-Jørgensen <toke@...hat.com>
To:     Manish Chopra <manishc@...vell.com>,
        "netdev\@vger.kernel.org" <netdev@...r.kernel.org>
Subject: Re: ndo_xdp_xmit - on which queue to transmit the packet (if core_id >= total_xdp_queues ) ?

Manish Chopra <manishc@...vell.com> writes:

> Hello,
>
> I am working on XDP_REDIRECT implementation and got a query. Some of
> the ethernet drivers decide the xdp queue index on which xdp packet
> should be redirected based on smp_processor_id() in their
> ndo_xdp_xmit() handler, if smp_processor_id() >= total_num_xdp_queues,
> they decide to drop the packets and return error from the handler.

Congratulations, you've hit upon one of the major usability issues with
XDP_REDIRECT! ;)

> I am hitting the same condition where using 8 XDP queues, I get CPU id
> 8 to redirect the XDP packet and I am not sure if it should be dropped
> or can be transmitted on a queue (= smp_processor_id() %
> total_num_xdp_queues) safely ?.

I would expect you would at least need some kind of locking to do this
safely, but I guess it depends on how your driver is structured...

> freescale/dpaa2 seems to be handling this case by sending the packet
> on the queue (= smp_processor_id() % total_num_xdp_queues) but unsure
> what should be the expected behavior.

As you've noted, this varies somewhat between drivers, and there's
really no "expected behaviour" today. Drivers basically do what they
think makes sense for their hardware.

We're trying to fix this, and make the behaviour configurable; if you
happen to be at LPC, please come discuss it with us at this session:

https://linuxplumbersconf.org/event/4/contributions/462/

-Toke