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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 12 May 2020 06:22:20 +0200 From: Jürgen Groß <jgross@...e.com> To: Denis Kirjanov <kda@...ux-powerpc.org>, paul@....org Cc: netdev@...r.kernel.org, brouer@...hat.com, wei.liu@...nel.org, ilias.apalodimas@...aro.org Subject: Re: [PATCH net-next v9 1/2] xen networking: add basic XDP support for xen-netfront On 11.05.20 19:27, Denis Kirjanov wrote: > On 5/11/20, Jürgen Groß <jgross@...e.com> wrote: >> On 11.05.20 12:22, Denis Kirjanov wrote: >>> The patch adds a basic XDP processing to xen-netfront driver. >>> >>> We ran an XDP program for an RX response received from netback >>> driver. Also we request xen-netback to adjust data offset for >>> bpf_xdp_adjust_head() header space for custom headers. >>> >>> synchronization between frontend and backend parts is done >>> by using xenbus state switching: >>> Reconfiguring -> Reconfigured- > Connected >>> >>> UDP packets drop rate using xdp program is around 310 kpps >>> using ./pktgen_sample04_many_flows.sh and 160 kpps without the patch. >> >> I'm still not seeing proper synchronization between frontend and >> backend when an XDP program is activated. >> >> Consider the following: >> >> 1. XDP program is not active, so RX responses have no XDP headroom >> 2. netback has pushed one (or more) RX responses to the ring page >> 3. XDP program is being activated -> Reconfiguring >> 4. netback acknowledges, will add XDP headroom for following RX >> responses >> 5. netfront reads RX response (2.) without XDP headroom from ring page >> 6. boom! > > One thing that could be easily done is to set the offset on xen-netback side > in xenvif_rx_data_slot(). Are you okay with that? How does this help in above case? I think you haven't understood the problem I'm seeing. There can be many RX responses in the ring page which haven't been consumed by the frontend yet. You are doing the switch to XDP via a different communication channel (Xenstore), so you need some way to synchronize both communication channels. Either you make sure you have read all RX responses before doing the switch (this requires stopping netback to push out more RX responses), or you need to have a flag in the RX responses indicating whether XDP headroom is provided or not (requires an addition to the Xen netif protocol). Or I'm completely wrong and this can not happen due to the way XDP programs work, but you didn't provide any clear statement this being the case. Juergen
Powered by blists - more mailing lists