Re: [PATCH v2 net 2/2] net: core: generic XDP support for stacked device

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 2019/5/20 下午11:53, Stephen Hemminger wrote:
On Mon, 20 May 2019 11:11:05 +0200
Jiri Pirko <jiri@xxxxxxxxxxx> wrote:

Sun, May 19, 2019 at 05:10:46AM CEST, stephen@xxxxxxxxxxxxxxxxxx wrote:
When a device is stacked like (team, bonding, failsafe or netvsc) the
XDP generic program for the parent device is not called.  In these
cases, the rx handler changes skb->dev to its own in the receive
handler, and returns RX_HANDLER_ANOTHER.  Fix this by calling
do_xdp_generic if necessary before starting another round.

Review of all the places RX_HANDLER_ANOTHER is returned
show that the current devices do correctly change skb->dev.

There was an older patch that got abandoned that did the
same thing, this is just a rewrite.

Suggested-by: Jason Wang <jasowang@xxxxxxxxxx>
Fixes: d445516966dc ("net: xdp: support xdp generic on virtual devices")
Signed-off-by: Stephen Hemminger <sthemmin@xxxxxxxxxxxxx>
Acked-by: Jason Wang <jasowang@xxxxxxxxxx>
---
I'm always scarred of changes like this. The history tells us that this
codepaths are very fragile. It took us non-trivial efford to fix bonding
here, not to mention vlans (that was pain).

The reason for troubles was often fact that different flows were treated
differently (vlan accel/non-accel).
Yes, this is a sensitive path. Another alternative is to fix it
inside each device (netvsc). That is what my earlier patch did and that
is what is being done now (probably will make it into the RHEL on Azure
drivers).
This patch calls do_xdp_generic for master device in different point in
the receive patch comparing to lower device. Would it be possible to
unify this? E.g. by moving do_xdp_generice() call from
netif_rx_internal()/netif_receive_skb_internal() here,
to the beginning of __netif_receive_skb_core()?

That could work, but has the question about doing XDP farther down
call stack (lower performance).

There is also the case what if both paths support XDP in driver.
This would be the ideal case, how would this work?



I think we have a clear request of allowing native XDP to work on stacked device. We're missing some generic building blocks (like XDP rx handler) here.

Thanks





[Index of Archives]     [Linux Networking Development]     [Fedora Linux Users]     [Linux SCTP]     [DCCP]     [Gimp]     [Yosemite Campsites]

  Powered by Linux