Re: [PATCH v7 bpf-next 0/6] xsk: build skb by page (aka generic zerocopy xmit)
On Wed, 17 Feb 2021 22:08:55 -0800 John Fastabend wrote: > > Performance Testing > > > > The test environment is Aliyun ECS server. > > Test cmd: > > ``` > > xdpsock -i eth0 -t -S -s > > ``` > > > > Test result data: > > > > size64 512 10241500 > > copy1916747 1775988 1600203 1440054 > > page1974058 1953655 1945463 1904478 > > percent 3.0%10.0% 21.58% 32.3% > > > > For the series, but might be good to get Dave or Jakub to check > 2/6 to be sure they agree. Not sure if Dave would consider holding this series just because of this, but I'm not a huge fan. I think moving towards a bitfield would be a better direction an all these flags and defines. This series is not the place for such effort, so perhaps drop patch 2, leave it be and follow up with a conversion to a bitfield?
RE: [PATCH v7 bpf-next 0/6] xsk: build skb by page (aka generic zerocopy xmit)
Alexander Lobakin wrote: > This series introduces XSK generic zerocopy xmit by adding XSK umem > pages as skb frags instead of copying data to linear space. > The only requirement for this for drivers is to be able to xmit skbs > with skb_headlen(skb) == 0, i.e. all data including hard headers > starts from frag 0. > To indicate whether a particular driver supports this, a new netdev > priv flag, IFF_TX_SKB_NO_LINEAR, is added (and declared in virtio_net > as it's already capable of doing it). So consider implementing this > in your drivers to greatly speed-up generic XSK xmit. [...] > Performance Testing > > The test environment is Aliyun ECS server. > Test cmd: > ``` > xdpsock -i eth0 -t -S -s > ``` > > Test result data: > > size64 512 10241500 > copy1916747 1775988 1600203 1440054 > page1974058 1953655 1945463 1904478 > percent 3.0%10.0% 21.58% 32.3% > For the series, but might be good to get Dave or Jakub to check 2/6 to be sure they agree. Acked-by: John Fastabend