[ovs-dev] [PATCHv11] netdev-afxdp: add new netdev type for AF_XDP.

[Eelco Chaudron]

On 20 Jun 2019, at 23:58, William Tu wrote:

> On Thu, Jun 20, 2019 at 1:26 AM Eelco Chaudron <echaudro at redhat.com> 
> wrote:
>>
>>
>>
>> On 20 Jun 2019, at 4:15, William Tu wrote:
>>
>>>> The PVP test seems to work fine however after a while it stops
>>>> forwarding:
>>>>
>>>> $ ovs-ofctl dump-flows ovs_pvp_br0
>>>>   cookie=0x0, duration=8.510s, table=0, n_packets=1, n_bytes=1020,
>>>> in_port=eno1 actions=output:tapVM
>
> So this means for the physical nic, there is no packet received.
> I can reproduce similar issue using trex imix traffic.
>
> I think it's an issue in the ixgbe driver. If you keep sending
> traffic, then it's ok.
> But if you run af_xdp, stop, and run it again. The ixgbe driver report
>
> # dmesg
> [272206.755287] ixgbe 0000:0d:00.0 eth3: initiating reset to clear Tx
> work after link loss
> [272206.820872] ixgbe 0000:0d:00.0 eth3: Reset adapter
> [272207.484969] ixgbe 0000:0d:00.1 eth5: initiating reset to clear Tx
> work after link loss
> [272207.588880] ixgbe 0000:0d:00.1 eth5: Reset adapter
>
> # ip link show // the device is DOWN
> 94: eth3: <NO-CARRIER,BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 xdp
> qdisc mq state DOWN mode DEFAULT group default qlen 1000
>
> So at the traffic generator side, trex detects link down and stops
> sending traffic.
> When restart OVS which clears the AF_XDP/XDP program, the link is up 
> again,
> and the trex resumes sending traffic.

The PVP script will not restart OVS, or reapply the config, or bring 
down the link between the tests.

Just to be sure, I re-ran it, and checked the logging, but nothing of 
the above.
In addition, the same test without the VM does not show the problem.

I think it’s the packets being forwarded to the VM and as it takes 
time before they are released os causing some lockup. I’ll try to 
figure out more details next week when testing your v13.

Cheers,

Eelco