On Mon, Jun 17, 2019 at 11:23 AM William Tu <u9012...@gmail.com> wrote: > > Hi Eelco, > > On Mon, Jun 17, 2019 at 3:12 AM Eelco Chaudron <echau...@redhat.com> wrote: > > > > Hi William, > > > > See below parts of an offline email discussion I had with Magnus before, > > and some research I did in the end, which explains that by design you > > might not get all the descriptors ready. > > I think it's different issues. The behavior you described is a hickup waiting > for queuing 16 rx packets. Here, at the afxdp_complete_tx, the > xsk_ring_cons__peek > returns descs that already been released, causing ovs push more elems and thus > crash. > > > Hope this helps change your design… > > > > In addition, the Point to Point test is working with you change, > > however, the PVP test is still failing due to buffer starvation (see my > > comments in Patchv8 for a possible cause). > > > Thanks, looking back v8 > https://patchwork.ozlabs.org/patch/1097740/ > Hopefully next version will fix this issue. > > > Also on OVS restart system crashes in the following part: > > > > #0 netdev_afxdp_rxq_recv (rxq_=0x173c080, batch=0x7fe1397f80d0, > > qfill=0x0) at lib/netdev-afxdp.c:583 > > #1 0x0000000000907f21 in netdev_rxq_recv (rx=<optimized out>, > > batch=batch@entry=0x7fe1397f80d0, qfill=<optimized out>) at > > lib/netdev.c:710 > > #2 0x00000000008dd1c3 in dp_netdev_process_rxq_port > > (pmd=pmd@entry=0x175d990, rxq=0x175a460, port_no=2) at > > lib/dpif-netdev.c:4257 > > #3 0x00000000008dd63d in pmd_thread_main (f_=<optimized out>) at > > lib/dpif-netdev.c:5449 > > #4 0x000000000095e94d in ovsthread_wrapper (aux_=<optimized out>) at > > lib/ovs-thread.c:352 > > #5 0x00007fe1633872de in start_thread () from /lib64/libpthread.so.0 > > #6 0x00007fe162b2ca63 in clone () from /lib64/libc.so.6 > > > How do you restart the system? So I have two afxdp port > Port "eth3" > Interface "eth3" > type: afxdp > options: {n_rxq="1", xdpmode=drv} > Port "eth5" > Interface "eth5" > type: afxdp > options: {n_rxq="1", xdpmode=drv} > > I tested using > # ovs-vsctl del-port eth3 > # ovs-vsctl del-port eth5 > # ovs-vsctl del-br br0 > # ovs-appctl -t ovs-vswitchd exit > Looks ok. > > <snip> > > > > This means, that if you rely on (the naive :-)) code in the sample > > > application, you can endup in a situation where you can receive from > > > the > > > Rx ring, but not post to the fill ring. > > > > > > So, the reason for the 16 packet hickup is as following: > > > > > > 1. Userland: The fill ring is completely filled. > > > 2. Kernel: One packet is received, one entry picked from the fill > > > ring, > > > but the consumer pointer is not bumped, and packet is placed on the > > > Rx ring. > > > 3. Userland: One packet is picked from the Rx ring. > > > 4. Userland: Tries to put an entry on fill ring. The fill ring is > > > full, > > > so userland spins. > > > 5. Kernel: When 16 packets has been picked from the fill ring the > > > consumer ptr is released. > > > 6. Userland: Exists the while loop. > > Based on the above, there is no starvation problem here if there are more > than 16 packets, correct? And at step 4, we can skip spinning and try to > process more rx ring. > > For next version, I will first check the fill ring by using > xsk_prod_nb_free(), > to avoid the step 4. > > Thanks > William
Hi Eelco, I have some fixes with commit "prepare for v12" at https://github.com/williamtu/ovs-ebpf/commits/afxdp-v11 I tested PVP and it works ok (using tap and also veth namespaces) Can you give it a try? Thanks a lot William _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
