On 2019/5/15 下午11:23, Stephen Hemminger wrote:
On Wed, 15 May 2019 16:12:42 +0800
Jason Wang <jasow...@redhat.com> wrote:
On 2019/5/15 下午4:03, Stephen Hemminger wrote:
XDP generic does not work correctly with the Hyper-V/Azure netvsc
device because of packet processing order. Only packets on the
synthetic path get seen by the XDP program. The VF device packets
are not seen.
By the time the packets that arrive on the VF are handled by
netvsc after the first pass of XDP generic (on the VF) has already
been done.
A fix for the netvsc device is to do this in the VF packet handler.
by directly calling do_xdp_generic() if XDP program is present
on the parent device.
A riskier but maybe better alternative would be to do this netdev core
code after the receive handler is invoked (if RX_HANDLER_ANOTHER
is returned).
Something like what I propose at
https://lore.kernel.org/patchwork/patch/973819/ ?
It belongs to a series that try to make XDP (both native and generic)
work for stacked device. But for some reason (probably performance), the
maintainer seems not like the idea.
Maybe it's time to reconsider that?
Thanks
I like your generic solution but it introduces a change in semantics.
Netvsc always changes device when returning a ANOTHER but do all devices?
If some other stacked device did this then there a chance that using
XDP on that device would see same packet twice.
Good point. Can we simply add a check and call XDP only if dev is
changed in this case?
Thanks
