> 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.
That's too bad, thanks for re-ran it.
> In addition, the same test without the VM does not show the
On 20 Jun 2019, at 23:58, William Tu wrote:
On Thu, Jun 20, 2019 at 1:26 AM Eelco Chaudron
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,
On Thu, Jun 20, 2019 at 1:26 AM Eelco Chaudron 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,
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
>> cookie=0x0,
> 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
> cookie=0x0, duration=8.504s, table=0, n_packets=1, n_bytes=252,
>
On 19.06.2019 9:35, Eelco Chaudron wrote:
>
>
> On 19 Jun 2019, at 0:28, William Tu wrote:
>
>>>
>>> I guess, this crash caused by trying to destroy unallocated queue.
>>>
>>> Following change could help:
>>> ---
>>> diff --git a/lib/netdev-afxdp.c b/lib/netdev-afxdp.c
>>> index
On 19 Jun 2019, at 0:31, 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
cookie=0x0, duration=8.504s,
On 19 Jun 2019, at 0:28, William Tu wrote:
I guess, this crash caused by trying to destroy unallocated queue.
Following change could help:
---
diff --git a/lib/netdev-afxdp.c b/lib/netdev-afxdp.c
index a6543e8f5..6e1431dce 100644
--- a/lib/netdev-afxdp.c
+++ b/lib/netdev-afxdp.c
@@ -249,7
> 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
> cookie=0x0, duration=8.504s, table=0, n_packets=1, n_bytes=252,
>
>
> I guess, this crash caused by trying to destroy unallocated queue.
>
> Following change could help:
> ---
> diff --git a/lib/netdev-afxdp.c b/lib/netdev-afxdp.c
> index a6543e8f5..6e1431dce 100644
> --- a/lib/netdev-afxdp.c
> +++ b/lib/netdev-afxdp.c
> @@ -249,7 +249,7 @@
>
> I’m using an RHEL7 instance and use systemd to restart openvswitch
> with “systemctl restart openvswitch”.
> It uses ovs-ctl to stat/stop, see here for some details:
>
> https://github.com/openvswitch/ovs/blob/master/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in
>
>
Thanks Eelco,
I can
On 18 Jun 2019, at 12:17, Ilya Maximets wrote:
On 18.06.2019 12:45, Eelco Chaudron wrote:
On 17 Jun 2019, at 22:32, William Tu wrote:
1000,463875,419996,402010
However I can not restart OVS (see other email on how I restart),
even if I clear the XDP programs before a restart it
On 18.06.2019 12:45, Eelco Chaudron wrote:
>
>
> On 17 Jun 2019, at 22:32, William Tu wrote:
>
>> On Mon, Jun 17, 2019 at 11:23 AM William Tu wrote:
>>>
>>> Hi Eelco,
>>>
>>> On Mon, Jun 17, 2019 at 3:12 AM Eelco Chaudron wrote:
Hi William,
See below parts of an offline
On 17 Jun 2019, at 22:32, William Tu wrote:
On Mon, Jun 17, 2019 at 11:23 AM William Tu
wrote:
Hi Eelco,
On Mon, Jun 17, 2019 at 3:12 AM Eelco Chaudron
wrote:
Hi William,
See below parts of an offline email discussion I had with Magnus
before,
and some research I did in the end,
On 17 Jun 2019, at 20:23, William Tu wrote:
Hi Eelco,
On Mon, Jun 17, 2019 at 3:12 AM Eelco Chaudron
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
On Mon, Jun 17, 2019 at 11:23 AM William Tu wrote:
>
> Hi Eelco,
>
> On Mon, Jun 17, 2019 at 3:12 AM Eelco Chaudron 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
Hi Eelco,
On Mon, Jun 17, 2019 at 3:12 AM Eelco Chaudron 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
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.
Hope this helps change your design…
In addition, the Point to Point test is working with you
Hi Eelco,
I think it's either a bug in kernel or my misunderstanding about how to
process the xsk cq ring. I posted the issue here
https://marc.info/?l=xdp-newbies=156055471727857=2
And apply this to v11 fix my crash.
Do you mind testing it again on your system?
Thanks for your time for trial
On 13 Jun 2019, at 2:37, William Tu wrote:
Hi Eelco,
#0 0x7fbc6a78193f in raise () from /lib64/libc.so.6
#1 0x7fbc6a76bc95 in abort () from /lib64/libc.so.6
#2 0x004ed1a1 in __umem_elem_push_n
(addrs=0x7fbc40f2ec50,
n=32, umemp=0x24cc790) at lib/xdpsock.c:32
#3
Hi Eelco,
> > >>> #0 0x7fbc6a78193f in raise () from /lib64/libc.so.6
> > >>> #1 0x7fbc6a76bc95 in abort () from /lib64/libc.so.6
> > >>> #2 0x004ed1a1 in __umem_elem_push_n (addrs=0x7fbc40f2ec50,
> > >>> n=32, umemp=0x24cc790) at lib/xdpsock.c:32
> > >>> #3 umem_elem_push_n
On Wed, Jun 12, 2019 at 1:56 AM Eelco Chaudron wrote:
>
> Hi William,
>
> I’m using 64 bytes generated by a Xena sending 10G wire speed.
> My ingress and egress port are the same ixgbe nic.
>
> I tried skb-mode, and as you mention it’s much slower (4x) and does
> not trigger the issue…
>
> I also
Hi William,
I’m using 64 bytes generated by a Xena sending 10G wire speed.
My ingress and egress port are the same ixgbe nic.
I tried skb-mode, and as you mention it’s much slower (4x) and does
not trigger the issue…
I also tried the v8 patch again on this setup and it’s NOT crashing in
On Tue, Jun 11, 2019 at 08:47:19AM +0200, Eelco Chaudron wrote:
>
>
> On 8 Jun 2019, at 6:48, William Tu wrote:
>
> > > > > + ethtool -L enp2s0 combined 1
> > > > > + ovs-vsctl set Open_vSwitch . other_config:pmd-cpu-mask=0x10
> > > > > + ovs-vsctl add-port br0 enp2s0 -- set interface enp2s0
On 8 Jun 2019, at 6:48, William Tu wrote:
+ ethtool -L enp2s0 combined 1
+ ovs-vsctl set Open_vSwitch . other_config:pmd-cpu-mask=0x10
+ ovs-vsctl add-port br0 enp2s0 -- set interface enp2s0
type="afxdp"
\
+options:n_rxq=1 options:xdpmode=drv \
+
Hi William,
This was still a draft email, and was not supposed to go out ;)
My debug and build setup was a bit messed up and was having problems
running GDB… I was (I’m) planning to continue getting some debug
info on Tuesday after the public holiday here…
But just to give you a heads up,
> > > + ethtool -L enp2s0 combined 1
> > > + ovs-vsctl set Open_vSwitch . other_config:pmd-cpu-mask=0x10
> > > + ovs-vsctl add-port br0 enp2s0 -- set interface enp2s0 type="afxdp"
> > > \
> > > +options:n_rxq=1 options:xdpmode=drv \
> > > +other_config:pmd-rxq-affinity="0:4"
another
Hi Eelco,
Thanks for the testing.
On Fri, Jun 7, 2019 at 8:43 AM Eelco Chaudron wrote:
>
> Hi William,
>
> No review or full test yet, just some observations…
>
> We run OVS as a non root user, which is causing OVS with XDP to fail:
Right, XDP requires using root privilege.
I will add this in
Hi William,
No review or full test yet, just some observations…
We run OVS as a non root user, which is causing OVS with XDP to fail:
2019-06-07T09:14:20.628Z|00023|ofproto_dpif|INFO|netdev@ovs-netdev:
Datapath supports ct_orig_tuple
29 matches
Mail list logo
