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.
