Re: [ovs-discuss] Drop in performance for conntrack cases with OVS

[Darrell Ball]

added back the alias

Darrell

On Thu, Jan 16, 2020 at 8:00 PM Darrell Ball  wrote:

> Thanks for the report Anju
>
> Extensive testing was done without tunnels (both PVP and P2P; flows
> 2-100k).
> Threads and queues were also varied.  The testing is about a year old now
> however
> and there were some minor conntrack changes after that, which I would not
> have expected to have a big impact;
> well, at least till now.
>
> This report is interesting however.
>
> 1/ What kind of user traffic - UDP ?
>
> 2/ What about threads and queues ?
>
> Thanks Darrell
>
> On Wed, Jan 15, 2020 at 10:59 PM Anju Thomas via discuss <
> ovs-discuss@openvswitch.org> wrote:
>
>> Hi,
>>
>>
>>
>> We are moving to latest OVS viz OVS 2.12 (Earlier we were on 2.8) . We
>> noticed a significant drop in performance for flows with conntrack (40-50%
>> drop in Traffic going over Vxlan ) . On further analysis , we could pin
>> this drop in performance to the below commit
>>
>>
>>
>> commit 967bb5c5cd9070112138d74a2f4394c50ae48420
>>
>> Author: Darrell Ball 
>>
>> Date:   Thu May 9 08:15:07 2019 -0700
>>
>>
>>
>> conntrack: Add rcu support.
>>
>> For performance and code simplification reasons, add rcu support for
>>
>> conntrack. The array of hmaps is replaced by a cmap as part of this
>>
>> conversion.  Using a single map also simplifies the handling of NAT
>>
>> and allows the removal of the nat_conn map and friends.  Per
>> connection
>>
>> entry locks are introduced, which are needed in a few code paths.
>>
>>
>>
>>
>>
>>
>>
>> Has anyone noticed this and if so is there any way to get around this as
>> well (We don’t use NAT connections)?
>>
>>
>>
>> Is there a specific case where this could give better performance ?
>>
>>
>>
>> Regards
>>
>> Anju
>>
>>
>> ___
>> discuss mailing list
>> disc...@openvswitch.org
>> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>>
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Re：Re： [HELP] Question about icmp pkt marked Invalid by userspace conntrack

[Darrell Ball]

Hi Timo

On Wed, Nov 13, 2019 at 1:00 AM txfh2007  wrote:

> Hi Darrell:
> I have set burst size 2 times of rate（e.g. if rate is 1Gbps, then
> burst is 2Gbps）. and have tried different rate value. the result is as
> below:
> meter rate/iperf test result:   1G / 800M
> meter rate/iperf test result:   500M / 420M
> meter rate/iperf test result:   200M / 172M
> meter rate/iperf test result:   100M / 95M
> meter rate/iperf test result:50M / 45M
> meter rate/iperf test result:10M / 9M
> It seems if rate is lower, the test result is more accurate, but for
> rate above 200M , the actual rate limit result is not as expected.
>

Can you try this patch to see the effect on precision ?

diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index 4720ba1..01c0280 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -5633,6 +5633,7 @@ dp_netdev_run_meter(struct dp_netdev *dp, struct
dp_packet_batch *packets_,
 }

 meter_lock(dp, meter_id);
+now = time_usec();
 meter = dp->meters[meter_id];
 if (!meter) {
 goto out;

Thanks Darrell



>
> Thanks
> Timo
>
>
> ：Re: [ovs-discuss] Re：Re： [HELP] Question about icmp pkt marked Invalid by
> userspace conntrack
>
>
> Hi Timo
>
>
>
> On Sun, Nov 10, 2019 at 11:58 PM txfh2007  wrote:
>
> Hi Darrell:
>
> I have tried to manual set flow table and meter action, to arrange
> meter action at the end of the flow pipeline(just before the output
> action), and delete conntrack related actions. But the iperf result is also
> around 800Mbps(meter rate is 1Gbps as below).
> Should I print any message to verify that userspace meter works as
> expected ?
>
> ovs-ofctl dump-meters br-int -O openflow13
> OFPST_METER_CONFIG reply (OF1.3) (xid=0x2):
> meter=1 kbps burst stats bands=
> type=drop rate=100 burst_size=120
>
>  ovs-appctl dpif/dump-flows br-int
> recirc_id(0),in_port(5),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(frag=no),
> packets:570308, bytes:817648729, used:0.191s, flags:SP., actions:meter(0),3
> recirc_id(0),in_port(3),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(frag=no),
> packets:291956, bytes:19551792, used:0.191s, flags:SP., actions:5
>
>
> Just to recap here:
>
>
> The test is sending b/w 2 VMs attached to the same host.
>
>
>
> Now you are rechecking the base case of the test by removing the conntrack
> rules and are applying a meter rule in one direction only.
> However, the same problem is observed where 0.8 Gbps is seen vs 1 Gbps
> meter setting
> Without meter, you can get 5 Gbps.
>
>
> 1/ To investigate, try explicitly setting the burst size high to take
> burstiness out as a factor.
> 2/ Also try other meter rates which might help see where the issue is.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --
>
> ：txfh2007 
> ：Ben Pfaff ; ovs-discuss 
> ：Re: [ovs-discuss] Re：Re： [HELP] Question about icmp pkt marked Invalid by
> userspace conntrack
>
>
> Hi Timo
>
> On Wed, Nov 6, 2019 at 9:37 PM txfh2007  wrote:
>
> Hi Darrell:
> Sorry, I forgot to tell you the attached flow is based on VM tx
> direction rate limit. So the datapath action order is conntrack -> meter ->
> forward decision -> output, For the  VM rx direction rate limit, the
> datapath flow is as below, please help to check, thank you!
>
>
> For both directions, I think you want to apply the flow meter at the end
> of the pipeline.
> Can you do that and then check the numbers again.
>
>Also, for the same flow table and meter configuration, the kernel
> datapath rate limit is more accurate than userspace datapath.
> For VM rx direction rate limit:
>
>
> ct_state(-new+est-rel-rpl-inv+trk),ct_label(0/0x1),recirc_id(0x29),in_port(5),packet_type(ns=0,id=0),eth(src=fa:16:3e:33:02:d8,dst=fa:16:3e:12:d7:77),eth_type(0x0800),ipv4(dst=
> 192.168.1.10/255.255.255.248,proto=6,frag=no),tcp_flags(ack),
> packets:1031455, bytes:1481163900, used:0.149s, flags:.,
> actions:ct(zone=4),recirc(0x2a)
>
> ct_state(-new+est-rel-rpl-inv+trk),ct_label(0/0x1),recirc_id(0x2a),in_port(5),packet_type(ns=0,id=0),eth(src=fa:16:3e:33:02:d8,dst=fa:16:3e:12:d7:77),eth_type(0x0800),ipv4(src=192.168.1.8,dst=192.168.1.10,proto=6,frag=no),
> packets:1685180, bytes:2415638857, used:0.118s, flags:P., actions:meter(1),6
>
>
>
>
>
>
>
>
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Re：Re： [HELP] Question about icmp pkt marked Invalid by userspace conntrack

[Darrell Ball]

Hi Timo


On Sun, Nov 10, 2019 at 11:58 PM txfh2007  wrote:

> Hi Darrell:
>
> I have tried to manual set flow table and meter action, to arrange
> meter action at the end of the flow pipeline(just before the output
> action), and delete conntrack related actions. But the iperf result is also
> around 800Mbps(meter rate is 1Gbps as below).
> Should I print any message to verify that userspace meter works as
> expected ?
>
> ovs-ofctl dump-meters br-int -O openflow13
> OFPST_METER_CONFIG reply (OF1.3) (xid=0x2):
> meter=1 kbps burst stats bands=
> type=drop rate=100 burst_size=120
>
>  ovs-appctl dpif/dump-flows br-int
> recirc_id(0),in_port(5),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(frag=no),
> packets:570308, bytes:817648729, used:0.191s, flags:SP., actions:meter(0),3
> recirc_id(0),in_port(3),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(frag=no),
> packets:291956, bytes:19551792, used:0.191s, flags:SP., actions:5
>

Just to recap here:

The test is sending b/w 2 VMs attached to the same host.

Now you are rechecking the base case of the test by removing the conntrack
rules and are applying a meter rule in one direction only.
However, the same problem is observed where 0.8 Gbps is seen vs 1 Gbps
meter setting
Without meter, you can get 5 Gbps.

1/ To investigate, try explicitly setting the burst size high to take
burstiness out as a factor.
2/ Also try other meter rates which might help see where the issue is.









>
> --
>
> ：txfh2007 
> ：Ben Pfaff ; ovs-discuss 
> ：Re: [ovs-discuss] Re：Re： [HELP] Question about icmp pkt marked Invalid by
> userspace conntrack
>
>
> Hi Timo
>
> On Wed, Nov 6, 2019 at 9:37 PM txfh2007  wrote:
>
> Hi Darrell:
> Sorry, I forgot to tell you the attached flow is based on VM tx
> direction rate limit. So the datapath action order is conntrack -> meter ->
> forward decision -> output, For the  VM rx direction rate limit, the
> datapath flow is as below, please help to check, thank you!
>
>
> For both directions, I think you want to apply the flow meter at the end
> of the pipeline.
> Can you do that and then check the numbers again.
>
>Also, for the same flow table and meter configuration, the kernel
> datapath rate limit is more accurate than userspace datapath.
> For VM rx direction rate limit:
>
>
> ct_state(-new+est-rel-rpl-inv+trk),ct_label(0/0x1),recirc_id(0x29),in_port(5),packet_type(ns=0,id=0),eth(src=fa:16:3e:33:02:d8,dst=fa:16:3e:12:d7:77),eth_type(0x0800),ipv4(dst=
> 192.168.1.10/255.255.255.248,proto=6,frag=no),tcp_flags(ack),
> packets:1031455, bytes:1481163900, used:0.149s, flags:.,
> actions:ct(zone=4),recirc(0x2a)
>
> ct_state(-new+est-rel-rpl-inv+trk),ct_label(0/0x1),recirc_id(0x2a),in_port(5),packet_type(ns=0,id=0),eth(src=fa:16:3e:33:02:d8,dst=fa:16:3e:12:d7:77),eth_type(0x0800),ipv4(src=192.168.1.8,dst=192.168.1.10,proto=6,frag=no),
> packets:1685180, bytes:2415638857, used:0.118s, flags:P., actions:meter(1),6
>
>
>
>
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Re：Re： [HELP] Question about icmp pkt marked Invalid by userspace conntrack

[Darrell Ball]

Hi Timo

On Wed, Nov 6, 2019 at 9:37 PM txfh2007  wrote:

> Hi Darrell:
> Sorry, I forgot to tell you the attached flow is based on VM tx
> direction rate limit. So the datapath action order is conntrack -> meter ->
> forward decision -> output, For the  VM rx direction rate limit, the
> datapath flow is as below, please help to check, thank you!
>

For both directions, I think you want to apply the flow meter at the end of
the pipeline.
Can you do that and then check the numbers again.


>Also, for the same flow table and meter configuration, the kernel
> datapath rate limit is more accurate than userspace datapath.


> For VM rx direction rate limit:
>
>
> ct_state(-new+est-rel-rpl-inv+trk),ct_label(0/0x1),recirc_id(0x29),in_port(5),packet_type(ns=0,id=0),eth(src=fa:16:3e:33:02:d8,dst=fa:16:3e:12:d7:77),eth_type(0x0800),ipv4(dst=
> 192.168.1.10/255.255.255.248,proto=6,frag=no),tcp_flags(ack),
> packets:1031455, bytes:1481163900, used:0.149s, flags:.,
> actions:ct(zone=4),recirc(0x2a)
>
> ct_state(-new+est-rel-rpl-inv+trk),ct_label(0/0x1),recirc_id(0x2a),in_port(5),packet_type(ns=0,id=0),eth(src=fa:16:3e:33:02:d8,dst=fa:16:3e:12:d7:77),eth_type(0x0800),ipv4(src=192.168.1.8,dst=192.168.1.10,proto=6,frag=no),
> packets:1685180, bytes:2415638857, used:0.118s, flags:P., actions:meter(1),6
>
>
>
>
> --
> ：Re: [ovs-discuss] Re：Re： [HELP] Question about icmp pkt marked Invalid by
> userspace conntrack
>
>
> Hi Timo
>
> On Wed, Nov 6, 2019 at 2:06 AM txfh2007  wrote:
>
> Hi Darrell:
>
> the flow dump result is as below: Please help to check
> BEFORE:
>
>
> ct_state(-new+est-rel-rpl-inv+trk),ct_label(0/0x1),recirc_id(0x1b),in_port(6),packet_type(ns=0,id=0),eth(src=fa:16:3e:12:d7:77,dst=fa:16:3e:33:02:d8),eth_type(0x0800),ipv4(dst=
> 192.168.1.8/255.255.255.248,proto=6,frag=no),tcp_flags(psh|ack),
> packets:18934, bytes:2660, used:0.000s, flags:P.,
> actions:ct(zone=1),recirc(0x1c)
>
> ct_state(-new+est-rel-rpl-inv+trk),ct_label(0/0x1),recirc_id(0x1c),in_port(6),packet_type(ns=0,id=0),eth(src=fa:16:3e:12:d7:77,dst=fa:16:3e:33:02:d8),eth_type(0x0800),ipv4(src=192.168.1.10,dst=192.168.1.8,proto=6,frag=no),
> packets:5345996, bytes:7676256441, used:0.000s, flags:P., actions:5
>
> AFTER:
>
>
> ct_state(-new+est-rel-rpl-inv+trk),ct_label(0/0x1),recirc_id(0x19),in_port(6),packet_type(ns=0,id=0),eth(src=fa:16:3e:12:d7:77,dst=fa:16:3e:33:02:d8),eth_type(0x0800),ipv4(dst=
> 192.168.1.8/255.255.255.248,proto=6,frag=no),tcp_flags(ack),
> packets:2473174, bytes:3551472384, used:0.136s, flags:.,
> actions:meter(0),ct(zone=1),recirc(0x1a)
>
>
> meter is being applied by above rule and then the pipeline continues below
> to do another pass thru the datapath;
> this would likely explain the numbers
> Can you double check the Openflow rules and do the metering at output rule.
>
>
>
> ct_state(-new+est-rel-rpl-inv+trk),ct_label(0/0x1),recirc_id(0x1a),in_port(6),packet_type(ns=0,id=0),eth(src=fa:16:3e:12:d7:77,dst=fa:16:3e:33:02:d8),eth_type(0x0800),ipv4(src=192.168.1.10,dst=192.168.1.8,proto=6,frag=no),
> packets:5292889, bytes:7599875381, used:0.046s, flags:P., actions:5
>
>
>
> meter rate is 1Gbps, iperf result is around 800Mbps
>
> [  5]  95.00-96.00  sec   104 MBytes   869 Mbits/sec
> [  5]  96.00-97.00  sec  79.4 MBytes   666 Mbits/sec
> [  5]  97.00-98.00  sec   107 MBytes   896 Mbits/sec
> [  5]  98.00-99.00  sec  75.4 MBytes   632 Mbits/sec
> [  5]  99.00-100.00 sec  98.3 MBytes   824 Mbits/sec
> [  5] 100.00-100.04 sec  0.00 Bytes  0.00 bits/sec
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval   Transfer Bandwidth
> [  5]   0.00-100.04 sec  0.00 Bytes  0.00 bits/sec  sender
> [  5]   0.00-100.04 sec  9.29 GBytes   798 Mbits/sec
> receiver
>
>
>
> --
> ：Darrell Ball 
> ：2019年11月6日(星期三) 02:46
> ：txfh2007 
> ：Ben Pfaff ; ovs-discuss 
> ：Re: [ovs-discuss] Re：Re： [HELP] Question about icmp pkt marked Invalid by
> userspace conntrack
>
>
> Hi Timo
>
> On Mon, Nov 4, 2019 at 11:29 PM txfh2007  wrote:
>
> Hi Darrell:
> The meter rate limit is set as 1Gbps, but the actual rate is around
> 500Mbps.. I have read the meter patch, but this patch is to prevent delta_t
> changed to 0. But in my case, the delta_t is around 35500ms.
>
>
> It might be good to just include all known related fixes anyways,
> including this other one
>
>
>
> https://github.com/openvswitch/ovs/commit/acc5df0e3cb036524d49891fdb9ba89b609dd26a
>
>
>
>
> For my case, the meter action is on openflow table 46, and the ct action
> is on t

Re: [ovs-discuss] Re：Re： [HELP] Question about icmp pkt marked Invalid by userspace conntrack

[Darrell Ball]

Hi Timo

On Wed, Nov 6, 2019 at 2:06 AM txfh2007  wrote:

> Hi Darrell:
>
> the flow dump result is as below: Please help to check
> BEFORE:
>
>
> ct_state(-new+est-rel-rpl-inv+trk),ct_label(0/0x1),recirc_id(0x1b),in_port(6),packet_type(ns=0,id=0),eth(src=fa:16:3e:12:d7:77,dst=fa:16:3e:33:02:d8),eth_type(0x0800),ipv4(dst=
> 192.168.1.8/255.255.255.248,proto=6,frag=no),tcp_flags(psh|ack),
> packets:18934, bytes:2660, used:0.000s, flags:P.,
> actions:ct(zone=1),recirc(0x1c)
>
> ct_state(-new+est-rel-rpl-inv+trk),ct_label(0/0x1),recirc_id(0x1c),in_port(6),packet_type(ns=0,id=0),eth(src=fa:16:3e:12:d7:77,dst=fa:16:3e:33:02:d8),eth_type(0x0800),ipv4(src=192.168.1.10,dst=192.168.1.8,proto=6,frag=no),
> packets:5345996, bytes:7676256441, used:0.000s, flags:P., actions:5
>
> AFTER:
>
>
> ct_state(-new+est-rel-rpl-inv+trk),ct_label(0/0x1),recirc_id(0x19),in_port(6),packet_type(ns=0,id=0),eth(src=fa:16:3e:12:d7:77,dst=fa:16:3e:33:02:d8),eth_type(0x0800),ipv4(dst=
> 192.168.1.8/255.255.255.248,proto=6,frag=no),tcp_flags(ack),
> packets:2473174, bytes:3551472384, used:0.136s, flags:.,
> actions:meter(0),ct(zone=1),recirc(0x1a)
>

meter is being applied by above rule and then the pipeline continues below
to do another pass thru the datapath;
this would likely explain the numbers
Can you double check the Openflow rules and do the metering at output rule.



> ct_state(-new+est-rel-rpl-inv+trk),ct_label(0/0x1),recirc_id(0x1a),in_port(6),packet_type(ns=0,id=0),eth(src=fa:16:3e:12:d7:77,dst=fa:16:3e:33:02:d8),eth_type(0x0800),ipv4(src=192.168.1.10,dst=192.168.1.8,proto=6,frag=no),
> packets:5292889, bytes:7599875381, used:0.046s, flags:P., actions:5
>
>
>
> meter rate is 1Gbps, iperf result is around 800Mbps
>
> [  5]  95.00-96.00  sec   104 MBytes   869 Mbits/sec
> [  5]  96.00-97.00  sec  79.4 MBytes   666 Mbits/sec
> [  5]  97.00-98.00  sec   107 MBytes   896 Mbits/sec
> [  5]  98.00-99.00  sec  75.4 MBytes   632 Mbits/sec
> [  5]  99.00-100.00 sec  98.3 MBytes   824 Mbits/sec
> [  5] 100.00-100.04 sec  0.00 Bytes  0.00 bits/sec
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval   Transfer Bandwidth
> [  5]   0.00-100.04 sec  0.00 Bytes  0.00 bits/sec  sender
> [  5]   0.00-100.04 sec  9.29 GBytes   798 Mbits/sec
> receiver
>
>
>
> --
> ：Darrell Ball 
> ：2019年11月6日(星期三) 02:46
> ：txfh2007 
> ：Ben Pfaff ; ovs-discuss 
> ：Re: [ovs-discuss] Re：Re： [HELP] Question about icmp pkt marked Invalid by
> userspace conntrack
>
>
> Hi Timo
>
> On Mon, Nov 4, 2019 at 11:29 PM txfh2007  wrote:
>
> Hi Darrell:
> The meter rate limit is set as 1Gbps, but the actual rate is around
> 500Mbps.. I have read the meter patch, but this patch is to prevent delta_t
> changed to 0. But in my case, the delta_t is around 35500ms.
>
>
> It might be good to just include all known related fixes anyways,
> including this other one
>
>
>
> https://github.com/openvswitch/ovs/commit/acc5df0e3cb036524d49891fdb9ba89b609dd26a
>
>
>
>
> For my case, the meter action is on openflow table 46, and the ct action
> is on table 44, the output action is on table 65, so I guess the order is
> right?
>
>
> Could you dump the 'relevant' datapath flows before adding the meter rule
> and after adding the meter rule ?
> ovs-appctl dpif/dump-flows 
>
>
>
> Thanks
>
> Timo
>
>
>
> --
> ：Darrell Ball 
> ：2019年11月5日(星期二) 06:56
> ：txfh2007 
> ：Ben Pfaff ; ovs-discuss 
> ：Re: [ovs-discuss] Re：Re： [HELP] Question about icmp pkt marked Invalid by
> userspace conntrack
>
>
> Hi Timo
>
> On Sun, Nov 3, 2019 at 5:12 PM txfh2007  wrote:
>
> Hi Darrell:
> Sorry for my late reply. Yes, the two VMs under test are on same
> compute node , and pkts rx/tx via vhost user type port.
>
> Got it
>
>
> Firstly if I don't configure meter table, then Iperf TCP bandwidth result
> From VM1 to VM2 is around 5Gbps, then I set the meter entry and constraint
> the rate, and the deviation is larger than I throught.
>
>
> IIUC, pre-meter, you get 5 Gbps, then post-meter 0.5 Gpbs, which is less
> than you expected ?
> What did you expect the metered rate to be ?
> Note Ben pointed you to a meter related bug fix on the alias b4.
>
> I guess the recalculation of l4 checksum during conntrack would impact
> the actual rate?
>
>
> are you applying the meter rule at end of the complete pipeline ?
>
>
> Thank you
> Timo
>
>
>
>
> txfh2007 
> Ben Pfaff ; ovs-discuss 
> Re: [ovs-discuss] Re：Re： [HELP] Question about

Re: [ovs-discuss] Re：Re： [HELP] Question about icmp pkt marked Invalid by userspace conntrack

[Darrell Ball]

Hi Timo

On Mon, Nov 4, 2019 at 11:29 PM txfh2007  wrote:

> Hi Darrell:
> The meter rate limit is set as 1Gbps, but the actual rate is around
> 500Mbps.. I have read the meter patch, but this patch is to prevent delta_t
> changed to 0. But in my case, the delta_t is around 35500ms.
>

It might be good to just include all known related fixes anyways, including
this other one

https://github.com/openvswitch/ovs/commit/acc5df0e3cb036524d49891fdb9ba89b609dd26a



> For my case, the meter action is on openflow table 46, and the ct action
> is on table 44, the output action is on table 65, so I guess the order is
> right?
>

Could you dump the 'relevant' datapath flows before adding the meter rule
and after adding the meter rule ?
ovs-appctl dpif/dump-flows 


>
> Thanks
>
> Timo
>
>
>
> ----------
> ：Darrell Ball 
> ：2019年11月5日(星期二) 06:56
> ：txfh2007 
> ：Ben Pfaff ; ovs-discuss 
> ：Re: [ovs-discuss] Re：Re： [HELP] Question about icmp pkt marked Invalid by
> userspace conntrack
>
>
> Hi Timo
>
> On Sun, Nov 3, 2019 at 5:12 PM txfh2007  wrote:
>
> Hi Darrell:
> Sorry for my late reply. Yes, the two VMs under test are on same
> compute node , and pkts rx/tx via vhost user type port.
>
> Got it
>
>
> Firstly if I don't configure meter table, then Iperf TCP bandwidth result
> From VM1 to VM2 is around 5Gbps, then I set the meter entry and constraint
> the rate, and the deviation is larger than I throught.
>
>
> IIUC, pre-meter, you get 5 Gbps, then post-meter 0.5 Gpbs, which is less
> than you expected ?
> What did you expect the metered rate to be ?
> Note Ben pointed you to a meter related bug fix on the alias b4.
>
> I guess the recalculation of l4 checksum during conntrack would impact
> the actual rate?
>
>
> are you applying the meter rule at end of the complete pipeline ?
>
>
> Thank you
> Timo
>
>
>
>
> txfh2007 
> Ben Pfaff ; ovs-discuss 
> Re: [ovs-discuss] Re：Re： [HELP] Question about icmp pkt marked Invalid by
> userspace conntrack
>
>
> Hi Timo
>
>
> I read thru this thread to get more context on what you are doing; you
> have a base OVS-DPDK
> use case and are measuring VM to VM performance across 2 compute nodes.
> You are probably using
> vhost-user-client ports ? Pls correct me if I am wrong.
> In this case, "per direction" you have one rx virtual interface to handle
> in OVS; there will be a tradeoff b/w
> checksum validation security and performance.
> JTBC, in terms of your measurements, how did you arrive at the 5Gbps -
> instrumented code or otherwise ?.
> (I can verify that later when I have a setup).
>
>
> Darrell
>
>
>
>
>
>
>
>
>
>
> On Thu, Oct 31, 2019 at 9:23 AM Darrell Ball  wrote:
>
>
>
>
> On Thu, Oct 31, 2019 at 3:04 AM txfh2007 via discuss <
> ovs-discuss@openvswitch.org> wrote:
>
> Hi Ben && Darrell：
>  This patch works, but after merging this patch I have found the iperf
> throughout decrease from 5Gbps+ to 500Mbps.
>
> what is the 5Gbps number ? Is that the number with marking all packets as
> invalid in initial sanity checks ?
>
>
> Typically one wants to offload checksum checks. The code checks whether
> that has been done and skips
> doing it in software; can you verify that you have the capability and are
> using it ?
>
>
> Skipping checksum checks reduces security, of course, but it can be added
> if there is a common case of
> not being able to offload checksumming.
>
>
>
>  I guess maybe we should add a switch to turn off layer4 checksum
> validation when doing userspace conntrack ? I have found for kernel
> conntrack, there is a related button named "nf_conntrack_checksum"  .
>
> Any advice?
>
> Thank you !
>
> --
>
> ：Ben Pfaff 
> ：ovs-discuss 
> ：Re：Re：[ovs-discuss] [HELP] Question about icmp pkt marked Invalid by
> userspace conntrack
>
>
> Hi Ben && Darrell：
>  Thanks, this patch works! Now the issue seems fixed
>
> Timo
>
>
> Re: Re：[ovs-discuss] [HELP] Question about icmp pkt marked Invalid by
> userspace conntrack
>
>
> I see.
>
> It sounds like Darrell pointed out the solution, but please let me know
> if it did not help.
>
> On Fri, Oct 11, 2019 at 08:57:58AM +0800, txfh2007 wrote:
> > Hi Ben:
> >
> >  I just found the GCC_UNALIGNED_ACCESSORS error during gdb trace and
> not sure this is a misaligned error or others. What I can confirm is
> during "extract_l4" of this icmp reply packet, when we d

Re: [ovs-discuss] Re：Re： [HELP] Question about icmp pkt marked Invalid by userspace conntrack

[Darrell Ball]

Hi Timo

On Sun, Nov 3, 2019 at 5:12 PM txfh2007  wrote:

> Hi Darrell:
> Sorry for my late reply. Yes, the two VMs under test are on same
> compute node , and pkts rx/tx via vhost user type port.


Got it


> Firstly if I don't configure meter table, then Iperf TCP bandwidth result
> From VM1 to VM2 is around 5Gbps, then I set the meter entry and constraint
> the rate, and the deviation is larger than I throught.
>

IIUC, pre-meter, you get 5 Gbps, then post-meter 0.5 Gpbs, which is less
than you expected ?
What did you expect the metered rate to be ?
Note Ben pointed you to a meter related bug fix on the alias b4.


> I guess the recalculation of l4 checksum during conntrack would impact
> the actual rate?
>

are you applying the meter rule at end of the complete pipeline ?


>
> Thank you
> Timo
>
>
>
>
> txfh2007 
> Ben Pfaff ; ovs-discuss 
> Re: [ovs-discuss] Re：Re： [HELP] Question about icmp pkt marked Invalid by
> userspace conntrack
>
>
> Hi Timo
>
>
> I read thru this thread to get more context on what you are doing; you
> have a base OVS-DPDK
> use case and are measuring VM to VM performance across 2 compute nodes.
> You are probably using
> vhost-user-client ports ? Pls correct me if I am wrong.
> In this case, "per direction" you have one rx virtual interface to handle
> in OVS; there will be a tradeoff b/w
> checksum validation security and performance.
> JTBC, in terms of your measurements, how did you arrive at the 5Gbps -
> instrumented code or otherwise ?.
> (I can verify that later when I have a setup).
>
>
> Darrell
>
>
>
>
>
>
>
>
>
>
> On Thu, Oct 31, 2019 at 9:23 AM Darrell Ball  wrote:
>
>
>
>
> On Thu, Oct 31, 2019 at 3:04 AM txfh2007 via discuss <
> ovs-discuss@openvswitch.org> wrote:
>
> Hi Ben && Darrell：
>  This patch works, but after merging this patch I have found the iperf
> throughout decrease from 5Gbps+ to 500Mbps.
>
> what is the 5Gbps number ? Is that the number with marking all packets as
> invalid in initial sanity checks ?
>
>
> Typically one wants to offload checksum checks. The code checks whether
> that has been done and skips
> doing it in software; can you verify that you have the capability and are
> using it ?
>
>
> Skipping checksum checks reduces security, of course, but it can be added
> if there is a common case of
> not being able to offload checksumming.
>
>
>
>  I guess maybe we should add a switch to turn off layer4 checksum
> validation when doing userspace conntrack ? I have found for kernel
> conntrack, there is a related button named "nf_conntrack_checksum"  .
>
> Any advice?
>
> Thank you !
>
> --
>
> ：Ben Pfaff 
> ：ovs-discuss 
> ：Re：Re：[ovs-discuss] [HELP] Question about icmp pkt marked Invalid by
> userspace conntrack
>
>
> Hi Ben && Darrell：
>  Thanks, this patch works! Now the issue seems fixed
>
> Timo
>
>
> Re: Re：[ovs-discuss] [HELP] Question about icmp pkt marked Invalid by
> userspace conntrack
>
>
> I see.
>
> It sounds like Darrell pointed out the solution, but please let me know
> if it did not help.
>
> On Fri, Oct 11, 2019 at 08:57:58AM +0800, txfh2007 wrote:
> > Hi Ben:
> >
> >  I just found the GCC_UNALIGNED_ACCESSORS error during gdb trace and
> not sure this is a misaligned error or others. What I can confirm is
> during "extract_l4" of this icmp reply packet, when we do "check_l4_icmp",
> the unaligned error emits and the "extract_l4" returned false. So this
> packet be marked as ct_state=invalid.
> >
> > Thank you for your help.
> >
> > Timo
> >
> > Topic：Re: [ovs-discuss] [HELP] Question about icmp pkt marked Invalid by
> userspace conntrack
> >
> >
> > It's very surprising.
> >
> > Are you using a RISC architecture that insists on aligned accesses?  On
> > the other hand, if you are using x86-64 or some other architecture that
> > ordinarily does not care, are you sure that this is about a misaligned
> > access (it is more likely to simply be a bad pointer)?
> >
> > On Thu, Oct 10, 2019 at 10:50:33PM +0800, txfh2007 via discuss wrote:
> > >
> > > Hi all:
> > > I was using OVS-DPDK(version 2.10-1), and I have found pinging
> between two VMs on different compute nodes failed. I have checked my env
> and found there is one node's NIC cannot strip CRC of a frame, the other
> node's NIC is normal(I mean it can strip CRC ). And the reason of ping fail
> is the icmp reply pkt (from 

Re: [ovs-discuss] Re：Re： [HELP] Question about icmp pkt marked Invalid by userspace conntrack

[Darrell Ball]

Hi Timo

I read thru this thread to get more context on what you are doing; you have
a base OVS-DPDK
use case and are measuring VM to VM performance across 2 compute nodes. You
are probably using
vhost-user-client ports ? Pls correct me if I am wrong.
In this case, "per direction" you have one rx virtual interface to handle
in OVS; there will be a tradeoff b/w
checksum validation security and performance.
JTBC, in terms of your measurements, how did you arrive at the 5Gbps -
instrumented code or otherwise ?.
(I can verify that later when I have a setup).

Darrell






On Thu, Oct 31, 2019 at 9:23 AM Darrell Ball  wrote:

>
>
> On Thu, Oct 31, 2019 at 3:04 AM txfh2007 via discuss <
> ovs-discuss@openvswitch.org> wrote:
>
>> Hi Ben && Darrell：
>>  This patch works, but after merging this patch I have found the
>> iperf throughout decrease from 5Gbps+ to 500Mbps.
>
>
> what is the 5Gbps number ? Is that the number with marking all packets as
> invalid in initial sanity checks ?
>
> Typically one wants to offload checksum checks. The code checks
> whether that has been done and skips
> doing it in software; can you verify that you have the capability and are
> using it ?
>
> Skipping checksum checks reduces security, of course, but it can be added
> if there is a common case of
> not being able to offload checksumming.
>
>
>
>> I guess maybe we should add a switch to turn off layer4 checksum
>> validation when doing userspace conntrack ? I have found for kernel
>> conntrack, there is a related button named "nf_conntrack_checksum"  .
>>
>> Any advice?
>>
>> Thank you !
>>
>> --
>>
>> ：Ben Pfaff 
>> ：ovs-discuss 
>> ：Re：Re：[ovs-discuss] [HELP] Question about icmp pkt marked Invalid by
>> userspace conntrack
>>
>>
>> Hi Ben && Darrell：
>>  Thanks, this patch works! Now the issue seems fixed
>>
>> Timo
>>
>>
>> Re: Re：[ovs-discuss] [HELP] Question about icmp pkt marked Invalid by
>> userspace conntrack
>>
>>
>> I see.
>>
>> It sounds like Darrell pointed out the solution, but please let me know
>> if it did not help.
>>
>> On Fri, Oct 11, 2019 at 08:57:58AM +0800, txfh2007 wrote:
>> > Hi Ben:
>> >
>> >  I just found the GCC_UNALIGNED_ACCESSORS error during gdb trace
>> and not sure this is a misaligned error or others. What I can confirm is
>> during "extract_l4" of this icmp reply packet, when we do "check_l4_icmp",
>> the unaligned error emits and the "extract_l4" returned false. So this
>> packet be marked as ct_state=invalid.
>> >
>> > Thank you for your help.
>> >
>> > Timo
>> >
>> > Topic：Re: [ovs-discuss] [HELP] Question about icmp pkt marked Invalid
>> by userspace conntrack
>> >
>> >
>> > It's very surprising.
>> >
>> > Are you using a RISC architecture that insists on aligned accesses?  On
>> > the other hand, if you are using x86-64 or some other architecture that
>> > ordinarily does not care, are you sure that this is about a misaligned
>> > access (it is more likely to simply be a bad pointer)?
>> >
>> > On Thu, Oct 10, 2019 at 10:50:33PM +0800, txfh2007 via discuss wrote:
>> > >
>> > > Hi all:
>> > > I was using OVS-DPDK(version 2.10-1), and I have found pinging
>> between two VMs on different compute nodes failed. I have checked my env
>> and found there is one node's NIC cannot strip CRC of a frame, the other
>> node's NIC is normal(I mean it can strip CRC ). And the reason of ping fail
>> is the icmp reply pkt (from node whose NIC cannot strip CRC) is marked as
>> invalid . So the icmp request From Node A is 64 bytes， but the icmp reply
>> From Node B is 68 bytes(with 4 bytes CRC). And when doing "check_l4_icmp",
>> when we call csum task(in lib/csum.c). Gcc emits unaligned accessor error.
>> The backtrace is as below:
>> > >
>> > > I just want to confirm if this phenomenon is reasonable?
>> > >
>> > > Many thanks
>> > >
>> > > Timo
>> > >
>> > >
>> > > get_unaligned_be16 (p=0x7f2ad0b1ed5c) at lib/unaligned.h:89
>> > > 89 GCC_UNALIGNED_ACCESSORS(ovs_be16, be16);
>> > > (gdb) bt
>> > > #0  get_unaligned_be16 (p=0x7f2ad0b1ed5c) at lib/unaligned.h:89
>> > > #1  0x0075a584 in csum_continue (partial=0,
>> data_=0x7f2ad0b1e

Re: [ovs-discuss] Re：Re： [HELP] Question about icmp pkt marked Invalid by userspace conntrack

[Darrell Ball]

On Thu, Oct 31, 2019 at 3:04 AM txfh2007 via discuss <
ovs-discuss@openvswitch.org> wrote:

> Hi Ben && Darrell：
>  This patch works, but after merging this patch I have found the iperf
> throughout decrease from 5Gbps+ to 500Mbps.


what is the 5Gbps number ? Is that the number with marking all packets as
invalid in initial sanity checks ?

Typically one wants to offload checksum checks. The code checks
whether that has been done and skips
doing it in software; can you verify that you have the capability and are
using it ?

Skipping checksum checks reduces security, of course, but it can be added
if there is a common case of
not being able to offload checksumming.



> I guess maybe we should add a switch to turn off layer4 checksum
> validation when doing userspace conntrack ? I have found for kernel
> conntrack, there is a related button named "nf_conntrack_checksum"  .
>
> Any advice?
>
> Thank you !
>
> --
>
> ：Ben Pfaff 
> ：ovs-discuss 
> ：Re：Re：[ovs-discuss] [HELP] Question about icmp pkt marked Invalid by
> userspace conntrack
>
>
> Hi Ben && Darrell：
>  Thanks, this patch works! Now the issue seems fixed
>
> Timo
>
>
> Re: Re：[ovs-discuss] [HELP] Question about icmp pkt marked Invalid by
> userspace conntrack
>
>
> I see.
>
> It sounds like Darrell pointed out the solution, but please let me know
> if it did not help.
>
> On Fri, Oct 11, 2019 at 08:57:58AM +0800, txfh2007 wrote:
> > Hi Ben:
> >
> >  I just found the GCC_UNALIGNED_ACCESSORS error during gdb trace and
> not sure this is a misaligned error or others. What I can confirm is
> during "extract_l4" of this icmp reply packet, when we do "check_l4_icmp",
> the unaligned error emits and the "extract_l4" returned false. So this
> packet be marked as ct_state=invalid.
> >
> > Thank you for your help.
> >
> > Timo
> >
> > Topic：Re: [ovs-discuss] [HELP] Question about icmp pkt marked Invalid by
> userspace conntrack
> >
> >
> > It's very surprising.
> >
> > Are you using a RISC architecture that insists on aligned accesses?  On
> > the other hand, if you are using x86-64 or some other architecture that
> > ordinarily does not care, are you sure that this is about a misaligned
> > access (it is more likely to simply be a bad pointer)?
> >
> > On Thu, Oct 10, 2019 at 10:50:33PM +0800, txfh2007 via discuss wrote:
> > >
> > > Hi all:
> > > I was using OVS-DPDK(version 2.10-1), and I have found pinging
> between two VMs on different compute nodes failed. I have checked my env
> and found there is one node's NIC cannot strip CRC of a frame, the other
> node's NIC is normal(I mean it can strip CRC ). And the reason of ping fail
> is the icmp reply pkt (from node whose NIC cannot strip CRC) is marked as
> invalid . So the icmp request From Node A is 64 bytes， but the icmp reply
> From Node B is 68 bytes(with 4 bytes CRC). And when doing "check_l4_icmp",
> when we call csum task(in lib/csum.c). Gcc emits unaligned accessor error.
> The backtrace is as below:
> > >
> > > I just want to confirm if this phenomenon is reasonable?
> > >
> > > Many thanks
> > >
> > > Timo
> > >
> > >
> > > get_unaligned_be16 (p=0x7f2ad0b1ed5c) at lib/unaligned.h:89
> > > 89 GCC_UNALIGNED_ACCESSORS(ovs_be16, be16);
> > > (gdb) bt
> > > #0  get_unaligned_be16 (p=0x7f2ad0b1ed5c) at lib/unaligned.h:89
> > > #1  0x0075a584 in csum_continue (partial=0,
> data_=0x7f2ad0b1ed5c, n=68) at lib/csum.c:46
> > > #2  0x0075a552 in csum (data=0x7f2ad0b1ed5c, n=68) at
> lib/csum.c:33
> > > #3  0x008ddf18 in check_l4_icmp (data=0x7f2ad0b1ed5c, size=68,
> validate_checksum=true) at lib/conntrack.c:1638
> > > #4  0x008de650 in extract_l4 (key=0x7f32a20df120,
> data=0x7f2ad0b1ed5c, size=68, related=0x7f32a20df15d, l3=0x7f2ad0b1ed48,
> > > validate_checksum=true) at lib/conntrack.c:1888
> > > #5  0x008de90d in conn_key_extract (ct=0x7f32b42a2d98,
> pkt=0x7f2ad0b1e9c0, dl_type=8, ctx=0x7f32a20df120, zone=4)
> > > at lib/conntrack.c:1973
> > > #6  0x008dd49c in conntrack_execute (ct=0x7f32b42a2d98,
> pkt_batch=0x7f32a20e08b0, dl_type=8, force=false, commit=false,
> > > zone=4, setmark=0x0, setlabel=0x0, tp_src=0, tp_dst=0, helper=0x0,
> nat_action_info=0x0, now=5395897849) at lib/conntrack.c:1318
> > > #7  0x0076d651 in dp_execute_cb (aux_=0x7f32a20dfb00,
> packets_=0x7f32a20e08b0, a=0x7f32a20e0ac8, should_steal=false)
> > > at lib/dpif-netdev.c:6711
> > > #8  0x007b2d49 in odp_execute_actions (dp=0x7f32a20dfb00,
> batch=0x7f32a20e08b0, steal=true, actions=0x7f32a20e0ac8,
> > > actions_len=20, dp_execute_action=0x76ca60 ) at
> lib/odp-execute.c:726
> > > #9  0x0076d71b in dp_netdev_execute_actions
> (pmd=0x7f2a6e1ce010, packets=0x7f32a20e08b0, should_steal=true,
> > > flow=0x7f32a20dfb60, actions=0x7f32a20e0ac8, actions_len=20) at
> lib/dpif-netdev.c:6754
> > > #10 0x0076b900 in handle_packet_upcall 

Re: [ovs-discuss] Re：Re： [HELP] Question about icmp pkt marked Invalid by userspace conntrack

[Darrell Ball]

This is fixed via 9171c63532ee9cbc63bb8cfae364ab071f44389b
2.10.4/3/2 will have it

On Thu, Oct 10, 2019 at 6:56 PM txfh2007 via discuss <
ovs-discuss@openvswitch.org> wrote:

> Hi Ben:
> This is my tcpdump result and the userspace datapath cache flow:
>
>Note: the icmp reply got by ovs bridge should have 4 bytes CRC
>
> 09:42:40.883012 fa:16:3e:6c:07:83 > 00:00:0c:9f:f3:ae, ethertype IPv4
> (0x0800), length 98: (tos 0x0, ttl 63, id 7119, offset 0, flags [DF], proto
> ICMP (1), length 84)
> 192.168.1.7 > 10.142.174.254: ICMP echo request, id 2604, seq 116,
> length 64
> 0x:   0c9f f3ae fa16 3e6c 0783 0800 4500
> 0x0010:  0054 1bcf 4000 3f01 a49e c0a8 0107 0a8e
> 0x0020:  aefe 0800 40d1 0a2c 0074 0fde 9f5d 
> 0x0030:   3c80 0200   1011 1213 1415
> 0x0040:  1617 1819 1a1b 1c1d 1e1f 2021 2223 2425
> 0x0050:  2627 2829 2a2b 2c2d 2e2f 3031 3233 3435
> 0x0060:  3637
> 09:42:40.883683 fa:16:3e:0e:d1:15 > fa:16:3e:53:dd:68, ethertype IPv4
> (0x0800), length 102: (tos 0x0, ttl 254, id 7119, offset 0, flags [DF],
> proto ICMP (1), length 84)
> 10.142.174.254 > 192.168.1.7: ICMP echo reply, id 2604, seq 116,
> length 64
> 0x:  fa16 3e53 dd68 fa16 3e0e d115 0800 4500
> 0x0010:  0054 1bcf 4000 fe01 e59d 0a8e aefe c0a8
> 0x0020:  0107  48d1 0a2c 0074 0fde 9f5d 
> 0x0030:   3c80 0200   1011 1213 1415
> 0x0040:  1617 1819 1a1b 1c1d 1e1f 2021 2223 2425
> 0x0050:  2627 2829 2a2b 2c2d 2e2f 3031 3233 3435
> 0x0060:  3637 01a0 af78
>
>
> tunnel(tun_id=0x5,src=10.142.18.11,dst=10.142.18.12,geneve({class=0x102,type=0x80,len=4,0xd30003/0x7fff}),flags(-df+csum+key)),rec
> irc_id(0),in_port(15),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(proto=1,frag=no),icmp(type=0),
> packets:41, bytes:4182, used:0.380s,
>  actions:ct(zone=4),recirc(0x37)
>
>
> tunnel(tun_id=0x5,src=10.142.18.11,dst=10.142.18.12,geneve({}),flags(-df+csum+key)),ct_state(+inv+trk),recirc_id(0x37),in_port(15),pac
> ket_type(ns=0,id=0),eth_type(0x0800),ipv4(frag=no), packets:211,
> bytes:21522, used:0.342s, actions:drop
>
>
>
>
> Re: Re：[ovs-discuss] [HELP] Question about icmp pkt marked Invalid by
> userspace conntrack
>
>
> On October 10, 2019 5:57:58 PM PDT, txfh2007 
> wrote:Hi Ben:
>
>  I just found the GCC_UNALIGNED_ACCESSORS error during gdb trace and
> not sure this is a misaligned error or others. What I can confirm is
> during "extract_l4" of this icmp reply packet, when we do "check_l4_icmp",
> the unaligned error emits and the "extract_l4" returned false. So this
> packet be marked as ct_state=invalid.
>
> Thank you for your help.
>
> Timo
>
> Topic：Re: [ovs-discuss] [HELP] Question about icmp pkt marked Invalid by
> userspace conntrack
>
>
> It's very surprising.
>
> Are you using a RISC architecture that insists on aligned accesses?  On
> the other hand, if you are using x86-64 or some other architecture that
> ordinarily does not care, are you sure that this is about a misaligned
> access (it is more likely to simply be a bad pointer)?
>
> On Thu, Oct 10, 2019 at 10:50:33PM +0800, txfh2007 via discuss wrote:
> >
> Hi all:
> I was using OVS-DPDK(version 2.10-1), and I have found pinging between
> two VMs on different compute nodes failed. I have checked my env and found
> there is one node's NIC cannot strip CRC of a frame, the other node's NIC
> is normal(I mean it can strip CRC ). And the reason of ping fail is the
> icmp reply pkt (from node whose NIC cannot strip CRC) is marked as invalid
> . So the icmp request From Node A is 64 bytes， but the icmp reply From Node
> B is 68 bytes(with 4 bytes CRC). And when doing "check_l4_icmp", when we
> call csum task(in lib/csum.c). Gcc emits unaligned accessor error. The
> backtrace is as below:
>
> I just want to confirm if this phenomenon is reasonable?
>
> Many thanks
>
> Timo
>
>
> get_unaligned_be16 (p=0x7f2ad0b1ed5c) at lib/unaligned.h:89
> 89 GCC_UNALIGNED_ACCESSORS(ovs_be16, be16);
> (gdb) bt
> #0  get_unaligned_be16 (p=0x7f2ad0b1ed5c) at lib/unaligned.h:89
> #1  0x0075a584 in csum_continue (partial=0, data_=0x7f2ad0b1ed5c,
> n=68) at lib/csum.c:46
> #2  0x0075a552 in csum (data=0x7f2ad0b1ed5c, n=68) at lib/csum.c:33
> #3  0x008ddf18 in check_l4_icmp (data=0x7f2ad0b1ed5c, size=68,
> validate_checksum=true) at lib/conntrack.c:1638
> #4  0x008de650 in extract_l4 (key=0x7f32a20df120,
> data=0x7f2ad0b1ed5c, size=68, related=0x7f32a20df15d, l3=0x7f2ad0b1ed48,
> validate_checksum=true) at lib/conntrack.c:1888
> #5  0x008de90d in conn_key_extract (ct=0x7f32b42a2d98,
> pkt=0x7f2ad0b1e9c0, dl_type=8, ctx=0x7f32a20df120, zone=4)
> at lib/conntrack.c:1973
> #6  0x008dd49c in conntrack_execute (ct=0x7f32b42a2d98,
> pkt_batch=0x7f32a20e08b0, dl_type=8, force=false, commit=false,
> zone=4, setmark=0x0, setlabel=0x0, tp_src=0, tp_dst=0, helper=0x0,
> 

[ovs-discuss] Fwd: FW: [HELP] Question about icmp pkt marked Invalid by userspace conntrack

[Darrell Ball]

1/ Pls provide a hexdump capture of the request and corresponding reply
packets.

2/ Also, I would check 2.10.4 or latest 2.10.


On 10/10/19, 7:51 AM, "ovs-discuss-boun...@openvswitch.org on behalf of
txfh2007 via discuss"  wrote:


Hi all:
I was using OVS-DPDK(version 2.10-1), and I have found pinging
between two VMs on different compute nodes failed. I have checked my env
and found there is one node's NIC cannot strip CRC of a frame, the other
node's NIC is normal(I mean it can strip CRC ). And the reason of ping fail
is the icmp reply pkt (from node whose NIC cannot strip CRC) is marked as
invalid . So the icmp request From Node A is 64 bytes， but the icmp reply
>From Node B is 68 bytes(with 4 bytes CRC). And when doing "check_l4_icmp",
when we call csum task(in lib/csum.c). Gcc emits unaligned accessor error.
The backtrace is as below:

I just want to confirm if this phenomenon is reasonable?

Many thanks

Timo


get_unaligned_be16 (p=0x7f2ad0b1ed5c) at lib/unaligned.h:89
89  GCC_UNALIGNED_ACCESSORS(ovs_be16, be16);
(gdb) bt
#0  get_unaligned_be16 (p=0x7f2ad0b1ed5c) at lib/unaligned.h:89
#1  0x0075a584 in csum_continue (partial=0,
data_=0x7f2ad0b1ed5c, n=68) at lib/csum.c:46
#2  0x0075a552 in csum (data=0x7f2ad0b1ed5c, n=68) at
lib/csum.c:33
#3  0x008ddf18 in check_l4_icmp (data=0x7f2ad0b1ed5c, size=68,
validate_checksum=true) at lib/conntrack.c:1638
#4  0x008de650 in extract_l4 (key=0x7f32a20df120,
data=0x7f2ad0b1ed5c, size=68, related=0x7f32a20df15d, l3=0x7f2ad0b1ed48,
validate_checksum=true) at lib/conntrack.c:1888
#5  0x008de90d in conn_key_extract (ct=0x7f32b42a2d98,
pkt=0x7f2ad0b1e9c0, dl_type=8, ctx=0x7f32a20df120, zone=4)
at lib/conntrack.c:1973
#6  0x008dd49c in conntrack_execute (ct=0x7f32b42a2d98,
pkt_batch=0x7f32a20e08b0, dl_type=8, force=false, commit=false,
zone=4, setmark=0x0, setlabel=0x0, tp_src=0, tp_dst=0, helper=0x0,
nat_action_info=0x0, now=5395897849) at lib/conntrack.c:1318
#7  0x0076d651 in dp_execute_cb (aux_=0x7f32a20dfb00,
packets_=0x7f32a20e08b0, a=0x7f32a20e0ac8, should_steal=false)
at lib/dpif-netdev.c:6711
#8  0x007b2d49 in odp_execute_actions (dp=0x7f32a20dfb00,
batch=0x7f32a20e08b0, steal=true, actions=0x7f32a20e0ac8,
actions_len=20, dp_execute_action=0x76ca60 ) at
lib/odp-execute.c:726
#9  0x0076d71b in dp_netdev_execute_actions
(pmd=0x7f2a6e1ce010, packets=0x7f32a20e08b0, should_steal=true,
flow=0x7f32a20dfb60, actions=0x7f32a20e0ac8, actions_len=20) at
lib/dpif-netdev.c:6754
#10 0x0076b900 in handle_packet_upcall (pmd=0x7f2a6e1ce010,
packet=0x7f2ad0b1e9c0, key=0x7f32a20e1100,
actions=0x7f32a20e0a40, put_actions=0x7f32a20e0a80) at
lib/dpif-netdev.c:6056
#11 0x0076bdf0 in fast_path_processing (pmd=0x7f2a6e1ce010,
packets_=0x7f32a20e2b60, keys=0x7f32a20e10c0,
batches=0x7f32a20e0f90, n_batches=0x7f32a20e13c0, in_port=15) at
lib/dpif-netdev.c:6153
#12 0x0076c3df in dp_netdev_input__ (pmd=0x7f2a6e1ce010,
packets=0x7f32a20e2b60, md_is_valid=true, port_no=0)
at lib/dpif-netdev.c:6230
#13 0x0076c4d4 in dp_netdev_recirculate (pmd=0x7f2a6e1ce010,
packets=0x7f32a20e2b60) at lib/dpif-netdev.c:6265
#14 0x0076ceae in dp_execute_cb (aux_=0x7f32a20e1db0,
packets_=0x7f32a20e2b60, a=0x7f32a20e2d78, should_steal=true)


___
discuss mailing list
disc...@openvswitch.org

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openvswitch.org%2Fmailman%2Flistinfo%2Fovs-discussdata=02%7C01%7Cdball%40vmware.com%7Ca4f3c8a6ba5e4a010cc208d74d915931%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637063158979473315sdata=Iy09aVT10BlMDf%2FeEEJbDPAGlL%2BthPhK7p0kKxmUdc4%3Dreserved=0
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] FW: OVS 2.9.0 native firewall drops empty payload TCP packets continued

[Darrell Ball]

Thanks for reconfirming Jing

Darrell

On Fri, May 3, 2019 at 3:02 PM Zhang, Jing C. (Nokia - CA/Ottawa) <
jing.c.zh...@nokia.com> wrote:

> The thing is, I don’t see empty TCP packet drops on DPDK computes, I
> nevertheless applied the patch HAN mentioned on DPDK computes, no
> difference.
>
>
>
> The issues we see is on OVS computes.
>
>
>
> Jing
>
>
>
> *From:* Darrell Ball 
> *Sent:* Friday, May 03, 2019 3:34 PM
> *To:* Zhang, Jing C. (Nokia - CA/Ottawa) 
> *Cc:* Han Zhou ; ovs-discuss@openvswitch.org
> *Subject:* Re: FW: [ovs-discuss] OVS 2.9.0 native firewall drops empty
> payload TCP packets continued
>
>
>
>
>
>
>
> On Fri, May 3, 2019 at 10:44 AM Zhang, Jing C. (Nokia - CA/Ottawa) <
> jing.c.zh...@nokia.com> wrote:
>
>
>1. The hybrid firewall refers to Linux bridge based firewall. To debug
>the issue, we switch the neutron OVS agent to use native firewall.
>
>
>
> [securitygroup]
>
> #firewall_driver=iptables_hybrid
>
> firewall_driver=openvswitch
>
>
>
> # ovs-ofctl dump-flows br-int | grep ct_state
>
> cookie=0xddb977285e2ba9b6, duration=185.322s, table=71, n_packets=0,
> n_bytes=0, idle_age=185, priority=110,ct_state=+trk
> actions=ct_clear,resubmit(,71)
>
> cookie=0xddb977285e2ba9b6, duration=182.170s, table=72, n_packets=0,
> n_bytes=0, idle_age=184, priority=75,ct_state=+est-rel-rpl,icmp,reg5=0x1
> actions=resubmit(,73)
>
> cookie=0xddb977285e2ba9b6, duration=182.170s, table=72, n_packets=204,
> n_bytes=16642, idle_age=18, priority=77,ct_state=+est-rel-rpl,udp,reg5=0x1
> actions=resubmit(,73)
>
> cookie=0xddb977285e2ba9b6, duration=182.170s, table=72, n_packets=0,
> n_bytes=0, idle_age=184, priority=77,ct_state=+est-rel-rpl,tcp,reg5=0x1
> actions=resubmit(,73)
>
> cookie=0xddb977285e2ba9b6, duration=182.170s, table=72, n_packets=0,
> n_bytes=0, idle_age=184, priority=75,ct_state=+new-est,icmp,reg5=0x1
> actions=resubmit(,73)
>
> cookie=0xddb977285e2ba9b6, duration=182.170s, table=72, n_packets=204,
> n_bytes=16642, idle_age=18, priority=77,ct_state=+new-est,udp,reg5=0x1
> actions=resubmit(,73)
>
> cookie=0xddb977285e2ba9b6, duration=182.170s, table=72, n_packets=0,
> n_bytes=0, idle_age=184, priority=77,ct_state=+new-est,tcp,reg5=0x1
> actions=resubmit(,73)
>
> cookie=0xddb977285e2ba9b6, duration=182.170s, table=72, n_packets=0,
> n_bytes=0, idle_age=184, priority=74,ct_state=+est-rel-rpl,ipv6,reg5=0x1
> actions=resubmit(,73)
>
> cookie=0xddb977285e2ba9b6, duration=182.170s, table=72, n_packets=0,
> n_bytes=0, idle_age=184, priority=74,ct_state=+est-rel-rpl,ip,reg5=0x1
> actions=resubmit(,73)
>
> cookie=0xddb977285e2ba9b6, duration=182.170s, table=72, n_packets=0,
> n_bytes=0, idle_age=184, priority=74,ct_state=+new-est,ipv6,reg5=0x1
> actions=resubmit(,73)
>
> cookie=0xddb977285e2ba9b6, duration=182.170s, table=72, n_packets=0,
> n_bytes=0, idle_age=184, priority=74,ct_state=+new-est,ip,reg5=0x1
> actions=resubmit(,73)
>
>
>
> My understanding is Centos 7 packs the OVS tree, that how conntrack is
> supported before kernel 4.3.
>
>
>
> https://cbs.centos.org/koji/buildinfo?buildID=24381
>
>
>
> I assumed you are using Linux tree OVS kernel module
>
>
>
>
>
>
>
>
>
>1. I back-ported the patch pointed by Han to OVS v2.9.0, it does not
>solve the packet drop on the OVS compute.
>
>
>
> Thanks for confirming
>
> We don't know your full topology, but if you want to send packets
> following a path that goes thru an OVS userspace datapath then
>
> that patch would be applicable.
>
> Did you apply the patch to ALL userspace dataspath instances that could be
> in you packet path ?
>
> What is the path followed in the problem case ?
>
>
>
>
>
>
>1.
>
>
>
> The nature of the issue is same, OVS native firewall drops packets less
> than 60 bytes.
>
>
>
> Pls correct me and advise if the issue on OVS compute is fixable.
>
>
>
> You could check the OVS tree kernel module.
>
>
>
>
>
>
>
> JIng
>
>
>
> *From:* Darrell Ball 
> *Sent:* Friday, May 3, 2019 11:55 AM
> *To:* Zhang, Jing C. (Nokia - CA/Ottawa) 
> *Cc:* Han Zhou ; ovs-discuss@openvswitch.org
> *Subject:* Re: FW: [ovs-discuss] OVS 2.9.0 native firewall drops empty
> payload TCP packets continued
>
>
>
> couple corrections inline
>
>
>
> On Fri, May 3, 2019 at 8:52 AM Darrell Ball  wrote:
>
>
>
>
>
> On Fri, May 3, 2019 at 8:29 AM Zhang, Jing C. (Nokia - CA/Ottawa) <
> jing.c.zh...@nokia.com> wrote:
>
>
>1. This issue is with native OVS firewall where the data flows 

Re: [ovs-discuss] FW: OVS 2.9.0 native firewall drops empty payload TCP packets continued

[Darrell Ball]

On Fri, May 3, 2019 at 10:44 AM Zhang, Jing C. (Nokia - CA/Ottawa) <
jing.c.zh...@nokia.com> wrote:

>
>1. The hybrid firewall refers to Linux bridge based firewall. To debug
>the issue, we switch the neutron OVS agent to use native firewall.
>
>
>
> [securitygroup]
>
> #firewall_driver=iptables_hybrid
>
> firewall_driver=openvswitch
>
>
>
> # ovs-ofctl dump-flows br-int | grep ct_state
>
> cookie=0xddb977285e2ba9b6, duration=185.322s, table=71, n_packets=0,
> n_bytes=0, idle_age=185, priority=110,ct_state=+trk
> actions=ct_clear,resubmit(,71)
>
> cookie=0xddb977285e2ba9b6, duration=182.170s, table=72, n_packets=0,
> n_bytes=0, idle_age=184, priority=75,ct_state=+est-rel-rpl,icmp,reg5=0x1
> actions=resubmit(,73)
>
> cookie=0xddb977285e2ba9b6, duration=182.170s, table=72, n_packets=204,
> n_bytes=16642, idle_age=18, priority=77,ct_state=+est-rel-rpl,udp,reg5=0x1
> actions=resubmit(,73)
>
> cookie=0xddb977285e2ba9b6, duration=182.170s, table=72, n_packets=0,
> n_bytes=0, idle_age=184, priority=77,ct_state=+est-rel-rpl,tcp,reg5=0x1
> actions=resubmit(,73)
>
> cookie=0xddb977285e2ba9b6, duration=182.170s, table=72, n_packets=0,
> n_bytes=0, idle_age=184, priority=75,ct_state=+new-est,icmp,reg5=0x1
> actions=resubmit(,73)
>
> cookie=0xddb977285e2ba9b6, duration=182.170s, table=72, n_packets=204,
> n_bytes=16642, idle_age=18, priority=77,ct_state=+new-est,udp,reg5=0x1
> actions=resubmit(,73)
>
> cookie=0xddb977285e2ba9b6, duration=182.170s, table=72, n_packets=0,
> n_bytes=0, idle_age=184, priority=77,ct_state=+new-est,tcp,reg5=0x1
> actions=resubmit(,73)
>
> cookie=0xddb977285e2ba9b6, duration=182.170s, table=72, n_packets=0,
> n_bytes=0, idle_age=184, priority=74,ct_state=+est-rel-rpl,ipv6,reg5=0x1
> actions=resubmit(,73)
>
> cookie=0xddb977285e2ba9b6, duration=182.170s, table=72, n_packets=0,
> n_bytes=0, idle_age=184, priority=74,ct_state=+est-rel-rpl,ip,reg5=0x1
> actions=resubmit(,73)
>
> cookie=0xddb977285e2ba9b6, duration=182.170s, table=72, n_packets=0,
> n_bytes=0, idle_age=184, priority=74,ct_state=+new-est,ipv6,reg5=0x1
> actions=resubmit(,73)
>
> cookie=0xddb977285e2ba9b6, duration=182.170s, table=72, n_packets=0,
> n_bytes=0, idle_age=184, priority=74,ct_state=+new-est,ip,reg5=0x1
> actions=resubmit(,73)
>
>
>
> My understanding is Centos 7 packs the OVS tree, that how conntrack is
> supported before kernel 4.3.
>
>
>
> https://cbs.centos.org/koji/buildinfo?buildID=24381
>

I assumed you are using Linux tree OVS kernel module



>
>
>
>
>1. I back-ported the patch pointed by Han to OVS v2.9.0, it does not
>solve the packet drop on the OVS compute.
>
>
Thanks for confirming
We don't know your full topology, but if you want to send packets following
a path that goes thru an OVS userspace datapath then
that patch would be applicable.
Did you apply the patch to ALL userspace dataspath instances that could be
in you packet path ?
What is the path followed in the problem case ?



>
>1.
>
>
>
> The nature of the issue is same, OVS native firewall drops packets less
> than 60 bytes.
>
>
>
> Pls correct me and advise if the issue on OVS compute is fixable.
>

You could check the OVS tree kernel module.



>
>
> JIng
>
>
>
> *From:* Darrell Ball 
> *Sent:* Friday, May 3, 2019 11:55 AM
> *To:* Zhang, Jing C. (Nokia - CA/Ottawa) 
> *Cc:* Han Zhou ; ovs-discuss@openvswitch.org
> *Subject:* Re: FW: [ovs-discuss] OVS 2.9.0 native firewall drops empty
> payload TCP packets continued
>
>
>
> couple corrections inline
>
>
>
> On Fri, May 3, 2019 at 8:52 AM Darrell Ball  wrote:
>
>
>
>
>
> On Fri, May 3, 2019 at 8:29 AM Zhang, Jing C. (Nokia - CA/Ottawa) <
> jing.c.zh...@nokia.com> wrote:
>
>
>1. This issue is with native OVS firewall where the data flows are
>subject to conntrack rules, there is no issue for hybrid firewall
>
>
>
> 1/ Does 'native OVS firewall' mean either kernel datapath or userpace
> datapath ?
>
> 2/ Pls define 'hybrid datapath' in your context ?
>
>
>
> 2/ Pls define 'hybrid firewall' in your context ?
>
>
>
>
>
>
>1.
>
>
>
>1. Below is from DPDK compute:
>
>
>
> # ovs-vsctl --no-wait get Open_vSwitch . other_config
>
>
>
> 3/ dpdk is not initialized
>
>
>
> An info log is also present when dpdk is initialized: "DPDK Enabled -
> initialized"
>
>
>
> btw: '--no-wait' is needed for get commands
>
>
>
> btw: '--no-wait' is NOT needed for get commands
>
>
>
>
>
>
>
> # ovs-vsctl -- list bridge br-int | grep datapath
>
> datapath

Re: [ovs-discuss] FW: OVS 2.9.0 native firewall drops empty payload TCP packets continued

[Darrell Ball]

couple corrections inline

On Fri, May 3, 2019 at 8:52 AM Darrell Ball  wrote:

>
>
> On Fri, May 3, 2019 at 8:29 AM Zhang, Jing C. (Nokia - CA/Ottawa) <
> jing.c.zh...@nokia.com> wrote:
>
>>
>>1. This issue is with native OVS firewall where the data flows are
>>subject to conntrack rules, there is no issue for hybrid firewall
>>
>>
> 1/ Does 'native OVS firewall' mean either kernel datapath or userpace
> datapath ?
> 2/ Pls define 'hybrid datapath' in your context ?
>

2/ Pls define 'hybrid firewall' in your context ?


>
>
>>
>>1.
>>
>>
>>
>>1. Below is from DPDK compute:
>>
>>
>>
>> # ovs-vsctl --no-wait get Open_vSwitch . other_config
>>
>
> 3/ dpdk is not initialized
>
> An info log is also present when dpdk is initialized: "DPDK Enabled -
> initialized"
>
> btw: '--no-wait' is needed for get commands
>

btw: '--no-wait' is NOT needed for get commands


>
>
>
>> # ovs-vsctl -- list bridge br-int | grep datapath
>>
>> datapath_id : "1a9b5b9ec94e"
>>
>> datapath_type   : netdev
>>
>> datapath_version: ""
>>
>
> 4/ You are using userspace datapath on this particular node without dpdk
> support
> Is that intentional ?
>
>
>
>>
>>
>> *From:* Darrell Ball 
>> *Sent:* Friday, May 3, 2019 11:24 AM
>> *To:* Zhang, Jing C. (Nokia - CA/Ottawa) 
>> *Cc:* Han Zhou ; ovs-discuss@openvswitch.org
>> *Subject:* Re: FW: [ovs-discuss] OVS 2.9.0 native firewall drops empty
>> payload TCP packets continued
>>
>>
>>
>> The node you are displaying below is running kernel datapath
>>
>>
>>
>> fyi: The fix Han pointed you to is for userspace datapath/conntrack
>>
>>
>>
>>
>>
>>
>>
>> On Fri, May 3, 2019 at 8:14 AM Zhang, Jing C. (Nokia - CA/Ottawa) <
>> jing.c.zh...@nokia.com> wrote:
>>
>> We have both OVS and OVS-dpdk computes.
>>
>>
>>
>> Below is from OVS compute:
>>
>>
>>
>> # ovs-vsctl --no-wait get Open_vSwitch . other_config
>>
>> {}
>>
>> # ovs-vsctl -- list bridge br-int | grep datapath
>>
>> datapath_id : "aaf62aaf3546"
>>
>> datapath_type   : system
>>
>> datapath_version: ""
>>
>>
>>
>> *From:* Darrell Ball 
>> *Sent:* Friday, May 3, 2019 12:19 AM
>> *To:* Han Zhou ; Zhang, Jing C. (Nokia - CA/Ottawa) <
>> jing.c.zh...@nokia.com>; ovs-discuss@openvswitch.org
>> *Subject:* Re: FW: [ovs-discuss] OVS 2.9.0 native firewall drops empty
>> payload TCP packets continued
>>
>>
>>
>> What do the following commands yield ?
>>
>>
>>
>> sudo ovs-vsctl -- get bridge  datapath_type
>>
>>
>>
>> sudo ovs-vsctl --no-wait get Open_vSwitch . other_config
>>
>>
>>
>>
>>
>>
>>
>> *From: * on behalf of Han Zhou <
>> zhou...@gmail.com>
>> *Date: *Thursday, May 2, 2019 at 7:12 PM
>> *To: *"Zhang, Jing C. (Nokia - CA/Ottawa)" 
>> *Cc: *"ovs-discuss@openvswitch.org" 
>> *Subject: *Re: [ovs-discuss] OVS 2.9.0 native firewall drops empty
>> payload TCP packets continued
>>
>>
>>
>>
>>
>> On Thu, May 2, 2019 at 6:04 PM Zhang, Jing C. (Nokia - CA/Ottawa) <
>> jing.c.zh...@nokia.com> wrote:
>> >
>> > We (our VNFs) continue to observe the same empty payload TCP (ACK)
>> packet drop with native firewall (see original post below) after upgrading
>> to Centos 7.6. This packet drop results in unacceptable TCP performance, by
>> that native firewall still can not be enabled in product.
>> >
>> >
>> https://mail.openvswitch.org/pipermail/ovs-discuss/2018-August/047263.html
>> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openvswitch.org%2Fpipermail%2Fovs-discuss%2F2018-August%2F047263.html=02%7C01%7Cdball%40vmware.com%7Cd358d5a23b2640ebd28708d6cf6cc524%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636924463524642583=ihTE%2BcOA9d8yNflCbqJYHXOJWhFuqvq4yJmu7H9lGwo%3D=0>
>> >
>> > $ uname -a
>> > Linux overcloud-sriovperformancecompute-0 3.10.0-957.10.1.el7.x86_64 #1
>> SMP Mon Mar 18 15:06:45 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
>> >
>> > $ ovs-vswitchd --version
>> > ovs-vswitchd (Open vSwitch) 2.9.0
>> > DPDK 17.11.0
>> >
>> > The scenario: OVS provider VLAN network is use

Re: [ovs-discuss] FW: OVS 2.9.0 native firewall drops empty payload TCP packets continued

[Darrell Ball]

On Fri, May 3, 2019 at 8:29 AM Zhang, Jing C. (Nokia - CA/Ottawa) <
jing.c.zh...@nokia.com> wrote:

>
>1. This issue is with native OVS firewall where the data flows are
>subject to conntrack rules, there is no issue for hybrid firewall
>
>
1/ Does 'native OVS firewall' mean either kernel datapath or userpace
datapath ?
2/ Pls define 'hybrid datapath' in your context ?


>
>1.
>
>
>
>1. Below is from DPDK compute:
>
>
>
> # ovs-vsctl --no-wait get Open_vSwitch . other_config
>

3/ dpdk is not initialized

An info log is also present when dpdk is initialized: "DPDK Enabled -
initialized"

btw: '--no-wait' is needed for get commands



> # ovs-vsctl -- list bridge br-int | grep datapath
>
> datapath_id : "1a9b5b9ec94e"
>
> datapath_type   : netdev
>
> datapath_version: ""
>

4/ You are using userspace datapath on this particular node without dpdk
support
Is that intentional ?



>
>
> *From:* Darrell Ball 
> *Sent:* Friday, May 3, 2019 11:24 AM
> *To:* Zhang, Jing C. (Nokia - CA/Ottawa) 
> *Cc:* Han Zhou ; ovs-discuss@openvswitch.org
> *Subject:* Re: FW: [ovs-discuss] OVS 2.9.0 native firewall drops empty
> payload TCP packets continued
>
>
>
> The node you are displaying below is running kernel datapath
>
>
>
> fyi: The fix Han pointed you to is for userspace datapath/conntrack
>
>
>
>
>
>
>
> On Fri, May 3, 2019 at 8:14 AM Zhang, Jing C. (Nokia - CA/Ottawa) <
> jing.c.zh...@nokia.com> wrote:
>
> We have both OVS and OVS-dpdk computes.
>
>
>
> Below is from OVS compute:
>
>
>
> # ovs-vsctl --no-wait get Open_vSwitch . other_config
>
> {}
>
> # ovs-vsctl -- list bridge br-int | grep datapath
>
> datapath_id : "aaf62aaf3546"
>
> datapath_type   : system
>
> datapath_version: ""
>
>
>
> *From:* Darrell Ball 
> *Sent:* Friday, May 3, 2019 12:19 AM
> *To:* Han Zhou ; Zhang, Jing C. (Nokia - CA/Ottawa) <
> jing.c.zh...@nokia.com>; ovs-discuss@openvswitch.org
> *Subject:* Re: FW: [ovs-discuss] OVS 2.9.0 native firewall drops empty
> payload TCP packets continued
>
>
>
> What do the following commands yield ?
>
>
>
> sudo ovs-vsctl -- get bridge  datapath_type
>
>
>
> sudo ovs-vsctl --no-wait get Open_vSwitch . other_config
>
>
>
>
>
>
>
> *From: * on behalf of Han Zhou <
> zhou...@gmail.com>
> *Date: *Thursday, May 2, 2019 at 7:12 PM
> *To: *"Zhang, Jing C. (Nokia - CA/Ottawa)" 
> *Cc: *"ovs-discuss@openvswitch.org" 
> *Subject: *Re: [ovs-discuss] OVS 2.9.0 native firewall drops empty
> payload TCP packets continued
>
>
>
>
>
> On Thu, May 2, 2019 at 6:04 PM Zhang, Jing C. (Nokia - CA/Ottawa) <
> jing.c.zh...@nokia.com> wrote:
> >
> > We (our VNFs) continue to observe the same empty payload TCP (ACK)
> packet drop with native firewall (see original post below) after upgrading
> to Centos 7.6. This packet drop results in unacceptable TCP performance, by
> that native firewall still can not be enabled in product.
> >
> >
> https://mail.openvswitch.org/pipermail/ovs-discuss/2018-August/047263.html
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openvswitch.org%2Fpipermail%2Fovs-discuss%2F2018-August%2F047263.html=02%7C01%7Cdball%40vmware.com%7Cd358d5a23b2640ebd28708d6cf6cc524%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636924463524642583=ihTE%2BcOA9d8yNflCbqJYHXOJWhFuqvq4yJmu7H9lGwo%3D=0>
> >
> > $ uname -a
> > Linux overcloud-sriovperformancecompute-0 3.10.0-957.10.1.el7.x86_64 #1
> SMP Mon Mar 18 15:06:45 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
> >
> > $ ovs-vswitchd --version
> > ovs-vswitchd (Open vSwitch) 2.9.0
> > DPDK 17.11.0
> >
> > The scenario: OVS provider VLAN network is used
> >
> >
> > in physical interface of ovs compute zero length tcp payload packet
> arrives as padded to 64 bytes (and vlan tag is included in ethernet header)
> > same packet does not appear anymore in the tcpdump taken from tap-xyz
> interface (once vlan tag is removed and packet is cut by 4 bytes to 60
> bytes)
> >
> >
> > Tcpdump on physical port:
> >
> > 00:25:24.468423 fa:16:3e:d7:bb:2c > fa:16:3e:ff:dd:29, ethertype 802.1Q
> (0x8100), length 2674: vlan 3837, p 0, ethertype IPv4, (tos 0x0, ttl 64, id
> 6893, offset 0, flags [DF], proto TCP (6), length 2656)
> > 192.168.10.52.80 > 192.168.10.60.57576: Flags [P.], cksum 0xa013
> (incorrect -> 0x772d), seq 8961:11577, ack 78, win 210, length 2616: HTTP
> > 00:25:24.468593 fa:1

Re: [ovs-discuss] FW: OVS 2.9.0 native firewall drops empty payload TCP packets continued

[Darrell Ball]

and jtbc, ovs-dpdk uses the userspace datapath

On Fri, May 3, 2019 at 8:24 AM Darrell Ball  wrote:

> The node you are displaying below is running kernel datapath
>
> fyi: The fix Han pointed you to is for userspace datapath/conntrack
>
>
>
> On Fri, May 3, 2019 at 8:14 AM Zhang, Jing C. (Nokia - CA/Ottawa) <
> jing.c.zh...@nokia.com> wrote:
>
>> We have both OVS and OVS-dpdk computes.
>>
>>
>>
>> Below is from OVS compute:
>>
>>
>>
>> # ovs-vsctl --no-wait get Open_vSwitch . other_config
>>
>> {}
>>
>> # ovs-vsctl -- list bridge br-int | grep datapath
>>
>> datapath_id : "aaf62aaf3546"
>>
>> datapath_type   : system
>>
>> datapath_version: ""
>>
>>
>>
>> *From:* Darrell Ball 
>> *Sent:* Friday, May 3, 2019 12:19 AM
>> *To:* Han Zhou ; Zhang, Jing C. (Nokia - CA/Ottawa) <
>> jing.c.zh...@nokia.com>; ovs-discuss@openvswitch.org
>> *Subject:* Re: FW: [ovs-discuss] OVS 2.9.0 native firewall drops empty
>> payload TCP packets continued
>>
>>
>>
>> What do the following commands yield ?
>>
>>
>>
>> sudo ovs-vsctl -- get bridge  datapath_type
>>
>>
>>
>> sudo ovs-vsctl --no-wait get Open_vSwitch . other_config
>>
>>
>>
>>
>>
>>
>>
>> *From: * on behalf of Han Zhou <
>> zhou...@gmail.com>
>> *Date: *Thursday, May 2, 2019 at 7:12 PM
>> *To: *"Zhang, Jing C. (Nokia - CA/Ottawa)" 
>> *Cc: *"ovs-discuss@openvswitch.org" 
>> *Subject: *Re: [ovs-discuss] OVS 2.9.0 native firewall drops empty
>> payload TCP packets continued
>>
>>
>>
>>
>>
>> On Thu, May 2, 2019 at 6:04 PM Zhang, Jing C. (Nokia - CA/Ottawa) <
>> jing.c.zh...@nokia.com> wrote:
>> >
>> > We (our VNFs) continue to observe the same empty payload TCP (ACK)
>> packet drop with native firewall (see original post below) after upgrading
>> to Centos 7.6. This packet drop results in unacceptable TCP performance, by
>> that native firewall still can not be enabled in product.
>> >
>> >
>> https://mail.openvswitch.org/pipermail/ovs-discuss/2018-August/047263.html
>> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openvswitch.org%2Fpipermail%2Fovs-discuss%2F2018-August%2F047263.html=02%7C01%7Cdball%40vmware.com%7Cd358d5a23b2640ebd28708d6cf6cc524%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636924463524642583=ihTE%2BcOA9d8yNflCbqJYHXOJWhFuqvq4yJmu7H9lGwo%3D=0>
>> >
>> > $ uname -a
>> > Linux overcloud-sriovperformancecompute-0 3.10.0-957.10.1.el7.x86_64 #1
>> SMP Mon Mar 18 15:06:45 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
>> >
>> > $ ovs-vswitchd --version
>> > ovs-vswitchd (Open vSwitch) 2.9.0
>> > DPDK 17.11.0
>> >
>> > The scenario: OVS provider VLAN network is used
>> >
>> >
>> > in physical interface of ovs compute zero length tcp payload packet
>> arrives as padded to 64 bytes (and vlan tag is included in ethernet header)
>> > same packet does not appear anymore in the tcpdump taken from tap-xyz
>> interface (once vlan tag is removed and packet is cut by 4 bytes to 60
>> bytes)
>> >
>> >
>> > Tcpdump on physical port:
>> >
>> > 00:25:24.468423 fa:16:3e:d7:bb:2c > fa:16:3e:ff:dd:29, ethertype 802.1Q
>> (0x8100), length 2674: vlan 3837, p 0, ethertype IPv4, (tos 0x0, ttl 64, id
>> 6893, offset 0, flags [DF], proto TCP (6), length 2656)
>> > 192.168.10.52.80 > 192.168.10.60.57576: Flags [P.], cksum 0xa013
>> (incorrect -> 0x772d), seq 8961:11577, ack 78, win 210, length 2616: HTTP
>> > 00:25:24.468593 fa:16:3e:ff:dd:29 > fa:16:3e:d7:bb:2c, ethertype 802.1Q
>> (0x8100), length 60: vlan 3837, p 0, ethertype IPv4, (tos 0x0, ttl 64, id
>> 56318, offset 0, flags [DF], proto TCP (6), length 40)
>> > 192.168.10.60.57576 > 192.168.10.52.80: Flags [.], cksum 0x1d34
>> (correct), seq 78, ack 11577, win 391, length 0
>> > 00:25:24.475848 fa:16:3e:ff:dd:29 > fa:16:3e:d7:bb:2c, ethertype 802.1Q
>> (0x8100), length 60: vlan 3837, p 0, ethertype IPv4, (tos 0x0, ttl 64, id
>> 56319, offset 0, flags [DF], proto TCP (6), length 40)
>> > 192.168.10.60.57576 > 192.168.10.52.80: Flags [F.], cksum 0x1d33
>> (correct), seq 78, ack 11577, win 391, length 0
>> > 00:25:24.480337 fa:16:3e:d7:bb:2c > fa:16:3e:ff:dd:29, ethertype 802.1Q
>> (0x8100), length 2674: vlan 3837, p 0, ethertype IPv4, (

Re: [ovs-discuss] FW: OVS 2.9.0 native firewall drops empty payload TCP packets continued

[Darrell Ball]

The node you are displaying below is running kernel datapath

fyi: The fix Han pointed you to is for userspace datapath/conntrack



On Fri, May 3, 2019 at 8:14 AM Zhang, Jing C. (Nokia - CA/Ottawa) <
jing.c.zh...@nokia.com> wrote:

> We have both OVS and OVS-dpdk computes.
>
>
>
> Below is from OVS compute:
>
>
>
> # ovs-vsctl --no-wait get Open_vSwitch . other_config
>
> {}
>
> # ovs-vsctl -- list bridge br-int | grep datapath
>
> datapath_id : "aaf62aaf3546"
>
> datapath_type   : system
>
> datapath_version: ""
>
>
>
> *From:* Darrell Ball 
> *Sent:* Friday, May 3, 2019 12:19 AM
> *To:* Han Zhou ; Zhang, Jing C. (Nokia - CA/Ottawa) <
> jing.c.zh...@nokia.com>; ovs-discuss@openvswitch.org
> *Subject:* Re: FW: [ovs-discuss] OVS 2.9.0 native firewall drops empty
> payload TCP packets continued
>
>
>
> What do the following commands yield ?
>
>
>
> sudo ovs-vsctl -- get bridge  datapath_type
>
>
>
> sudo ovs-vsctl --no-wait get Open_vSwitch . other_config
>
>
>
>
>
>
>
> *From: * on behalf of Han Zhou <
> zhou...@gmail.com>
> *Date: *Thursday, May 2, 2019 at 7:12 PM
> *To: *"Zhang, Jing C. (Nokia - CA/Ottawa)" 
> *Cc: *"ovs-discuss@openvswitch.org" 
> *Subject: *Re: [ovs-discuss] OVS 2.9.0 native firewall drops empty
> payload TCP packets continued
>
>
>
>
>
> On Thu, May 2, 2019 at 6:04 PM Zhang, Jing C. (Nokia - CA/Ottawa) <
> jing.c.zh...@nokia.com> wrote:
> >
> > We (our VNFs) continue to observe the same empty payload TCP (ACK)
> packet drop with native firewall (see original post below) after upgrading
> to Centos 7.6. This packet drop results in unacceptable TCP performance, by
> that native firewall still can not be enabled in product.
> >
> >
> https://mail.openvswitch.org/pipermail/ovs-discuss/2018-August/047263.html
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openvswitch.org%2Fpipermail%2Fovs-discuss%2F2018-August%2F047263.html=02%7C01%7Cdball%40vmware.com%7Cd358d5a23b2640ebd28708d6cf6cc524%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636924463524642583=ihTE%2BcOA9d8yNflCbqJYHXOJWhFuqvq4yJmu7H9lGwo%3D=0>
> >
> > $ uname -a
> > Linux overcloud-sriovperformancecompute-0 3.10.0-957.10.1.el7.x86_64 #1
> SMP Mon Mar 18 15:06:45 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
> >
> > $ ovs-vswitchd --version
> > ovs-vswitchd (Open vSwitch) 2.9.0
> > DPDK 17.11.0
> >
> > The scenario: OVS provider VLAN network is used
> >
> >
> > in physical interface of ovs compute zero length tcp payload packet
> arrives as padded to 64 bytes (and vlan tag is included in ethernet header)
> > same packet does not appear anymore in the tcpdump taken from tap-xyz
> interface (once vlan tag is removed and packet is cut by 4 bytes to 60
> bytes)
> >
> >
> > Tcpdump on physical port:
> >
> > 00:25:24.468423 fa:16:3e:d7:bb:2c > fa:16:3e:ff:dd:29, ethertype 802.1Q
> (0x8100), length 2674: vlan 3837, p 0, ethertype IPv4, (tos 0x0, ttl 64, id
> 6893, offset 0, flags [DF], proto TCP (6), length 2656)
> > 192.168.10.52.80 > 192.168.10.60.57576: Flags [P.], cksum 0xa013
> (incorrect -> 0x772d), seq 8961:11577, ack 78, win 210, length 2616: HTTP
> > 00:25:24.468593 fa:16:3e:ff:dd:29 > fa:16:3e:d7:bb:2c, ethertype 802.1Q
> (0x8100), length 60: vlan 3837, p 0, ethertype IPv4, (tos 0x0, ttl 64, id
> 56318, offset 0, flags [DF], proto TCP (6), length 40)
> > 192.168.10.60.57576 > 192.168.10.52.80: Flags [.], cksum 0x1d34
> (correct), seq 78, ack 11577, win 391, length 0
> > 00:25:24.475848 fa:16:3e:ff:dd:29 > fa:16:3e:d7:bb:2c, ethertype 802.1Q
> (0x8100), length 60: vlan 3837, p 0, ethertype IPv4, (tos 0x0, ttl 64, id
> 56319, offset 0, flags [DF], proto TCP (6), length 40)
> > 192.168.10.60.57576 > 192.168.10.52.80: Flags [F.], cksum 0x1d33
> (correct), seq 78, ack 11577, win 391, length 0
> > 00:25:24.480337 fa:16:3e:d7:bb:2c > fa:16:3e:ff:dd:29, ethertype 802.1Q
> (0x8100), length 2674: vlan 3837, p 0, ethertype IPv4, (tos 0x0, ttl 64, id
> 6894, offset 0, flags [DF], proto TCP (6), length 2656)
> > 192.168.10.52.80 > 192.168.10.60.57576: Flags [P.], cksum 0xa013
> (incorrect -> 0x772d), seq 8961:11577, ack 78, win 210, length 2616: HTTP
> >
> > Tcpdump on vm tap interface:
> >
> > 00:25:24.468419 fa:16:3e:d7:bb:2c > fa:16:3e:ff:dd:29, ethertype IPv4
> (0x0800), length 2670: (tos 0x0, ttl 64, id 6893, offset 0, flags [DF],
> proto TCP (6), length 2656)
> > 192.168.10.52.80 > 192.168.10.60.57576: Flags [P.], cksum 0xa

Re: [ovs-discuss] FW: OVS 2.9.0 native firewall drops empty payload TCP packets continued

[Darrell Ball]

What do the following commands yield ?

sudo ovs-vsctl -- get bridge  datapath_type

sudo ovs-vsctl --no-wait get Open_vSwitch . other_config



>
> *From: * on behalf of Han Zhou <
> zhou...@gmail.com>
> *Date: *Thursday, May 2, 2019 at 7:12 PM
> *To: *"Zhang, Jing C. (Nokia - CA/Ottawa)" 
> *Cc: *"ovs-discuss@openvswitch.org" 
> *Subject: *Re: [ovs-discuss] OVS 2.9.0 native firewall drops empty
> payload TCP packets continued
>
>
>
>
>
> On Thu, May 2, 2019 at 6:04 PM Zhang, Jing C. (Nokia - CA/Ottawa) <
> jing.c.zh...@nokia.com> wrote:
> >
> > We (our VNFs) continue to observe the same empty payload TCP (ACK)
> packet drop with native firewall (see original post below) after upgrading
> to Centos 7.6. This packet drop results in unacceptable TCP performance, by
> that native firewall still can not be enabled in product.
> >
> >
> https://mail.openvswitch.org/pipermail/ovs-discuss/2018-August/047263.html
> 
> >
> > $ uname -a
> > Linux overcloud-sriovperformancecompute-0 3.10.0-957.10.1.el7.x86_64 #1
> SMP Mon Mar 18 15:06:45 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
> >
> > $ ovs-vswitchd --version
> > ovs-vswitchd (Open vSwitch) 2.9.0
> > DPDK 17.11.0
> >
> > The scenario: OVS provider VLAN network is used
> >
> >
> > in physical interface of ovs compute zero length tcp payload packet
> arrives as padded to 64 bytes (and vlan tag is included in ethernet header)
> > same packet does not appear anymore in the tcpdump taken from tap-xyz
> interface (once vlan tag is removed and packet is cut by 4 bytes to 60
> bytes)
> >
> >
> > Tcpdump on physical port:
> >
> > 00:25:24.468423 fa:16:3e:d7:bb:2c > fa:16:3e:ff:dd:29, ethertype 802.1Q
> (0x8100), length 2674: vlan 3837, p 0, ethertype IPv4, (tos 0x0, ttl 64, id
> 6893, offset 0, flags [DF], proto TCP (6), length 2656)
> > 192.168.10.52.80 > 192.168.10.60.57576: Flags [P.], cksum 0xa013
> (incorrect -> 0x772d), seq 8961:11577, ack 78, win 210, length 2616: HTTP
> > 00:25:24.468593 fa:16:3e:ff:dd:29 > fa:16:3e:d7:bb:2c, ethertype 802.1Q
> (0x8100), length 60: vlan 3837, p 0, ethertype IPv4, (tos 0x0, ttl 64, id
> 56318, offset 0, flags [DF], proto TCP (6), length 40)
> > 192.168.10.60.57576 > 192.168.10.52.80: Flags [.], cksum 0x1d34
> (correct), seq 78, ack 11577, win 391, length 0
> > 00:25:24.475848 fa:16:3e:ff:dd:29 > fa:16:3e:d7:bb:2c, ethertype 802.1Q
> (0x8100), length 60: vlan 3837, p 0, ethertype IPv4, (tos 0x0, ttl 64, id
> 56319, offset 0, flags [DF], proto TCP (6), length 40)
> > 192.168.10.60.57576 > 192.168.10.52.80: Flags [F.], cksum 0x1d33
> (correct), seq 78, ack 11577, win 391, length 0
> > 00:25:24.480337 fa:16:3e:d7:bb:2c > fa:16:3e:ff:dd:29, ethertype 802.1Q
> (0x8100), length 2674: vlan 3837, p 0, ethertype IPv4, (tos 0x0, ttl 64, id
> 6894, offset 0, flags [DF], proto TCP (6), length 2656)
> > 192.168.10.52.80 > 192.168.10.60.57576: Flags [P.], cksum 0xa013
> (incorrect -> 0x772d), seq 8961:11577, ack 78, win 210, length 2616: HTTP
> >
> > Tcpdump on vm tap interface:
> >
> > 00:25:24.468419 fa:16:3e:d7:bb:2c > fa:16:3e:ff:dd:29, ethertype IPv4
> (0x0800), length 2670: (tos 0x0, ttl 64, id 6893, offset 0, flags [DF],
> proto TCP (6), length 2656)
> > 192.168.10.52.80 > 192.168.10.60.57576: Flags [P.], cksum 0xa013
> (incorrect -> 0x772d), seq 8961:11577, ack 78, win 210, length 2616: HTTP
> > 00:25:24.480331 fa:16:3e:d7:bb:2c > fa:16:3e:ff:dd:29, ethertype IPv4
> (0x0800), length 2670: (tos 0x0, ttl 64, id 6894, offset 0, flags [DF],
> proto TCP (6), length 2656)
> > 192.168.10.52.80 > 192.168.10.60.57576: Flags [P.], cksum 0xa013
> (incorrect -> 0x772d), seq 8961:11577, ack 78, win 210, length 2616: HTTP
> >
> > Very straightforward to see the issue:
> >
> >
> > Configure neutron OVS agent to use native firewall
> > Create a pair of VMs on separate computes on provider vLAN
> > Disable TCP timestamp inside the VMs
> > Exchange TCP traffic between the VMs, e.g. http download.
> > Tcpdump on the physical and vm port, and compare.
> >
> >
> > I wonder why such obvious issue is not widely discussed?
> >
> > Jing
> >
>
>
>
> Maybe it's fixed by:
>
>
> https://github.com/openvswitch/ovs/commit/9171c63532ee9cbc63bb8cfae364ab071f44389b
> 
>
>
>
___
discuss mailing list
disc...@openvswitch.org

Re: [ovs-discuss] Changing Destination IP and MAC Address for TCP Connection

[Darrell Ball]

From:  on behalf of karthik karra 

Date: Thursday, December 6, 2018 at 5:35 PM
To: "ovs-discuss@openvswitch.org" 
Subject: [ovs-discuss] Changing Destination IP and MAC Address for TCP 
Connection

Hi All,

I have three VMs
VM1 - 192.168.1.101
VM2 - 192.168.1.102
VM3 - 192.168.1.103
I am using netcat for testing the flows between the VMs.

My scenario is, the netcat server listens on both VM2 and VM3. From VM1, I will 
provide "nc  ".
But I have a rule in OVS which mentions if source IP is VM1 and destination IP 
is VM2, then change the destination IP and MAC address to the VM3's such that 
the flow is redirected to the VM3.

This is working fine for UDP flows.

>>> really ?

For TCP, when I have searched for solution, I have found conntrack. I am using 
OVS 2.6 version as I have seen in one of the videos that from this version it 
supports the conntrack in user data path.


>> What is the o/p of  ‘sudo ovs-vsctl get bridge  
>> datapath_type’ ?

>> What is the o/p ‘sudo ovs-vsctl show’ ?


This is the flow rule I am using to match and change the addresses for TCP. I 
have followed the conntrack tutorial provided in OVS site.
ovs-ofctl add-flow ovs_bridge 
"table=0,priority=50,ct_state=-trk,tcp,nw_src=192.168.1.101,nw_dst=192.168.1.102,tp_dst=8001,idle_timeout=0,actions=ct(table=0),mod_nw_dst=192.168.1.103,mod_dl_dst=08:00:27:be:ce:e0,normal

>> Are you trying to use conntrack for NATing or you don’t care ?; right 
>> now, you are doing NAT outside of conntrack and
  anyways conntrack NAT is not in 2.6, assuming you are really 
using the userspace datapath ?

>> The above rule sends a packet thru conntrack that will not be very 
>> successful, but another copy of the packet will be subjected to 
>> nw_dst/dl_dst
  modification and be sent to the other VMs
   Normally endpoints talk bidirectionally, but your one rule seems 
to imply otherwise; can you explain ?
   What is the full o/p of ‘sudo ovs-ofctl dump-flows  ?

The SYN packet is still being sent to 102 rather than to 103.

>>  You mean the addresses are changed but the packet goes to VM3 or the 
>> addresses are not even changed from your POV ?
 Maybe the mac binding is not what you expect; first try sending to 
the openflow port of VM3 in
 the above rule first and see if that works; i.e.  change ‘normal’ 
to the ‘VM3 port’
 You could check ‘sudo ovs-appctl dpif/dump-flows ’

I have read that even the order of actions is important and I have put the 
"ct(table=0)" at the end. But its of no use.

Can anybody please help.

Thanks
Karra
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS 2.9.0 native firewall drops empty payload TCP packets

[Darrell Ball]

This seems to be in the kernel datapath and maybe recent issue
Greg, do you want to take a look ?


On 8/27/18, 9:50 AM, "ovs-discuss-boun...@openvswitch.org on behalf of Darrell 
Ball"  wrote:

I can take a look.

On 8/27/18, 9:47 AM, "ovs-discuss-boun...@openvswitch.org on behalf of Ben 
Pfaff"  wrote:

On Mon, Aug 27, 2018 at 01:20:15PM +, Zhang, Jing C. (Nokia - 
CA/Ottawa) wrote:
> We have customers reporting sluggish HTTP download with OVS 2.9.0. 
After debugging, we find the issue is OVS 2.9.0 native firewall drops TCP 
control packets (TCP ACK) with empty payload. The issue can be avoided by 
either reverting back to the legacy Linux bridge firewall or enabling TCP 
timestamp at both HTTP server and client sides.
> $ ovs-vswitchd --version
> ovs-vswitchd (Open vSwitch) 2.9.0
> DPDK 17.11.0

Darrell, this seems like it's in your area.  Will you take a look?

Thanks,

Ben.
___
discuss mailing list
disc...@openvswitch.org

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openvswitch.org%2Fmailman%2Flistinfo%2Fovs-discussdata=02%7C01%7Cdball%40vmware.com%7C2f9b0b93dbd241c6c41008d60c3d2c68%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636709854215126566sdata=LPjqpxatlO4lvu5cA4ejqF6PcBWoPbmdjvQuAwLcnH4%3Dreserved=0


___
discuss mailing list
disc...@openvswitch.org

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openvswitch.org%2Fmailman%2Flistinfo%2Fovs-discussdata=02%7C01%7Cdball%40vmware.com%7C2f9b0b93dbd241c6c41008d60c3d2c68%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636709854215126566sdata=LPjqpxatlO4lvu5cA4ejqF6PcBWoPbmdjvQuAwLcnH4%3Dreserved=0


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Recall: OVS 2.9.0 native firewall drops empty payload TCP packets

[Darrell Ball]

Did you mean to recall the issue ?

On 8/27/18, 9:48 AM, "ovs-discuss-boun...@openvswitch.org on behalf of Zhang, 
Jing C. (Nokia - CA/Ottawa)"  wrote:

Zhang, Jing C. (Nokia - CA/Ottawa) would like to recall the message, 
"[ovs-discuss] OVS 2.9.0 native firewall drops empty payload TCP packets".
___
discuss mailing list
disc...@openvswitch.org

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openvswitch.org%2Fmailman%2Flistinfo%2Fovs-discussdata=02%7C01%7Cdball%40vmware.com%7C355178c8254f499060a908d60c3ced80%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636709853183869015sdata=5YKwczWP0qc1nh6AHB3ZiAvZuMhSocT0X37U08QlX%2FI%3Dreserved=0


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS 2.9.0 native firewall drops empty payload TCP packets

[Darrell Ball]

I can take a look.

On 8/27/18, 9:47 AM, "ovs-discuss-boun...@openvswitch.org on behalf of Ben 
Pfaff"  wrote:

On Mon, Aug 27, 2018 at 01:20:15PM +, Zhang, Jing C. (Nokia - 
CA/Ottawa) wrote:
> We have customers reporting sluggish HTTP download with OVS 2.9.0. After 
debugging, we find the issue is OVS 2.9.0 native firewall drops TCP control 
packets (TCP ACK) with empty payload. The issue can be avoided by either 
reverting back to the legacy Linux bridge firewall or enabling TCP timestamp at 
both HTTP server and client sides.
> $ ovs-vswitchd --version
> ovs-vswitchd (Open vSwitch) 2.9.0
> DPDK 17.11.0

Darrell, this seems like it's in your area.  Will you take a look?

Thanks,

Ben.
___
discuss mailing list
disc...@openvswitch.org

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openvswitch.org%2Fmailman%2Flistinfo%2Fovs-discussdata=02%7C01%7Cdball%40vmware.com%7C1f27abb785824caad36a08d60c3cb330%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636709852193530364sdata=ivs6qeK%2BSpD1tLmPUq9VnwsBpPaf6sEnw7emt5N4iFE%3Dreserved=0


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [ovs-dev] Delete Flows matching specific cookie - OpenFlow 1.3.5 Spec support by OpenVSwitch

[Darrell Ball]

On 4/23/18, 6:53 PM, "Carlos Ferreira" <carlosmf...@gmail.com> wrote:

@IWAMOTO

Hello IWAMOTO,
No, I do not get any kind of error from Ryu. I have also verified the
structure of the Openflow messages sent to the switch using Wireshark
and no anomalies were found. The packet was well structured.

@Darrell,

Darrel, thank you for the info. I tried to use the del-flows using the
"ovs-ofctl del-flows" command with the specific cookie and in fact, it
did work. I'm lost here, because it does not seems to work if the
communication is done via OpenFlow with a remote controller.

Maybe you want to check what Ryu is sending the switch

http://www.openvswitch.org//support/dist-docs/ovs-ofctl.8.pdf

“
OpenFlow Switch Monitoring Commands

monitor switch [miss-len] [invalid_ttl] [watch:[spec...]]
Connects to switch and prints to the console all OpenFlow messages received. 
Usually, switch
should specify the name of a bridge in the ovs−vswitchd database.
“

eg) ovs-ofctl monitor br0 65534 invalid_ttl --detach --no-chdir --pidfile 2> 
ofctl_monitor.log




    On 24 April 2018 at 02:42, Darrell Ball <db...@vmware.com> wrote:
> //You can verify that OVS supports deletion by cookie specification by 
checking these tests:
>
>  932: ofproto.at:1746ofproto - del flows based on cookie
>  933: ofproto.at:1767ofproto - del flows based on cookie mask
>
> // Run the tests using “make check” like this:
> sudo make check TESTSUITEFLAGS='932-933' -C _gcc
>
> //Look at what is being tested here:
> tests/ofproto.at
>
> Thanks Darrell
>
>
> On 4/23/18, 4:17 PM, "ovs-dev-boun...@openvswitch.org on behalf of Carlos 
Ferreira" <ovs-dev-boun...@openvswitch.org on behalf of carlosmf...@gmail.com> 
wrote:
>
> Hello to all
>
> According to the OpenFlow 1.3.5 spec, page 44 specifies the following:
>
>
> "Modify and delete commands can also be filtered by cookie value, if
> the cookie_mask field contains
> a value other than 0. This constraint is that the bits specified by
> the cookie_mask in both
> the cookie field of the flow mod and a flow entry’s cookie value must
> be equal. In other words,
> (flow entry.cookie mod.cookie mask) == (flow mod.cookie
> mod.cookie mask)."
>
>
> Now, using the Ryu python-based controller, I tried to delete a flow
> by specifying the flow's cookie value, but the procedure was not
> successful.
>
> The following code is a test-example which I used.
>
> from ryu.base.app_manager import RyuApp
> from ryu.controller.dpset import EventDP
> from ryu.controller.handler import MAIN_DISPATCHER
> from ryu.controller.handler import set_ev_cls
> from ryu.ofproto import ofproto_v1_3
> from ryu.ofproto import ether, inet
>
> class MPLS_Testing(RyuApp):
>   OFP_VERSIONS = [ofproto_v1_3.OFP_VERSION]
>
>   @set_ev_cls(EventDP, MAIN_DISPATCHER)
>   def switch_connect_event(self, ev):
> ofp_parser = ev.dp.ofproto_parser
> ofp = ev.dp.ofproto
> datapath_obj = ev.dp
> if ev.enter:
>   datapath_obj.send_msg(  # Removes all flows registered in 
this switch.
> ofp_parser.OFPFlowMod(
>   datapath=datapath_obj,
>   table_id=ofp.OFPTT_ALL,
>   command=ofp.OFPFC_DELETE,
>   out_port=ofp.OFPP_ANY,
>   out_group=ofp.OFPG_ANY,
> )
>   )
>   add_label_flow = ofp_parser.OFPFlowMod(
> datapath=datapath_obj,
> cookie=1,
> table_id=0,
> command=ofp.OFPFC_ADD,
> match=ofp_parser.OFPMatch(
>   in_port=1
> ),
> instructions=[
>   ofp_parser.OFPInstructionActions(
> ofp.OFPIT_APPLY_ACTIONS,
> [
>   ofp_parser.OFPActionPushMpls(),
>   ofp_parser.OFPActionSetField(mpls_label=16),
> ]
>   ),
>   ofp_parser.OFPInstructionGotoTable(table_id=1),
> ]
>   )
>   datapath_obj.send_msg(add_label_flow

Re: [ovs-discuss] [ovs-dev] Delete Flows matching specific cookie - OpenFlow 1.3.5 Spec support by OpenVSwitch

[Darrell Ball]

//You can verify that OVS supports deletion by cookie specification by checking 
these tests:

 932: ofproto.at:1746ofproto - del flows based on cookie
 933: ofproto.at:1767ofproto - del flows based on cookie mask

// Run the tests using “make check” like this:
sudo make check TESTSUITEFLAGS='932-933' -C _gcc

//Look at what is being tested here:
tests/ofproto.at

Thanks Darrell


On 4/23/18, 4:17 PM, "ovs-dev-boun...@openvswitch.org on behalf of Carlos 
Ferreira"  
wrote:

Hello to all

According to the OpenFlow 1.3.5 spec, page 44 specifies the following:


"Modify and delete commands can also be filtered by cookie value, if
the cookie_mask field contains
a value other than 0. This constraint is that the bits specified by
the cookie_mask in both
the cookie field of the flow mod and a flow entry’s cookie value must
be equal. In other words,
(flow entry.cookie mod.cookie mask) == (flow mod.cookie
mod.cookie mask)."


Now, using the Ryu python-based controller, I tried to delete a flow
by specifying the flow's cookie value, but the procedure was not
successful.

The following code is a test-example which I used.

from ryu.base.app_manager import RyuApp
from ryu.controller.dpset import EventDP
from ryu.controller.handler import MAIN_DISPATCHER
from ryu.controller.handler import set_ev_cls
from ryu.ofproto import ofproto_v1_3
from ryu.ofproto import ether, inet

class MPLS_Testing(RyuApp):
  OFP_VERSIONS = [ofproto_v1_3.OFP_VERSION]

  @set_ev_cls(EventDP, MAIN_DISPATCHER)
  def switch_connect_event(self, ev):
ofp_parser = ev.dp.ofproto_parser
ofp = ev.dp.ofproto
datapath_obj = ev.dp
if ev.enter:
  datapath_obj.send_msg(  # Removes all flows registered in this 
switch.
ofp_parser.OFPFlowMod(
  datapath=datapath_obj,
  table_id=ofp.OFPTT_ALL,
  command=ofp.OFPFC_DELETE,
  out_port=ofp.OFPP_ANY,
  out_group=ofp.OFPG_ANY,
)
  )
  add_label_flow = ofp_parser.OFPFlowMod(
datapath=datapath_obj,
cookie=1,
table_id=0,
command=ofp.OFPFC_ADD,
match=ofp_parser.OFPMatch(
  in_port=1
),
instructions=[
  ofp_parser.OFPInstructionActions(
ofp.OFPIT_APPLY_ACTIONS,
[
  ofp_parser.OFPActionPushMpls(),
  ofp_parser.OFPActionSetField(mpls_label=16),
]
  ),
  ofp_parser.OFPInstructionGotoTable(table_id=1),
]
  )
  datapath_obj.send_msg(add_label_flow)

  add_label_flow2 = ofp_parser.OFPFlowMod(
datapath=datapath_obj,
cookie=2,
table_id=1,
command=ofp.OFPFC_ADD,
match=ofp_parser.OFPMatch(
  in_port=1
),
instructions=[
  ofp_parser.OFPInstructionActions(
ofp.OFPIT_APPLY_ACTIONS,
[
  ofp_parser.OFPActionPushMpls(),
  ofp_parser.OFPActionSetField(mpls_label=12),
]
  ),
  ofp_parser.OFPInstructionGotoTable(table_id=2),
]
  )
  datapath_obj.send_msg(add_label_flow2)

  # Deletes flow with cookie equal to 2.
  datapath_obj.send_msg(
ofp_parser.OFPFlowMod(
  cookie=2,
  cookie_mask=0x,
  datapath=datapath_obj,
  command=ofp.OFPFC_DELETE,
  out_port=ofp.OFPP_ANY,
  out_group=ofp.OFPG_ANY,
)
  )

Can anyone tell me if OpenVSwitch 2.9 supports cookie match when
deleting a flow from the tables? OpenFlow 1.3.5 spec clearly states
that a Delete command could also filter flows using the cookie value,
when the cookie_mask is different than zero. Currently, I'm kinda lost
here.

Thank you!

-- 

Carlos Miguel Ferreira
Researcher at Telecommunications Institute
Aveiro - Portugal
Work E-mail - c...@av.it.pt
Skype & GTalk -> carlosmf...@gmail.com
LinkedIn -> 
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.linkedin.com_in_carlosmferreira=DwIGaQ=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=ND4lqlTir-Ukyp2WkESK_WJ7j0b1dAUdptpdObaFU7Y=saz4uZw1U4C3pxnJSK9cRxTNXucuBUokJFvgmL3P3Wg=

Re: [ovs-discuss] tcp stream is broken with userspace conntrack after VM migration

[Darrell Ball]

Thanks for the report Neo.

From:  on behalf of "Yangxiaoliang (Neo)" 

Date: Saturday, February 24, 2018 at 2:09 AM
To: "ovs-discuss@openvswitch.org" 
Subject: [ovs-discuss] tcp stream is broken with userspace conntrack after VM 
migration

Hi,

Recently we have met a TCP STREAM broken problem with userspace conntrack 
feature.  After reading the ovs maillist, I found a similar problem with mine:  
https://mail.openvswitch.org/pipermail/ovs-discuss/2018-January/045958.html
Our test case is not absolutely same with his, but the result is almost the 
same (The TCP stream is stopped, and this TCP stream will close finally with 
timeout reason. But ping is ok. ). Since these is no any conclusion about this 
TCP conntrack issue, so I describe my problem here again to check that if 
anyone have any idea.

Our test case is described as below:
We are testing VM migration based on ovs(2.7.3)+dpdk(16.11).  There an iperf3 
TCP_STREAM test (speed >= 8Gbps) that running between two VMs.
 (VM_client – host1)   <- iperf3 TCP STREAM test ->  (VM_server – host2)

During the TCP_STREAM  test is running, we migrate the iperf3 client VM over 
and over again (migrating the iperf3 server VM doesn’t reproduce this problem) .

I capture the packets on client and server, then found that  the client doesn’t 
receive the TCP ACK packet from the server.  The client retransmit  TCP packets 
over and over again, and the server replies ACK packet but the ACK packet was 
dropped in server side.

We read the TCP conntrack code and add some debugging log. Then we found that 
below branchs in tcp_conn_update  will not be true.

--branch 1:
if (SEQ_GEQ(src->seqhi, end)
/* Last octet inside other's window space */
&& SEQ_GEQ(seq, src->seqlo - (dst->max_win << dws))
/* Retrans: not more than one window back */
&& (ackskew >= -MAXACKWINDOW)
/* Acking not more than one reassembled fragment backwards */
&& (ackskew <= (MAXACKWINDOW << sws))
/* Acking not more than one window forward */
&& ((tcp_flags & TCP_RST) == 0 || orig_seq == src->seqlo
|| (orig_seq == src->seqlo + 1) || (orig_seq + 1 == src->seqlo))) {
/* Require an exact/+1 sequence match on resets when possible */

--branch 2:
} else if ((dst->state < CT_DPIF_TCPS_SYN_SENT
|| dst->state >= CT_DPIF_TCPS_FIN_WAIT_2
|| src->state >= CT_DPIF_TCPS_FIN_WAIT_2)
   && SEQ_GEQ(src->seqhi + MAXACKWINDOW, end)
   /* Within a window forward of the originating packet */
   && SEQ_GEQ(seq, src->seqlo - MAXACKWINDOW)) {
   /* Within a window backward of the originating packet */

--Our debugging log is added as below:
} else {
// debugging log here
return CT_UPDATE_INVALID;
}

--Debugging log sample
2018-02-11T16:15:24.902940+08:00|err|ovs-vswitchd[16113]|tcp_conn_update[399]|00056|conntrack_tcp(pmd8)|:
  ==
2018-02-11T16:15:24.903168+08:00|err|ovs-vswitchd[16113]|tcp_conn_update[405]|00057|conntrack_tcp(pmd8)|:
 reply=0, (tcp header: tcp_src=59138, tcp_dst=5201, tcp_seq=557256579, 
tcp_ack=1919922981, tcp_ctl=0x8010, tcp_winsz=229, tcp_csum=21303, 
tcp_urg=0), (CON SRC: src->state=2, src->seqlo=557324635, src->seqhi=557258028, 
src->max_win=229, src->wscale=64), (CON DST: dst->state=0, dst->seqlo=0, 
dst->seqhi=1923674917, dst->max_win=1, dst->wscale=64)
2018-02-11T16:15:24.903357+08:00|err|ovs-vswitchd[16113]|tcp_conn_update[410]|00058|conntrack_tcp(pmd8)|:
 +3 Check branch 1: SEQ_GEQ(src->seqhi, end)=** 1 **, SEQ_GEQ(seq, src->seqlo - 
(dst->max_win << dws))=** 0 **, (ackskew <= (MAXACKWINDOW << sws))=** 1 **, 
((tcp_flags & TCP_RST) == 0 || orig_seq == src->seqlo|| (orig_seq == src->seqlo 
+ 1) || (orig_seq + 1 == src->seqlo))=** 1 **
2018-02-11T16:15:24.903543+08:00|err|ovs-vswitchd[16113]|tcp_conn_update[414]|00059|conntrack_tcp(pmd8)|:
 +3 1st branch detail: (src->seqhi=557258028, end=557258027), (seq=557256579, 
src->seqlo - (dst->max_win << dws)=557308251), (ackskew=-1919922981, 
-MAXACKWINDOW=-67035), (ackskew=-1919922981, (MAXACKWINDOW << sws)=1098301440), 
(tcp_flags=0x0010, orig_seq=557256579, src->seqlo=557324635), sws=14, 
dws=14, orig_seq=557256579
2018-02-11T16:15:24.903729+08:00|err|ovs-vswitchd[16113]|tcp_conn_update[419]|00060|conntrack_tcp(pmd8)|:
 +3 Check branch 2: (dst->state < CT_DPIF_TCPS_SYN_SENT || dst->state >= 
CT_DPIF_TCPS_FIN_WAIT_2 || src->state >= CT_DPIF_TCPS_FIN_WAIT_2)=** 1 **, 
SEQ_GEQ(src->seqhi + MAXACKWINDOW, end)=** 1 **, SEQ_GEQ(seq, src->seqlo - 
MAXACKWINDOW)=** 0 **
2018-02-11T16:15:24.903936+08:00|err|ovs-vswitchd[16113]|tcp_conn_update[423]|00061|conntrack_tcp(pmd8)|:
 +3 2nd 

Re: [ovs-discuss] 答复: conn_key_hash change hash arithmetic

[Darrell Ball]

I commented on this many weeks/months ago.

Thanks Darrell

On 2/1/18, 2:54 PM, "ovs-discuss-boun...@openvswitch.org on behalf of Ben 
Pfaff"  wrote:

Darrell, any comment on this?  + and ^ are both valid choices of
operator here and it's a little odd that one would be better than the
other.

On Thu, Dec 14, 2017 at 08:25:30AM +, liucheng (J) wrote:
> 
> 
> 发件人: liucheng (J)
> 发送时间: 2017年12月13日 18:01
> 收件人: 'ovs-discuss@openvswitch.org'
> 主题: [ovs-discuss]conn_key_hash change hash arithmetic
> 
> Hello all,
> I run a test with the user conntrack. And I found if I only change the 
udp port, then the hash with function “conn_key_hash” is not balance.
> I change the hmap num(ct->buckets) to 4096 and ct->n_conn_limit to 
30,000,000. And I print the num of the nodes contained in the hmap’s bucket.
> As an example, a result looks like below. Most bucket is empty, and some 
bucket contain hundreds of nodes;
> ~hmap 4095 count 4310 mask 4095~~~
> buket 488 content 367 node
> buket 1077 content 514 node
> buket 1118 content 281 node
> buket 1261 content 423 node
> buket 1280 content 268 node
> buket 1603 content 319 node
> buket 1724 content 352 node
> buket 2676 content 155 node
> buket 2993 content 471 node
> buket 3028 content 325 node
> buket 3836 content 355 node
> buket 4060 content 480 node
> 
> Then I change the code in conn_key_hash as the patch. And test result is 
the max nodes in one bucket is 12.
> The num of the bucket contained only one node is 5000542.
> The num of the bucket contained only two node is 4337097.
> The num of the bucket contained only three node is 2588535.
> The num of the bucket contained only four node is 1196063.
> The num of the bucket contained only five node is 460865.
> The num of the bucket contained only six node is 155936.
> The num of the bucket contained only seven node is 48727.
> Most buckets contain few nodes.
> 
> 
> diff --git a/lib/conntrack.c b/lib/conntrack.c
> index 6d078f5..3edf809 100644
> --- a/lib/conntrack.c
> +++ b/lib/conntrack.c
> @@ -2034,7 +2034,7 @@ conn_key_hash(const struct conn_key *key, uint32_t 
basis)
>  hdst = ct_endpoint_hash_add(hdst, >dst);
> 
>  /* Even if source and destination are swapped the hash will be the 
same. */
> -hash = hsrc ^ hdst;
> +hash = hsrc + hdst;
> 
>  /* Hash the rest of the key(L3 and L4 types and zone). */
>  hash = hash_words((uint32_t *) (>dst + 1),
> 

> ___
> discuss mailing list
> disc...@openvswitch.org
> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddiscuss=DwIGaQ=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=dTUs3WMDrQV6FEE6tIF3dGRCYYN-A5tIeAASPtMu-gk=bu696IgqmKAGyoCi7MmhOiXT3v5DG1avmEvvYwcMCLg=

___
discuss mailing list
disc...@openvswitch.org

https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddiscuss=DwIGaQ=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=dTUs3WMDrQV6FEE6tIF3dGRCYYN-A5tIeAASPtMu-gk=bu696IgqmKAGyoCi7MmhOiXT3v5DG1avmEvvYwcMCLg=


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [ovs-dev] Userspace space conntrack tcp issue

[Darrell Ball]

Hi Wang

Pls see inline

Thanks Darrell

On 1/1/18, 10:57 PM, "ovs-dev-boun...@openvswitch.org on behalf of 王志克" 
 wrote:

Hi,



I am testing below scenario, and I think there is some issue on TCP 
conntrack sequence number filter.



Scenario:



VM1->Host1-Host2-->VM2



There is SCP file copy below VM1 and VM2, and we configured conntrack. 
During the scp, I restart the openvswitch service (process stop and start), 
then after the restart, I saw the consequence TCP packets are tagged as invalid 
by conntrack and traffic can not be recovered.

I did some debug and found it fails on below check “(ackskew >= 
-MAXACKWINDOW)”. I am wondering should it be “(ackskew >= 
-(MAXACKWINDOW<seqlo - ack;

#define MAXACKWINDOW (0x + 1500)/* 1500 is an arbitrary fudge 
factor */

if (SEQ_GEQ(src->seqhi, end)

/* Last octet inside other's window space */

&& SEQ_GEQ(seq, src->seqlo - (dst->max_win << dws))

/* Retrans: not more than one window back */



&& (ackskew >= -MAXACKWINDOW)

/* Acking not more than one reassembled fragment backwards */

[Darrell] The above specific check looks ok to me; also, I am not convinced 
widening the valid skew is a good idea in the general case.

   Btw, what is the sws value in your case ?


&& (ackskew <= (MAXACKWINDOW << sws))

/* Acking not more than one window forward */

&& ((tcp_flags & TCP_RST) == 0 || orig_seq == src->seqlo

|| (orig_seq == src->seqlo + 1) || (orig_seq + 1 == 
src->seqlo))) {



Details:



   TCP Client Seq   TCP Client ACKTCP Server 
Seq TCP Server ACK

Before the restart:0x69f1536e 0xa3c81999   0xa3ca2d49   
0x69f15302

After the restart(5s later): 0x69f15302 0xa3c81999   0xa3c561e1 
  0x69f15302



As we can see the new seq 0xa3c561e1 (server steped back since previous 
segments are not acked.) is much less than 0xa3c81999 (client keeps sending 
last acked packet), which leads to failed check on conntrack.


[Darrell] Did you see any eventual resets ?; followed by conn timeout ?



I am using OVS2.7.0+dpdk16.11.3



Any thought?



Br,

Wang Zhike

___
dev mailing list
d...@openvswitch.org

https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev=DwIGaQ=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=y-qxAvIT_2KCfecDj8-3VCoLgJ-0NF-mDO_50tx2rcs=asIHHvNQJ8KbNdwwo78o7tz9FsckFUAdWziWIsltDxQ=


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] conn_key_hash change hash arithmetic

[Darrell Ball]

From: "liucheng (J)" <liuchen...@huawei.com>
Date: Thursday, December 14, 2017 at 7:28 PM
To: Darrel Ball <db...@vmware.com>, "ovs-discuss@openvswitch.org" 
<ovs-discuss@openvswitch.org>
Subject: RE: [ovs-discuss] conn_key_hash change hash arithmetic

Thanks for your reply. And my reply as below.

发件人: Darrell Ball [mailto:db...@vmware.com]
发送时间: 2017年12月15日 1:56
收件人: liucheng (J); ovs-discuss@openvswitch.org
主题: Re: [ovs-discuss] conn_key_hash change hash arithmetic



From: 
<ovs-discuss-boun...@openvswitch.org<mailto:ovs-discuss-boun...@openvswitch.org>>
 on behalf of "liucheng (J)" 
<liuchen...@huawei.com<mailto:liuchen...@huawei.com>>
Date: Wednesday, December 13, 2017 at 9:04 AM
To: "ovs-discuss@openvswitch.org<mailto:ovs-discuss@openvswitch.org>" 
<ovs-discuss@openvswitch.org<mailto:ovs-discuss@openvswitch.org>>
Subject: [ovs-discuss] conn_key_hash change hash arithmetic

>> Hello all,
>> I run a test with the user conntrack. And I found if I only change the udp 
>> port, then the hash with function “conn_key_hash” is not balance.

>> [Darrell] You are changing src and dst UDP ports; what algorithm is used to 
>> select the ports ?

[liucheng] UDP src and dst port increase from 1024 to 65530. Using tesgine(a 
packet transmitter) send the packets.


[Darrell] I tried all combinations of just L4 ports (equally) with just 2 IP 
addresses: 192.168.0.1 and 192.168.0.2
 The hash distribution looks good with less than 1% maximum 
difference in occupancy b/w buckets, using worse case single first level bucket.
  Having many first level buckets, as you have done, will be 
undesirable, for obvious reasons.
  The number of first level buckets should be a relatively 
small number.


>> I change the hmap num(ct->buckets) to 4096

>> [Darrell] I assume you refer to CONNTRACK_BUCKETS ?

[liucheng] Yes, CONNTRACK_BUCKETS is 4096.

>> and ct->n_conn_limit to 30,000,000.

>> [Darrell] That is a large number for only varying the L4 ports; don’t you 
>> think ?
>> Do you think this represents a common use case or connection 
>> distribution?

[liucheng] Yes. This is not a common application scenarios.But I try to change 
the ip from 192.168.0.1 to 192.168.0.10, and this problem is still exist.


>> And I print the num of the nodes contained in the hmap’s bucket.
>> As an example, a result looks like below. Most bucket is empty, and some 
>> bucket contain hundreds of nodes;
>> ~hmap 4095 count 4310 mask 4095~~~
>> buket 488 content 367 node
>> buket 1077 content 514 node
>> buket 1118 content 281 node
>> buket 1261 content 423 node
>> buket 1280 content 268 node
>> buket 1603 content 319 node
>> buket 1724 content 352 node
>> buket 2676 content 155 node
>> buket 2993 content 471 node
>> buket 3028 content 325 node
>> buket 3836 content 355 node
>> buket 4060 content 480 node

>> [Darrell] I assume you are referring to ct->buckets; i.e. first level 
>> buckets ?

[liucheng] I mean ctb->connections’s buckets. As it is a hmap, and has “struct 
hmap_node **buckets”. It has “mask + 1 “ buckets. i.e. buckets[488] contain 367 
nodes. As code is below:
for (i = 0; i < CONNTRACK_BUCKETS; i++) {
struct conntrack_bucket *ctb = >buckets[i];
struct conn *conn;
uint64_t count;

ct_lock_lock(>lock);
ds_put_format(, "~hmap %d count %lu mask 
%lu~~~\n",
i, hmap_count(>connections), ctb->connections.mask);
for (j = 0; j <= ctb->connections.mask; j++) {
count = 0;
HMAP_FOR_EACH_IN_BUCKET(conn, node, j, >connections) {
count++;
}
ds_put_format(, "buket %d content %lu node\n", j, count);
}

ct_lock_unlock(>lock);
}

>> Then I change the code in conn_key_hash as the patch. And test result is the 
>> max nodes in one bucket is 12.
>> The num of the bucket contained only one node is 5000542.
>> The num of the bucket contained only two node is 4337097.
>> The num of the bucket contained only three node is 2588535.
>> The num of the bucket contained only four node is 1196063.
>> The num of the bucket contained only five node is 460865.
>> The num of the bucket contained only six node is 155936.
>> The num of the bucket contained only seven node is 48727.
>> Most buckets contain few nodes.

>>  [Darrell] I am assuming you are referring to ct->buckets, still ?
>> 1 of 4096 first level buckets ?

[liucheng] As above say, there is 4096(CONNTRACK_BUCKETS) hmap(

Re: [ovs-discuss] conn_key_hash change hash arithmetic

[Darrell Ball]

From:  on behalf of "liucheng (J)" 

Date: Wednesday, December 13, 2017 at 9:04 AM
To: "ovs-discuss@openvswitch.org" 
Subject: [ovs-discuss] conn_key_hash change hash arithmetic

Hello all,
I run a test with the user conntrack. And I found if I only change the udp 
port, then the hash with function “conn_key_hash” is not balance.

[Darrell] You are changing src and dst UDP ports; what algorithm is used to 
select the ports ?


I change the hmap num(ct->buckets) to 4096

[Darrell] I assume you refer to CONNTRACK_BUCKETS ?


and ct->n_conn_limit to 30,000,000.

[Darrell] That is a large number for only varying the L4 ports; don’t you think 
?
 Do you think this represents a common use case or connection 
distribution?


And I print the num of the nodes contained in the hmap’s bucket.
As an example, a result looks like below. Most bucket is empty, and some bucket 
contain hundreds of nodes;
~hmap 4095 count 4310 mask 4095~~~
buket 488 content 367 node
buket 1077 content 514 node
buket 1118 content 281 node
buket 1261 content 423 node
buket 1280 content 268 node
buket 1603 content 319 node
buket 1724 content 352 node
buket 2676 content 155 node
buket 2993 content 471 node
buket 3028 content 325 node
buket 3836 content 355 node
buket 4060 content 480 node

[Darrell] I assume you are referring to ct->buckets; i.e. first level buckets ?

Then I change the code in conn_key_hash as the patch. And test result is the 
max nodes in one bucket is 12.
The num of the bucket contained only one node is 5000542.
The num of the bucket contained only two node is 4337097.
The num of the bucket contained only three node is 2588535.
The num of the bucket contained only four node is 1196063.
The num of the bucket contained only five node is 460865.
The num of the bucket contained only six node is 155936.
The num of the bucket contained only seven node is 48727.
Most buckets contain few nodes.

[Darrell] I am assuming you are referring to ct->buckets, still ?
 1 of 4096 first level buckets ?




diff --git a/lib/conntrack.c b/lib/conntrack.c
index 6d078f5..3edf809 100644
--- a/lib/conntrack.c
+++ b/lib/conntrack.c
@@ -2034,7 +2034,7 @@ conn_key_hash(const struct conn_key *key, uint32_t basis)
 hdst = ct_endpoint_hash_add(hdst, >dst);

 /* Even if source and destination are swapped the hash will be the same. */
-hash = hsrc ^ hdst;
+hash = hsrc + hdst;

 /* Hash the rest of the key(L3 and L4 types and zone). */
 hash = hash_words((uint32_t *) (>dst + 1),

___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Will fragment be processed in userspace(dpdk) connection track

[Darrell Ball]

Yes
I have done some work here and it will likely be added for 2.9

From:  on behalf of 王嵘 

Date: Tuesday, November 21, 2017 at 4:10 AM
To: "ovs-discuss@openvswitch.org" 
Subject: [ovs-discuss] Will fragment be processed in userspace(dpdk) connection 
track

hi,
 I am using ovs-dpdk now, and find that the fragment  has not been processed 
before the userspace connection track,
which is very necessary for me to use.
And I want to know, whether this function will be added?
Thanks very much.

WangRong
Best Regards.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Problem on creating bridge interface on OVS_DPDK in a VMware VM guest

[Darrell Ball]

On 9/28/17, 10:30 AM, "ovs-discuss-boun...@openvswitch.org on behalf of Darrell 
Ball" <ovs-discuss-boun...@openvswitch.org on behalf of db...@vmware.com> wrote:





On 9/27/17, 8:01 PM, "BALL SUN" <paul...@gmail.com> wrote:



I need some direction on " look into vmxnet3_recv_pkts with gdb"



One link is below


https://urldefense.proofpoint.com/v2/url?u=https-3A__www.cs.rochester.edu_-7Enelson_courses_csc-5F173_review_gdb.html=DwIGaQ=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=SHYVOrhO5vo68iu2mJ-Ct7omQ-KHWOQrXKZBHWeqKUE=l-Sdbh-hsqR8vfX5fHIvgid3MkPvTT6Vfob0ESTFi9Q=
 

probably you can find other better links



also, I am not abke to complie the vmxnet3-usermap, do you have any

step on that?



I have not used vmxnet3, so possibly others have some guidance about this?

I asked about you using vmxnet3-usermap, which you mentioned earlier, 
because your stack

trace was missing some info. and I wondered why.

AFAIK, vmxnet3-usermap is deprecated in favor of vmxnet3, but others might 
know more about this?


Meaning - have you tried adding the corresponding vmxnet3 module into the kernel
eg)
darrell@prmh-nsx-perf-server135:~$ sudo modprobe vmxnet3
darrell@prmh-nsx-perf-server135:~$ lsmod |  grep vmxnet3
vmxnet361440  0 

and then binding the vmxnet3 vnic, which in your case would be something like:

…../tools/dpdk-devbind.py --bind=vmxnet3 :03:00.0


    On Thu, Sep 28, 2017 at 12:36 AM, Darrell Ball <db...@vmware.com> wrote:

>

>

> On 9/26/17, 11:47 PM, "BALL SUN" <paul...@gmail.com> wrote:

>

> tried on 17.05.2, seems got the same problem.

>

>

> [Darrell]

> Can you look into vmxnet3_recv_pkts with gdb to see where the issue?

>

> In addition, you mentioned in an earlier thread about

> 
https://urldefense.proofpoint.com/v2/url?u=http-3A__dpdk.org_doc_vmxnet3-2Dusermap=DwIFaQ=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=mWUJAHqBJE53HZ9jsgJQ20r0YZAWMmFmzwD68avgNmo=tIl6tqL1YYkJOTJSzIJzXIQmHCsAUIhwhLI3WA9H3xo=
 

> I assume you are already using that driver now?











>

>

>

> # gdb /usr/local/sbin/ovs-vswitchd coredump

> GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-94.el7

> Copyright (C) 2013 Free Software Foundation, Inc.

> License GPLv3+: GNU GPL version 3 or later 
<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnu.org_licenses_gpl.html=DwIFaQ=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=AccF7D_1ucmacdhBYtneFmWraGWha6yRG9H7_2p_Oik=zdjTw6g4SPW8CaLqwVobBuIFl_6gZ7e13U4Vr0ZG7gQ=>

> This is free software: you are free to change and redistribute it.

> There is NO WARRANTY, to the extent permitted by law.  Type "show 
copying"

> and "show warranty" for details.

> This GDB was configured as "x86_64-redhat-linux-gnu".

> For bug reporting instructions, please see:

> 
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.gnu.org_software_gdb_bugs_=DwIFaQ=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=AccF7D_1ucmacdhBYtneFmWraGWha6yRG9H7_2p_Oik=MnzJQxJz9eucCrn96S5RPQ0WkdldccSBcaBs0t3HQro=>...











> Reading symbols from /usr/local/sbin/ovs-vswitchd...done.

> [New LWP 2610]

> [New LWP 2607]

> [New LWP 2599]

> [New LWP 2601]

> [New LWP 2608]

> [New LWP 2606]

> [New LWP 2603]

> [New LWP 2605]

> [New LWP 2604]

> [New LWP 2602]

> [New LWP 2609]

> [Thread debugging using libthread_db enabled]

> Using host libthread_db library "/lib64/libthread_db.so.1".

> Core was generated by `/usr/local/sbin/ovs-vswitchd

> --pidfile=/root/run/ovs-vswitchd.pid'.

> Program terminated with signal 11, Segmentation fault.

> #0  0x00686165 in vmxnet3_recv_pkts ()

> (gdb) bt

> #0  0x00686165 in vmxnet3_recv_pkts ()

> #1  0x007cbad4 in rte_eth_rx_burst (nb_pkts=32,

> rx_pkts=0x7fa2c67fb7b0, queue_id=0, port_id=0 '\000')

> at 
/data1/build/dpdk-stable-17.05.

Re: [ovs-discuss] Problem on creating bridge interface on OVS_DPDK in a VMware VM guest

[Darrell Ball]

On 9/27/17, 8:01 PM, "BALL SUN" <paul...@gmail.com> wrote:

I need some direction on " look into vmxnet3_recv_pkts with gdb"

One link is below
https://www.cs.rochester.edu/~nelson/courses/csc_173/review/gdb.html
probably you can find other better links

also, I am not abke to complie the vmxnet3-usermap, do you have any
step on that?

I have not used vmxnet3, so possibly others have some guidance about this?
I asked about you using vmxnet3-usermap, which you mentioned earlier, because 
your stack
trace was missing some info. and I wondered why.
AFAIK, vmxnet3-usermap is deprecated in favor of vmxnet3, but others might know 
more about this?

On Thu, Sep 28, 2017 at 12:36 AM, Darrell Ball <db...@vmware.com> wrote:
>
>
> On 9/26/17, 11:47 PM, "BALL SUN" <paul...@gmail.com> wrote:
>
> tried on 17.05.2, seems got the same problem.
>
>
> [Darrell]
> Can you look into vmxnet3_recv_pkts with gdb to see where the issue?
>
> In addition, you mentioned in an earlier thread about
> 
https://urldefense.proofpoint.com/v2/url?u=http-3A__dpdk.org_doc_vmxnet3-2Dusermap=DwIFaQ=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=mWUJAHqBJE53HZ9jsgJQ20r0YZAWMmFmzwD68avgNmo=tIl6tqL1YYkJOTJSzIJzXIQmHCsAUIhwhLI3WA9H3xo=
 
> I assume you are already using that driver now?





>
>
>
> # gdb /usr/local/sbin/ovs-vswitchd coredump
> GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-94.el7
> Copyright (C) 2013 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnu.org_licenses_gpl.html=DwIFaQ=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=AccF7D_1ucmacdhBYtneFmWraGWha6yRG9H7_2p_Oik=zdjTw6g4SPW8CaLqwVobBuIFl_6gZ7e13U4Vr0ZG7gQ=>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show 
copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-redhat-linux-gnu".
> For bug reporting instructions, please see:
> 
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.gnu.org_software_gdb_bugs_=DwIFaQ=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=AccF7D_1ucmacdhBYtneFmWraGWha6yRG9H7_2p_Oik=MnzJQxJz9eucCrn96S5RPQ0WkdldccSBcaBs0t3HQro=>...
> Reading symbols from /usr/local/sbin/ovs-vswitchd...done.
> [New LWP 2610]
> [New LWP 2607]
> [New LWP 2599]
> [New LWP 2601]
> [New LWP 2608]
> [New LWP 2606]
> [New LWP 2603]
> [New LWP 2605]
> [New LWP 2604]
> [New LWP 2602]
> [New LWP 2609]
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib64/libthread_db.so.1".
> Core was generated by `/usr/local/sbin/ovs-vswitchd
> --pidfile=/root/run/ovs-vswitchd.pid'.
> Program terminated with signal 11, Segmentation fault.
> #0  0x00686165 in vmxnet3_recv_pkts ()
> (gdb) bt
> #0  0x00686165 in vmxnet3_recv_pkts ()
> #1  0x007cbad4 in rte_eth_rx_burst (nb_pkts=32,
> rx_pkts=0x7fa2c67fb7b0, queue_id=0, port_id=0 '\000')
> at 
/data1/build/dpdk-stable-17.05.2/x86_64-native-linuxapp-gcc/include/rte_ethdev.h:2774
> #2  netdev_dpdk_rxq_recv (rxq=, batch=0x7fa2c67fb7a0)
> at lib/netdev-dpdk.c:1664
> #3  0x00729641 in netdev_rxq_recv (rx=rx@entry=0x7fa2f424a800,
> batch=batch@entry=0x7fa2c67fb7a0) at lib/netdev.c:701
> #4  0x00705bde in dp_netdev_process_rxq_port
> (pmd=pmd@entry=0x216e550, rx=0x7fa2f424a800, port_no=1) at
> lib/dpif-netdev.c:3114
> #5  0x00705e46 in pmd_thread_main (f_=) at
> lib/dpif-netdev.c:3854
> #6  0x00779584 in ovsthread_wrapper (aux_=) at
> lib/ovs-thread.c:348
> #7  0x7fa2f7d55dc5 in start_thread (arg=0x7fa2c67fc700) at
> pthread_create.c:308
> #8  0x00007fa2f733973d in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:113
>
> On Wed, Sep 27, 2017 at 2:31 PM, BALL SUN <paul...@gmail.com> wrote:
> > so, it is suggested to try on  17.05.2?
> >
> > On Wed, Sep 27, 2017 at 12:23 PM, Darrell Ball <db...@vmware.com> 
wrote:
> >>
> >>
> >> On 9/26/17, 9:19 PM, "ovs-discuss-boun...@openvswitch.org on 
behalf of Darrell Ball" <ovs-discuss-boun...@openvswitch.or

Re: [ovs-discuss] Problem on creating bridge interface on OVS_DPDK in a VMware VM guest

[Darrell Ball]

On 9/26/17, 9:19 PM, "ovs-discuss-boun...@openvswitch.org on behalf of Darrell 
Ball" <ovs-discuss-boun...@openvswitch.org on behalf of db...@vmware.com> wrote:





On 9/26/17, 8:26 PM, "BALL SUN" <paul...@gmail.com> wrote:



below is the backtrace



# gdb /usr/local/sbin/ovs-vswitchd coredump

GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-94.el7

Copyright (C) 2013 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later 
<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnu.org_licenses_gpl.html=DwIFaQ=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=wa0yd0R7cqOWvjJOu1dSW07R0zHnvfzd9YivtLlPVpc=vsFbzhYP_z61VhdI1w-dlGINFOOOMgkZjMhs4SjvOM8=>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.  Type "show 
copying"

and "show warranty" for details.

This GDB was configured as "x86_64-redhat-linux-gnu".

For bug reporting instructions, please see:


<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.gnu.org_software_gdb_bugs_=DwIFaQ=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=wa0yd0R7cqOWvjJOu1dSW07R0zHnvfzd9YivtLlPVpc=MOrbM5qkYI0I-SbDgsQ3lYwkcqQcDD64Vez202bqEng=>...

Reading symbols from /usr/local/sbin/ovs-vswitchd...done.

[New LWP 2716]

[New LWP 2707]

[New LWP 2712]

[New LWP 2711]

[New LWP 2713]

[New LWP 2708]

[New LWP 2714]

[New LWP 2715]

[New LWP 2706]

[New LWP 2710]

[New LWP 2709]

[Thread debugging using libthread_db enabled]

Using host libthread_db library "/lib64/libthread_db.so.1".

Core was generated by `/usr/local/sbin/ovs-vswitchd

--pidfile=/root/run/ovs-vswitchd.pid'.

Program terminated with signal 11, Segmentation fault.

#0  0x0068ad75 in vmxnet3_recv_pkts ()

(gdb) next

The program is not being run.

(gdb) bt

#0  0x0068ad75 in vmxnet3_recv_pkts ()



hmm, interesting signature

maybe you want to drill down on this function to see where the seg fault 
was.

Btw, ovs-dpdk master/2.8 just moved to 17.05.2 and I see a release note

for vmxnet3 here


https://urldefense.proofpoint.com/v2/url?u=http-3A__dpdk.org_doc_guides-2D17.05_rel-5Fnotes_release-5F17-5F05.html=DwIGaQ=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=qUaugJc_cpKZ0k9zQTz2QTAB2P5PlyAq5c_cc5Sanr0=4sfd93KUta1pbiZYJxgtDgKvYc0gUKKLiF9jb_Zttto=
 

“net/vmxnet3: fix filtering on promiscuous disabling
net/vmxnet3: fix receive queue memory leak“






#1  0x007d2252 in rte_eth_rx_burst (nb_pkts=32,

rx_pkts=0x7f3e4bffe7b0, queue_id=0, port_id=0 '\000')

at /data1/build/dpdk-stable- rte_eth_rx_burst 
/x86_64-native-linuxapp-gcc/include/rte_ethdev.h:2774

#2  netdev_dpdk_rxq_recv (rxq=, batch=0x7f3e4bffe7a0)

at lib/netdev-dpdk.c:1664

#3  0x0072e571 in netdev_rxq_recv (rx=rx@entry=0x7f3e5cc4a680,

batch=batch@entry=0x7f3e4bffe7a0) at lib/netdev.c:701

#4  0x0070ab0e in dp_netdev_process_rxq_port

(pmd=pmd@entry=0x29e5e20, rx=0x7f3e5cc4a680, port_no=1) at

lib/dpif-netdev.c:3114

#5  0x0070ad76 in pmd_thread_main (f_=) at

lib/dpif-netdev.c:3854

#6  0x0077e4b4 in ovsthread_wrapper (aux_=) at

lib/ovs-thread.c:348

#7  0x7f3e5fe07dc5 in start_thread (arg=0x7f3e4bfff700) at

pthread_create.c:308

#8  0x7f3e5f3eb73d in clone () at

../sysdeps/unix/sysv/linux/x86_64/clone.S:113

(gdb) bt



On Wed, Sep 27, 2017 at 9:15 AM, Sun Paul <paul...@gmail.com> wrote:

> Hi

>

> I am trying to decode the core dump, however, I am not familiar with

> the command to run the debug, can you please provide the steps?

>

> the linux version is CentOS7 (3.10.0-514.el7.x86_64), and we currently

> try to run the OVS+DPDK as a VMware guest. the expected topology would

> be connect another two nodes with this OVS+DPDK vm.

>

> On Wed, Sep 27, 2017 at 5:13 AM, Darrell Ball <db...@vmware.com> 
wrote:

>>

>>

>> On 9/25/17, 11:18 PM, "Sun Paul" <paul...@gmail.com> wrote:

>>

>> hi

Re: [ovs-discuss] Problem on creating bridge interface on OVS_DPDK in a VMware VM guest

[Darrell Ball]

On 9/26/17, 8:26 PM, "BALL SUN" <paul...@gmail.com> wrote:

below is the backtrace

# gdb /usr/local/sbin/ovs-vswitchd coredump
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-94.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnu.org_licenses_gpl.html=DwIFaQ=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=wa0yd0R7cqOWvjJOu1dSW07R0zHnvfzd9YivtLlPVpc=vsFbzhYP_z61VhdI1w-dlGINFOOOMgkZjMhs4SjvOM8=
 >
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:

<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.gnu.org_software_gdb_bugs_=DwIFaQ=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=wa0yd0R7cqOWvjJOu1dSW07R0zHnvfzd9YivtLlPVpc=MOrbM5qkYI0I-SbDgsQ3lYwkcqQcDD64Vez202bqEng=
 >...
Reading symbols from /usr/local/sbin/ovs-vswitchd...done.
[New LWP 2716]
[New LWP 2707]
[New LWP 2712]
[New LWP 2711]
[New LWP 2713]
[New LWP 2708]
[New LWP 2714]
[New LWP 2715]
[New LWP 2706]
[New LWP 2710]
[New LWP 2709]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/usr/local/sbin/ovs-vswitchd
--pidfile=/root/run/ovs-vswitchd.pid'.
Program terminated with signal 11, Segmentation fault.
#0  0x0068ad75 in vmxnet3_recv_pkts ()
(gdb) next
The program is not being run.
(gdb) bt
#0  0x0068ad75 in vmxnet3_recv_pkts ()

hmm, interesting signature
maybe you want to drill down on this function to see where the seg fault was.
Btw, ovs-dpdk master/2.8 just moved to 17.05.2 and I see a release note
for vmxnet3 here
http://dpdk.org/doc/guides-17.05/rel_notes/release_17_05.html
“Added vmxnet3 version 3 support.

Added support for vmxnet3 version 3 which includes several performance 
enhancements such as configurable Tx data ring, Receive Data Ring, and the 
ability to register memory regions.”

Maybe it was meant to say “vmxnet version 3” == vmxnet3 ?


#1  0x007d2252 in rte_eth_rx_burst (nb_pkts=32,
rx_pkts=0x7f3e4bffe7b0, queue_id=0, port_id=0 '\000')
at /data1/build/dpdk-stable- rte_eth_rx_burst 
/x86_64-native-linuxapp-gcc/include/rte_ethdev.h:2774
#2  netdev_dpdk_rxq_recv (rxq=, batch=0x7f3e4bffe7a0)
at lib/netdev-dpdk.c:1664
#3  0x0072e571 in netdev_rxq_recv (rx=rx@entry=0x7f3e5cc4a680,
batch=batch@entry=0x7f3e4bffe7a0) at lib/netdev.c:701
#4  0x0070ab0e in dp_netdev_process_rxq_port
(pmd=pmd@entry=0x29e5e20, rx=0x7f3e5cc4a680, port_no=1) at
lib/dpif-netdev.c:3114
#5  0x0070ad76 in pmd_thread_main (f_=) at
lib/dpif-netdev.c:3854
#6  0x0077e4b4 in ovsthread_wrapper (aux_=) at
lib/ovs-thread.c:348
#7  0x7f3e5fe07dc5 in start_thread (arg=0x7f3e4bfff700) at
pthread_create.c:308
#8  0x7f3e5f3eb73d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:113
(gdb) bt

On Wed, Sep 27, 2017 at 9:15 AM, Sun Paul <paul...@gmail.com> wrote:
> Hi
>
> I am trying to decode the core dump, however, I am not familiar with
> the command to run the debug, can you please provide the steps?
>
> the linux version is CentOS7 (3.10.0-514.el7.x86_64), and we currently
> try to run the OVS+DPDK as a VMware guest. the expected topology would
> be connect another two nodes with this OVS+DPDK vm.
>
> On Wed, Sep 27, 2017 at 5:13 AM, Darrell Ball <db...@vmware.com> wrote:
>>
>>
>> On 9/25/17, 11:18 PM, "Sun Paul" <paul...@gmail.com> wrote:
>>
>> hi
>>
>> I am trying to use the vmxnet3 (:03:00.0) as the dpdk0 interface.
>>
>> # ./dpdk-devbind.py --status
>>
>> Network devices using DPDK-compatible driver
>> 
>> :03:00.0 'VMXNET3 Ethernet Controller 07b0' drv=igb_uio unused=
>>
>> Network devices using kernel driver
>> ===
>> :02:01.0 '82545EM Gigabit Ethernet Controller (Copper) 100f'
>> if=ens33 drv=e1000 unused=igb_uio *Active*
>>
>> Other Network devices
>> =
>> :0b:00.0 'VMXNET3 Ethernet Controller 07b0' unused=igb_uio
>>
>>
>> so, when I try to execute "ovs-vsctl add-port g1 dpdk0 -- set
   

Re: [ovs-discuss] IPv4 address support for port configuration in OVS 2.8.0 version

[Darrell Ball]

Take a look at netdev_tnl_ip_build_header(…), for example.

From:  on behalf of Ranjith Kumar D 

Date: Monday, September 25, 2017 at 11:37 PM
To: "disc...@openvswitch.org" 
Subject: [ovs-discuss] IPv4 address support for port configuration in OVS 2.8.0 
version

Hello All,

I had recently downloaded the OVS 2.8.0 version code and was performing the 
code walkthrough for ovs-vsctl command handling for adding port to bridge. I 
see that structures related to port configuration takes only IPv6 address. 
Hence kindly let me know whether we will be able to set the interface of a port 
in a bridge with IPv4 remote and local IP.


ovs-vsctl set interface  type=gre/rte  
option:remote_ip=172.20.1.1 option:local_ip=172.24.1.0

Code snippet under concern is

OVS 2.4 version
--
/* Configuration specific to tunnels. */
struct netdev_tunnel_config {
bool in_key_present;
bool in_key_flow;
ovs_be64 in_key;

bool out_key_present;
bool out_key_flow;
ovs_be64 out_key;

ovs_be16 dst_port;

bool ip_src_flow;
bool ip_dst_flow;
ovs_be32 ip_src;
ovs_be32 ip_dst;

uint32_t exts;

uint8_t ttl;
bool ttl_inherit;

uint8_t tos;
bool tos_inherit;

bool csum;
bool ipsec;
bool dont_fragment;
};



OVS 2.8 Version
--
* Configuration specific to tunnels. */
struct netdev_tunnel_config {
bool in_key_present;
bool in_key_flow;
ovs_be64 in_key;

bool out_key_present;
bool out_key_flow;
ovs_be64 out_key;

ovs_be16 dst_port;

bool ip_src_flow;
bool ip_dst_flow;
struct in6_addr ipv6_src;
struct in6_addr ipv6_dst;

uint32_t exts;
bool set_egress_pkt_mark;
uint32_t egress_pkt_mark;

uint8_t ttl;
bool ttl_inherit;

uint8_t tos;
bool tos_inherit;

bool csum;
bool dont_fragment;
enum netdev_pt_mode pt_mode;
};

Regards,
Ranjith
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Problem on creating bridge interface on OVS_DPDK in a VMware VM guest

[Darrell Ball]

On 9/25/17, 9:26 PM, "Sun Paul" <paul...@gmail.com> wrote:

we are evauluating the DPDK on VMXNET3 , is sit supported in the VMware 
guest?

I see what you are doing now; I think it should be supported.
What driver are you using to bind the “vmxnet3 nic” ?
Probably you should provide all the steps you are using and your environment.



On Tue, Sep 26, 2017 at 12:09 PM, Darrell Ball <db...@vmware.com> wrote:
> Do you have a hard requirement to use vmxnet3 ?
> What are you requirements otherwise ?
>
>
> On 9/25/17, 9:06 PM, "ovs-discuss-boun...@openvswitch.org on behalf of 
Darrell Ball" <ovs-discuss-boun...@openvswitch.org on behalf of 
db...@vmware.com> wrote:
>
>
>
> On 9/25/17, 8:31 PM, "Sun Paul" <paul...@gmail.com> wrote:
>
> Hi
>
> thank for the reply. but can you explain what I should do?
>
>
> Do you have a hard requirement to use ESXi and vmxnet3 ?
>     What are you requirements otherwise ?
>
>
>
> On Tue, Sep 26, 2017 at 3:18 AM, Darrell Ball <db...@vmware.com> 
wrote:
> >
> >
> > On 9/25/17, 2:53 AM, "ovs-discuss-boun...@openvswitch.org on 
behalf of Sun Paul" <ovs-discuss-boun...@openvswitch.org on behalf of 
paul...@gmail.com> wrote:
> >
> > Hi
> >
> > I am trying to have a OVS+DPDK setup on a VM guest in Vmware
> > environment. the network adapter type for the dpdk is 
vmxnet3.
> >
> > The present support for guest connectivity for OVS-DPDK is here:
> > 
https://urldefense.proofpoint.com/v2/url?u=http-3A__docs.openvswitch.org_en_latest_topics_dpdk_vhost-2Duser_=DwIFaQ=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=U9YEU77bZamqSg208ehS8-3M4sgEVZoZE9yILybkOuU=6iVy8pqpuoo_1QAliEi37GLAiW2wEkUl5UGZMf7l5WA=
> >
> >
> > when I am trying to add-port on it, it failed. any idea?
> >
> > Sep 26 17:51:57 plocalhost ovs-vswitchd:
> > 2017-09-26T09:51:57Z|00058|netdev_dpdk|ERR|Interface dpdk0 
MTU (1500)
> > setup error: Operation not supported
> > Sep 26 17:51:57 plocalhost ovs-vswitchd:
> > 2017-09-26T09:51:57Z|00059|netdev_dpdk|ERR|Interface 
dpdk0(rxq:1
> > txq:2) configure error: Operation not supported
> >
> >
> >
> > the full log is shown below.
> >
> > Sep 26 17:51:26 plocalhost ovs-vswitchd:
> > 
2017-09-26T09:51:26Z|00051|ofproto_dpif|INFO|netdev@ovs-netdev:
> > Datapath supports ct_orig_tuple6
> > Sep 26 17:51:26 plocalhost ovs-vswitchd[2624]:
> > ovs|00039|ofproto_dpif|INFO|netdev@ovs-netdev: MPLS label 
stack length
> > probed as 3
> > Sep 26 17:51:26 plocalhost ovs-vswitchd[2624]:
> > ovs|00040|ofproto_dpif|INFO|netdev@ovs-netdev: Datapath 
supports
> > truncate action
> > Sep 26 17:51:26 plocalhost ovs-vswitchd[2624]:
> > ovs|00041|ofproto_dpif|INFO|netdev@ovs-netdev: Datapath 
supports
> > unique flow ids
> > Sep 26 17:51:26 plocalhost ovs-vswitchd[2624]:
> > ovs|00042|ofproto_dpif|INFO|netdev@ovs-netdev: Datapath 
supports clone
> > action
> > Sep 26 17:51:26 plocalhost ovs-vswitchd[2624]:
> > ovs|00043|ofproto_dpif|INFO|netdev@ovs-netdev: Max sample 
nesting
> > level probed as 10
> > Sep 26 17:51:26 plocalhost ovs-vswitchd[2624]:
> > ovs|00044|ofproto_dpif|INFO|netdev@ovs-netdev: Datapath 
supports
> > eventmask in conntrack action
> > Sep 26 17:51:26 plocalhost ovs-vswitchd[2624]:
> > ovs|00045|ofproto_dpif|INFO|netdev@ovs-netdev: Datapath 
supports
> > ct_state
> > Sep 26 17:51:26 plocalhost ovs-vswitchd[2624]:
> > ovs|00046|ofproto_dpif|INFO|netdev@ovs-netdev: Datapath 
supports
> > ct_zone
> > Sep 26 17:51:26 plocalhost ovs-vswitchd[2624]:
> > ovs|00047|ofproto_dpif|INFO|netdev@ovs-netdev: Datapath 
supports
> > ct_mark
> > Sep 26 17:51:26 plo

Re: [ovs-discuss] Problem on creating bridge interface on OVS_DPDK in a VMware VM guest

[Darrell Ball]

On 9/25/17, 8:31 PM, "Sun Paul" <paul...@gmail.com> wrote:

Hi

thank for the reply. but can you explain what I should do?


Do you have a hard requirement to use ESXi and vmxnet3 ?
What are you requirements otherwise ?



On Tue, Sep 26, 2017 at 3:18 AM, Darrell Ball <db...@vmware.com> wrote:
>
>
> On 9/25/17, 2:53 AM, "ovs-discuss-boun...@openvswitch.org on behalf of 
Sun Paul" <ovs-discuss-boun...@openvswitch.org on behalf of paul...@gmail.com> 
wrote:
>
> Hi
>
> I am trying to have a OVS+DPDK setup on a VM guest in Vmware
> environment. the network adapter type for the dpdk is vmxnet3.
>
> The present support for guest connectivity for OVS-DPDK is here:
> 
https://urldefense.proofpoint.com/v2/url?u=http-3A__docs.openvswitch.org_en_latest_topics_dpdk_vhost-2Duser_=DwIFaQ=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=U9YEU77bZamqSg208ehS8-3M4sgEVZoZE9yILybkOuU=6iVy8pqpuoo_1QAliEi37GLAiW2wEkUl5UGZMf7l5WA=
 
>
>
> when I am trying to add-port on it, it failed. any idea?
>
> Sep 26 17:51:57 plocalhost ovs-vswitchd:
> 2017-09-26T09:51:57Z|00058|netdev_dpdk|ERR|Interface dpdk0 MTU (1500)
> setup error: Operation not supported
> Sep 26 17:51:57 plocalhost ovs-vswitchd:
> 2017-09-26T09:51:57Z|00059|netdev_dpdk|ERR|Interface dpdk0(rxq:1
> txq:2) configure error: Operation not supported
>
>
>
> the full log is shown below.
>
> Sep 26 17:51:26 plocalhost ovs-vswitchd:
> 2017-09-26T09:51:26Z|00051|ofproto_dpif|INFO|netdev@ovs-netdev:
> Datapath supports ct_orig_tuple6
> Sep 26 17:51:26 plocalhost ovs-vswitchd[2624]:
> ovs|00039|ofproto_dpif|INFO|netdev@ovs-netdev: MPLS label stack length
> probed as 3
> Sep 26 17:51:26 plocalhost ovs-vswitchd[2624]:
> ovs|00040|ofproto_dpif|INFO|netdev@ovs-netdev: Datapath supports
> truncate action
> Sep 26 17:51:26 plocalhost ovs-vswitchd[2624]:
> ovs|00041|ofproto_dpif|INFO|netdev@ovs-netdev: Datapath supports
> unique flow ids
> Sep 26 17:51:26 plocalhost ovs-vswitchd[2624]:
> ovs|00042|ofproto_dpif|INFO|netdev@ovs-netdev: Datapath supports clone
> action
> Sep 26 17:51:26 plocalhost ovs-vswitchd[2624]:
> ovs|00043|ofproto_dpif|INFO|netdev@ovs-netdev: Max sample nesting
> level probed as 10
> Sep 26 17:51:26 plocalhost ovs-vswitchd[2624]:
> ovs|00044|ofproto_dpif|INFO|netdev@ovs-netdev: Datapath supports
> eventmask in conntrack action
> Sep 26 17:51:26 plocalhost ovs-vswitchd[2624]:
> ovs|00045|ofproto_dpif|INFO|netdev@ovs-netdev: Datapath supports
> ct_state
> Sep 26 17:51:26 plocalhost ovs-vswitchd[2624]:
> ovs|00046|ofproto_dpif|INFO|netdev@ovs-netdev: Datapath supports
> ct_zone
> Sep 26 17:51:26 plocalhost ovs-vswitchd[2624]:
> ovs|00047|ofproto_dpif|INFO|netdev@ovs-netdev: Datapath supports
> ct_mark
> Sep 26 17:51:26 plocalhost ovs-vswitchd[2624]:
> ovs|00048|ofproto_dpif|INFO|netdev@ovs-netdev: Datapath supports
> ct_label
> Sep 26 17:51:26 plocalhost ovs-vswitchd[2624]:
> ovs|00049|ofproto_dpif|INFO|netdev@ovs-netdev: Datapath supports
> ct_state_nat
> Sep 26 17:51:26 plocalhost ovs-vswitchd[2624]:
> ovs|00050|ofproto_dpif|INFO|netdev@ovs-netdev: Datapath supports
> ct_orig_tuple
> Sep 26 17:51:26 plocalhost ovs-vswitchd[2624]:
> ovs|00051|ofproto_dpif|INFO|netdev@ovs-netdev: Datapath supports
> ct_orig_tuple6
> Sep 26 17:51:26 plocalhost ovs-vswitchd:
> 2017-09-26T09:51:26Z|00052|bridge|INFO|bridge c1: added interface c1
> on port 65534
> Sep 26 17:51:26 plocalhost ovs-vswitchd[2624]:
> ovs|00052|bridge|INFO|bridge c1: added interface c1 on port 65534
> Sep 26 17:51:26 plocalhost kernel: device c1 entered promiscuous mode
> Sep 26 17:51:26 plocalhost ovs-vswitchd:
> 2017-09-26T09:51:26Z|00053|bridge|INFO|bridge c1: using datapath ID
> 76ff8ff75d4e
> Sep 26 17:51:26 plocalhost ovs-vswitchd[2624]:
> ovs|00053|bridge|INFO|bridge c1: using datapath ID 76ff8ff75d4e
> Sep 26 17:51:26 plocalhost ovs-vswitchd:
> 2017-09-26T09:51:26Z|00054|connmgr|INFO|c1: added service controller
> "punix:/usr/local/var/run/openvswitch/c1.mgmt"
> Sep 26 17:51:26 plocalhost ovs-vswitchd[2624]:
> ovs|00054|connmgr|INFO|c1: added service controller
> "

Re: [ovs-discuss] Problem on creating bridge interface on OVS_DPDK in a VMware VM guest

[Darrell Ball]

On 9/25/17, 2:53 AM, "ovs-discuss-boun...@openvswitch.org on behalf of Sun 
Paul"  
wrote:

Hi

I am trying to have a OVS+DPDK setup on a VM guest in Vmware
environment. the network adapter type for the dpdk is vmxnet3.

The present support for guest connectivity for OVS-DPDK is here:
http://docs.openvswitch.org/en/latest/topics/dpdk/vhost-user/


when I am trying to add-port on it, it failed. any idea?

Sep 26 17:51:57 plocalhost ovs-vswitchd:
2017-09-26T09:51:57Z|00058|netdev_dpdk|ERR|Interface dpdk0 MTU (1500)
setup error: Operation not supported
Sep 26 17:51:57 plocalhost ovs-vswitchd:
2017-09-26T09:51:57Z|00059|netdev_dpdk|ERR|Interface dpdk0(rxq:1
txq:2) configure error: Operation not supported



the full log is shown below.

Sep 26 17:51:26 plocalhost ovs-vswitchd:
2017-09-26T09:51:26Z|00051|ofproto_dpif|INFO|netdev@ovs-netdev:
Datapath supports ct_orig_tuple6
Sep 26 17:51:26 plocalhost ovs-vswitchd[2624]:
ovs|00039|ofproto_dpif|INFO|netdev@ovs-netdev: MPLS label stack length
probed as 3
Sep 26 17:51:26 plocalhost ovs-vswitchd[2624]:
ovs|00040|ofproto_dpif|INFO|netdev@ovs-netdev: Datapath supports
truncate action
Sep 26 17:51:26 plocalhost ovs-vswitchd[2624]:
ovs|00041|ofproto_dpif|INFO|netdev@ovs-netdev: Datapath supports
unique flow ids
Sep 26 17:51:26 plocalhost ovs-vswitchd[2624]:
ovs|00042|ofproto_dpif|INFO|netdev@ovs-netdev: Datapath supports clone
action
Sep 26 17:51:26 plocalhost ovs-vswitchd[2624]:
ovs|00043|ofproto_dpif|INFO|netdev@ovs-netdev: Max sample nesting
level probed as 10
Sep 26 17:51:26 plocalhost ovs-vswitchd[2624]:
ovs|00044|ofproto_dpif|INFO|netdev@ovs-netdev: Datapath supports
eventmask in conntrack action
Sep 26 17:51:26 plocalhost ovs-vswitchd[2624]:
ovs|00045|ofproto_dpif|INFO|netdev@ovs-netdev: Datapath supports
ct_state
Sep 26 17:51:26 plocalhost ovs-vswitchd[2624]:
ovs|00046|ofproto_dpif|INFO|netdev@ovs-netdev: Datapath supports
ct_zone
Sep 26 17:51:26 plocalhost ovs-vswitchd[2624]:
ovs|00047|ofproto_dpif|INFO|netdev@ovs-netdev: Datapath supports
ct_mark
Sep 26 17:51:26 plocalhost ovs-vswitchd[2624]:
ovs|00048|ofproto_dpif|INFO|netdev@ovs-netdev: Datapath supports
ct_label
Sep 26 17:51:26 plocalhost ovs-vswitchd[2624]:
ovs|00049|ofproto_dpif|INFO|netdev@ovs-netdev: Datapath supports
ct_state_nat
Sep 26 17:51:26 plocalhost ovs-vswitchd[2624]:
ovs|00050|ofproto_dpif|INFO|netdev@ovs-netdev: Datapath supports
ct_orig_tuple
Sep 26 17:51:26 plocalhost ovs-vswitchd[2624]:
ovs|00051|ofproto_dpif|INFO|netdev@ovs-netdev: Datapath supports
ct_orig_tuple6
Sep 26 17:51:26 plocalhost ovs-vswitchd:
2017-09-26T09:51:26Z|00052|bridge|INFO|bridge c1: added interface c1
on port 65534
Sep 26 17:51:26 plocalhost ovs-vswitchd[2624]:
ovs|00052|bridge|INFO|bridge c1: added interface c1 on port 65534
Sep 26 17:51:26 plocalhost kernel: device c1 entered promiscuous mode
Sep 26 17:51:26 plocalhost ovs-vswitchd:
2017-09-26T09:51:26Z|00053|bridge|INFO|bridge c1: using datapath ID
76ff8ff75d4e
Sep 26 17:51:26 plocalhost ovs-vswitchd[2624]:
ovs|00053|bridge|INFO|bridge c1: using datapath ID 76ff8ff75d4e
Sep 26 17:51:26 plocalhost ovs-vswitchd:
2017-09-26T09:51:26Z|00054|connmgr|INFO|c1: added service controller
"punix:/usr/local/var/run/openvswitch/c1.mgmt"
Sep 26 17:51:26 plocalhost ovs-vswitchd[2624]:
ovs|00054|connmgr|INFO|c1: added service controller
"punix:/usr/local/var/run/openvswitch/c1.mgmt"
Sep 26 17:51:57 plocalhost ovs-vsctl: ovs|1|vsctl|INFO|Called as
ovs-vsctl add-port c1 dpdk0 -- set Interface dpdk0 type=dpdk
options:dpdk-devargs=:03:00.0
Sep 26 17:51:57 plocalhost ovs-vswitchd:
2017-09-26T09:51:57Z|00055|dpif_netdev|INFO|PMD thread on numa_id: 0,
core id:  0 created.
Sep 26 17:51:57 plocalhost ovs-vswitchd[2624]:
ovs|00055|dpif_netdev|INFO|PMD thread on numa_id: 0, core id:  0
created.
Sep 26 17:51:57 plocalhost ovs-vswitchd:
2017-09-26T09:51:57Z|00056|dpif_netdev|INFO|There are 1 pmd threads on
numa node 0
Sep 26 17:51:57 plocalhost ovs-vswitchd[2624]:
ovs|00056|dpif_netdev|INFO|There are 1 pmd threads on numa node 0
Sep 26 17:51:57 plocalhost ovs-vswitchd[2624]:
ovs|00057|netdev_dpdk|WARN|Rx checksum offload is not supported on
port 0
Sep 26 17:51:57 plocalhost ovs-vswitchd:
2017-09-26T09:51:57Z|00057|netdev_dpdk|WARN|Rx checksum offload is not
supported on port 0
Sep 26 17:51:57 plocalhost ovs-vswitchd:
2017-09-26T09:51:57Z|00058|netdev_dpdk|ERR|Interface dpdk0 MTU (1500)
setup error: Operation not supported
Sep 26 17:51:57 plocalhost ovs-vswitchd:

Re: [ovs-discuss] [ovs-dev] adding dpdk ports sharing same pci address to ovs-dpdk bridge

[Darrell Ball]

On 9/19/17, 8:22 AM, "Loftus, Ciara" <ciara.lof...@intel.com> wrote:

> On 09/19/2017 08:58 AM, Loftus, Ciara wrote:

> >> Thanks for confirming Devendra

> >>

> >> Adding Ciara

> >> There have been some offline discussions regarding the issue.

> >

> > The workaround discussed is a patch to enable backwards compatibility

> with the old port IDs. Something like the following:

> >

> > – set Interface portX options:dpdk-devargs=dpdkportid0

> >

> > Looking for input.

> >

> 

> Seems like a good idea to take in the port number as a workaround. If

> it's just temporary because there will be a fix in DPDK sometime, then

> perhaps a new experimental option could be introduced  (e.g.

> dpdk-legacyname or dpdk-dpdkportnum) and removed in time. Otherwise

> dpdk-devargs usage will be changing between releases, break backwards

> compatibility and probably confuse people migrating from  having two ways to use it.

> 

> Maybe =dpdk0 is better than =dpdkportid0 as it's closer to the old

> behavior you are trying to replicate?

> 

> set Interface mydpdkport options:dpdk-legacyname=dpdk0



I think that's a good approach.


Seems fine to me
One alternative since I remember there was some confusion about the portid 
context before.

dpdk-dpdkportid=dpdk0  ?


> 

> Do you know if the required API will be implemented in DPDK sometime?



There was no response when I cross-posted to DPDK users mailing list, so I 
can't confirm.



Thanks,

Ciara



> 

> > Thanks,

> > Ciara

> >

> >>

> >>

> >> From: devendra rawat <devendra.rawat.si...@gmail.com>

> >> Date: Monday, September 18, 2017 at 4:27 AM

> >> To: Kevin Traynor <ktray...@redhat.com>

> >> Cc: Darrel Ball <db...@vmware.com>, "ovs-...@openvswitch.org"  >> d...@openvswitch.org>, "disc...@openvswitch.org"

> >> <disc...@openvswitch.org>

> >> Subject: Re: [ovs-dev] adding dpdk ports sharing same pci address to 
ovs-

> >> dpdk bridge

> >>

> >> Hi Kevin,

> >>

> >> On Fri, Sep 8, 2017 at 12:24 AM, Kevin Traynor <ktray...@redhat.com>

> >> wrote:

> >> On 09/07/2017 06:47 PM, Darrell Ball wrote:

> >>> Adding disc...@openvswitch.org

> >>>

> >>> The related changes went into 2.7

> >>>

> >>>

> >>>

> >>> On 9/7/17, 3:51 AM, "ovs-dev-boun...@openvswitch.org on behalf of

> >> devendra rawat" <ovs-dev-boun...@openvswitch.org on behalf of

> >> devendra.rawat.si...@gmail.com> wrote:

> >>>

> >>>  Hi,

> >>>

> >>>  I have compiled and built ovs-dpdk using DPDK v17.08 and OVS 
v2.8.0.

> >> The

> >>>  NIC that I am using is Mellanox ConnectX-3 Pro, which is a dual 
port

> 10G

> >>>  NIC. The problem with this NIC is that it provides only one PCI 
address

> for

> >>>  both the 10G ports.

> >>>

> >>>  So when I am trying to add the two DPDK ports to my br0 bridge

> >>>

> >>>  # ovs-vsctl --no-wait add-port br0 dpdk0 -- set Interface dpdk0

> >> type=dpdk

> >>>  options:dpdk-devargs=0002:01:00.0

> >>>

> >>>  # ovs-vsctl --no-wait add-port br0 dpdk1 -- set Interface dpdk1

> >> type=dpdk

> >>>  options:dpdk-devargs=0002:01:00.0

> >>>

> >>

> >> Were you able to confirm those addresses by running ./dpdk-devbind.py

> -s

> >> in your /tools dir?

> >>

> >> On running dpdk-devbind.py --status , I can see the ConnectX-3 pro NIC,

> >> having only one PCI address.

> >>

> >> Network devices using DPDK-compatible driver

> >> 

> 

Re: [ovs-discuss] [ovs-dev] adding dpdk ports sharing same pci address to ovs-dpdk bridge

[Darrell Ball]

Hi Devendra

Could you please respond to Kevin’s query just to be sure ?

Were you able to confirm those addresses by running ./dpdk-devbind.py -s
in your /tools dir?

Thanks Darrell


On 9/7/17, 11:54 AM, "Kevin Traynor" <ktray...@redhat.com> wrote:

On 09/07/2017 06:47 PM, Darrell Ball wrote:
> Adding disc...@openvswitch.org
> 
> The related changes went into 2.7
> 
> 
> 
> On 9/7/17, 3:51 AM, "ovs-dev-boun...@openvswitch.org on behalf of 
devendra rawat" <ovs-dev-boun...@openvswitch.org on behalf of 
devendra.rawat.si...@gmail.com> wrote:
> 
> Hi,
> 
> I have compiled and built ovs-dpdk using DPDK v17.08 and OVS v2.8.0. 
The
> NIC that I am using is Mellanox ConnectX-3 Pro, which is a dual port 
10G
> NIC. The problem with this NIC is that it provides only one PCI 
address for
> both the 10G ports.
> 
> So when I am trying to add the two DPDK ports to my br0 bridge
> 
> # ovs-vsctl --no-wait add-port br0 dpdk0 -- set Interface dpdk0 
type=dpdk
> options:dpdk-devargs=0002:01:00.0
> 
> # ovs-vsctl --no-wait add-port br0 dpdk1 -- set Interface dpdk1 
type=dpdk
> options:dpdk-devargs=0002:01:00.0
> 

Were you able to confirm those addresses by running ./dpdk-devbind.py -s
in your /tools dir?

> The port dpdk1 is added successfully and able to transfer data, but 
adding
> dpdk0 to br0 fails:
> 
> 2017-09-06T14:19:20Z|00045|netdev_dpdk|INFO|Port 0: e4:1d:2d:4f:78:60
> 2017-09-06T14:19:20Z|00046|bridge|INFO|bridge br0: added interface 
dpdk1 on
> port 1
> 2017-09-06T14:19:20Z|00047|bridge|INFO|bridge br0: added interface 
br0 on
> port 65534
> 2017-09-06T14:19:20Z|00048|dpif_netlink|WARN|Generic Netlink family
> 'ovs_datapath' does not exist. The Open vSwitch kernel module is 
probably
> not loaded.
> 2017-09-06T14:19:20Z|00049|netdev_dpdk|WARN|'dpdk0' is trying to use 
device
> '0002:01:00.0' which is already in use by 'dpdk1'
> 2017-09-06T14:19:20Z|00050|netdev|WARN|dpdk0: could not set 
configuration
> (Address already in use)
> 2017-09-06T14:19:20Z|00051|bridge|INFO|bridge br0: using datapath ID
> e41d2d4f7860
> 
> 
> With OVS v2.6.1 I never had this problem as dpdk-devargs was not 
mandatory
> and just specifying port name was enough to add that port to bridge.
> 
> Is there a way to add port both ports to bridge ?
> 
> Thanks,
> Devendra
> ___
> dev mailing list
> d...@openvswitch.org
> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev=DwICAg=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=qO7NdgrrorJhievOguQLmsfEFuBcPfz9NfQX7UME1-8=ZKHbYlaTjm8VFj6Rggmcb2gw6s3xW4PxEtUy4YFG1VA=
 
> 
> 
> ___
> dev mailing list
> d...@openvswitch.org
> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev=DwIC-g=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=SP7c06xdDYsw8FYR-HyGtqE-hTmP0KUKiWhLr-NeyyI=2XcodWmzbMnU56fFummQJpM1PtAlwKe-TrNfrtmomH4=
 
> 



___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] conntrack: Another ct-clean thread crash bug

[Darrell Ball]

On 9/8/17, 2:51 AM, "wangyunjian" <wangyunj...@huawei.com> wrote:

The operations of buckets->connections hmap should with a lock to protect 
between

ovs-vswitchd thread and pmd thread(or ct clean thread).But conn_clean() 
will release the lock.

This time, the hmap maybe change by other thread and the node->next maybe 
remove from hmap.

[Darrell] If I read your text correctly, then what you describe is intentional 
– there are multiple threads
and buckets are protected by locks, but, I don’t see a specific 
issue pointed to.
Also, this is not consistent with the stack trace below, 
assuming the stack trace is generated from
non-instrumented code and is reliable.

 Can you provide initially :

1/ Your config – ovs-vsctl show, sudo ovs-appctl dpif/show, sudo ovs-ofctl 
dump-flows ,
 ovs-appctl dpif/dump-flows br0

2/ I could not understand your simple diagram – can you make association of the 
diagram to
  “ovs-vsctl show” output.

3/ Are you sending TCP traffic or UDP traffic ?

4/ What streams are you sending ?
 What I mean by streams – what range of src/dst IP addresses and src/dst 
layer 4 port numbers
 What physical or virtual ports are you sending the streams from.






process_one(){  // pmd thread

ct_lock_lock(ctb.lock);

conn_clean (){

ct_lock_unlock(ctb.lock);

...

ct_lock_lock(ctb.lock)

}

ct_lock_unlock(ctb.lock);

}



conntrack_flush() {   //main thread

ct_lock_lock(ctb.lock);

nat_clean () {

ct_lock_unlock(ctb.lock);

...

ct_lock_lock(ctb.lock)

}

ct_lock_unlock(ctb.lock);

}



clean_thread_main() { // ct clean thread

ct_lock_lock(ctb.lock);

conn_clean (){

ct_lock_unlock(ctb.lock);

...

ct_lock_lock(ctb.lock)

}

ct_lock_unlock(ctb.lock);

}



> -Original Message-

> From: ovs-discuss-boun...@openvswitch.org [mailto:ovs-discuss-

> boun...@openvswitch.org] On Behalf Of Darrell Ball

> Sent: Wednesday, September 06, 2017 11:50 PM

> To: Huanglili (lee) <huanglili.hu...@huawei.com>; ovs-

> disc...@openvswitch.org

> Cc: b...@nicira.com; caihe <ca...@huawei.com>; liucheng (J)

> <liuchen...@huawei.com>

> Subject: Re: [ovs-discuss] conntrack: Another ct-clean thread crash bug

> 

> Hmm, that seems odd.

> Also, the code change you propose below does not make sense and would

> likely cause similar crashes itself.

> 

> Maybe, you explain what you are trying to do in your testing ?

> Can you say what traffic are you sending and from which ports ?

> 

> I’ll take another look at the related code.

> 

> Darrell

> 

> 

> On 9/6/17, 6:14 AM, "Huanglili (lee)" <huanglili.hu...@huawei.com> wrote:

> 

> Hi,

> We met another vswitchd crash when we use ct(nat) (ovs+dpdk).

> 

> Program terminated with signal 11, Segmentation fault.

> #0  0x00574a0b in hmap_remove (node=0x7f150c6e60a8,

> hmap=0x7f1553c40780) at lib/hmap.h:270

>   while (*bucket != node) {

> 

> (gdb) bt

> #0  0x00574a0b in hmap_remove (node=0x7f150c6e60a8,

> hmap=0x7f1553c40780)

> #1  sweep_bucket (limit=1808, now=563303851, ctb=0x7f1553c40778,

> ct=0x7f1553c3f9a8)

> #2  conntrack_clean (now=563303851, ct=0x7f1553c3f9a8)

> #3  clean_thread_main (f_=0x7f1553c3f9a8)

> 

> This crash can be triggered by using following flows, maybe the flows 
are

> not reasonable, but shouldn't trigger crash

> "table=0,priority=2,in_port=1 actions=resubmit(,2)

> table=0,priority=2,in_port=4 actions=resubmit(,2)

> table=0,priority=0 actions=drop

> table=0,priority=1 actions=resubmit(,10)

> table=1,priority=0 actions=resubmit(,14)

> table=2,priority=0 actions=resubmit(,4)

> table=4,priority=0 actions=resubmit(,14)

> table=10,priority=2,arp actions=resubmit(,1

Re: [ovs-discuss] conntrack: Another ct-clean thread crash bug

[Darrell Ball]

Hmm, that seems odd.
Also, the code change you propose below does not make sense and would likely 
cause similar crashes itself.

Maybe, you explain what you are trying to do in your testing ?
Can you say what traffic are you sending and from which ports ?

I’ll take another look at the related code.

Darrell


On 9/6/17, 6:14 AM, "Huanglili (lee)"  wrote:

Hi,
We met another vswitchd crash when we use ct(nat) (ovs+dpdk).

Program terminated with signal 11, Segmentation fault.
#0  0x00574a0b in hmap_remove (node=0x7f150c6e60a8, 
hmap=0x7f1553c40780) at lib/hmap.h:270
while (*bucket != node) {

(gdb) bt
#0  0x00574a0b in hmap_remove (node=0x7f150c6e60a8, 
hmap=0x7f1553c40780)
#1  sweep_bucket (limit=1808, now=563303851, ctb=0x7f1553c40778, 
ct=0x7f1553c3f9a8)
#2  conntrack_clean (now=563303851, ct=0x7f1553c3f9a8) 
#3  clean_thread_main (f_=0x7f1553c3f9a8) 

This crash can be triggered by using following flows, maybe the flows are 
not reasonable, but shouldn't trigger crash
"table=0,priority=2,in_port=1 actions=resubmit(,2)
table=0,priority=2,in_port=4 actions=resubmit(,2)
table=0,priority=0 actions=drop
table=0,priority=1 actions=resubmit(,10)
table=1,priority=0 actions=resubmit(,14)
table=2,priority=0 actions=resubmit(,4)
table=4,priority=0 actions=resubmit(,14)
table=10,priority=2,arp actions=resubmit(,12)
table=10,priority=1,dl_src=90:E2:BA:69:CD:61 actions=resubmit(,1)
table=10,priority=0 actions=drop

table=12,priority=3,arp,dl_src=90:E2:BA:69:CD:61,arp_spa=194.168.100.1,arp_sha=90:E2:BA:69:CD:61
 actions=resubmit(,1)
table=12,priority=2,arp actions=drop
table=14,priority=6,ip actions=ct(table=16,zone=1)
table=14,priority=0 actions=resubmit(,20)
table=14,priority=20,ip,ip_frag=yes,actions=resubmit(,18)
table=16,priority=20,ct_state=+est+trk,ip actions=resubmit(,20)
table=16,priority=15,ct_state=+rel+trk,ip actions=resubmit(,20)
table=16,priority=10,ct_mark=0x8000/0x8000,udp actions=resubmit(,20)
table=16,priority=5,ct_state=+new+trk,ip,in_port=3 actions=resubmit(,18)
table=16,priority=5,ct_state=+new+trk,ip,in_port=4 actions=resubmit(,18)
table=16,priority=5,ct_state=+new+trk,ip,in_port=2 
actions=ct(commit,zone=1,exec(load:0x1->NXM_NX_CT_MARK[31])),output:4
table=16,priority=5,ct_state=+new+trk,ip,in_port=1 
actions=ct(commit,zone=1,exec(load:0x1->NXM_NX_CT_MARK[31])),output:3
table=18,priority=0,in_port=3 actions=ct(zone=1,table=24)
table=18,priority=0,in_port=2 actions=output:4
table=18,priority=0,in_port=4,ip 
actions=ct(commit,zone=1,nat(dst=194.168.100.1)),2
table=18,priority=0,in_port=1 actions=output:3
table=20,priority=10,in_port=3,ip actions=ct(zone=1,table=22)
table=20,priority=10,in_port=4,ip actions=ct(zone=1,table=23)
table=20,priority=1 actions=ct(zone=1,table=18)
table=22,priority=10,in_port=3 action=4
table=23,priority=10,in_port=4 action=3
table=24,priority=10,in_port=3 action=1"

The networking:
vm
 |
br-ply - br-linux
 |
br-int

We find rev_conn is in the list of ctb->exp_lists[] sometimes.
The following change will solve this problem, but we can't explain why

$ git diff
diff --git a/lib/conntrack.c b/lib/conntrack.c
index 419cb1d..d5141c4 100644
--- a/lib/conntrack.c
+++ b/lib/conntrack.c
@@ nat_clean(struct conntrack *ct, struct conn *conn,
 if (rev_conn && (!nat_conn_key_node ||
  conn_key_cmp(_conn_key_node->value,
   _conn->rev_key))) {
+ovs_list_remove(_conn->exp_node);
 hmap_remove(>buckets[bucket_rev_conn].connections,
 _conn->node);
 free(rev_conn);
@@ create_un_nat_conn(struct conntrack *ct, struct conn *conn_f
or_un_nat_copy,
 nat_conn_keys_lookup(>nat_conn_keys, >key, 
ct->hash_basis);
 if (nat_conn_key_node && !conn_key_cmp(_conn_key_node->value,
 >rev_key) && !rev_conn) {
-
+ovs_list_init(>exp_node);
 hmap_insert(>buckets[un_nat_conn_bucket].connections,
 >node, un_nat_hash);

Any idea?

Thanks.



On 8/24/17, 3:36 AM, "ovs-dev-boun...@openvswitch.org on behalf of 
huanglili"  wrote:

From: Lili Huang 

Conn should be removed from the list before freed.

This crash will be triggered when a established flow do ct(nat)
again, like
"ip,actions=ct(table=1)
 

Re: [ovs-discuss] [ovs-dev] OVS DPDK NUMA pmd assignment question for physical port

[Darrell Ball]

Adding Billy and Kevin


On 9/6/17, 12:22 AM, "Darrell Ball" <db...@vmware.com> wrote:



On 9/6/17, 12:03 AM, "王志克" <wangzh...@jd.com> wrote:

Hi Darrell,

pmd-rxq-affinity has below limitation: (so isolated pmd can not be used 
for others, which is not my expectation. Lots of VMs come and go on the fly, 
and manully assignment is not feasible.)
  >>After that PMD threads on cores where RX queues was pinned 
will become isolated. This means that this thread will poll only pinned RX 
queues

My problem is that I have several CPUs spreading on different NUMA 
nodes. I hope all these CPU can have chance to serve the rxq. However, because 
the phy NIC only locates on one certain socket node, non-same numa pmd/CPU 
would be excluded. So I am wondering whether we can have different behavior for 
phy port rxq: 
  round-robin to all PMDs even the pmd on different NUMA socket.

I guess this is a common case, and I believe it would improve rx 
performance.


[Darrell] I agree it would be a common problem and some distribution would 
seem to make sense, maybe factoring in some favoring of local numa PMDs ?
Maybe an optional config to enable ?
  

Br,
Wang Zhike



___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [ovs-dev] OVS DPDK NUMA pmd assignment question for physical port

[Darrell Ball]

On 9/6/17, 12:03 AM, "王志克"  wrote:

Hi Darrell,

pmd-rxq-affinity has below limitation: (so isolated pmd can not be used for 
others, which is not my expectation. Lots of VMs come and go on the fly, and 
manully assignment is not feasible.)
  >>After that PMD threads on cores where RX queues was pinned will 
become isolated. This means that this thread will poll only pinned RX queues

My problem is that I have several CPUs spreading on different NUMA nodes. I 
hope all these CPU can have chance to serve the rxq. However, because the phy 
NIC only locates on one certain socket node, non-same numa pmd/CPU would be 
excluded. So I am wondering whether we can have different behavior for phy port 
rxq: 
  round-robin to all PMDs even the pmd on different NUMA socket.

I guess this is a common case, and I believe it would improve rx 
performance.


[Darrell] I agree it would be a common problem and some distribution would seem 
to make sense, maybe factoring in some favoring of local numa PMDs ?
Maybe an optional config to enable ?
  

Br,
Wang Zhike

___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [ovs-dev] OVS DPDK NUMA pmd assignment question for physical port

[Darrell Ball]

You could use  pmd-rxq-affinity for the queues you want serviced locally and 
let the others go remote

On 9/5/17, 8:14 PM, "王志克" <wangzh...@jd.com> wrote:

It is a bit different from my expectation.



I have separate CPU and pmd for each NUMA node. However, the physical NIC 
only locates on NUMA socket0. So only part of CPU and pmd (the ones in same 
NUMA node) can poll the physical NIC. Since I have multiple rx queue, I hope 
part queues can be polled with pmd on same node, others can be polled with pmd 
on non-local numa node. In this way, we have more pmds contributes the polling 
of physical NIC, so performance improvement is expected from total rx traffic 
view.



Br,

Wang Zhike



-Original Message-

    From: Darrell Ball [mailto:db...@vmware.com] 

Sent: Wednesday, September 06, 2017 10:47 AM

To: 王志克; ovs-discuss@openvswitch.org; ovs-...@openvswitch.org

Subject: Re: [ovs-dev] OVS DPDK NUMA pmd assignment question for physical 
port



This same numa node limitation was already removed, although same numa is 
preferred for performance reasons.



commit c37813fdb030b4270d05ad61943754f67021a50d

Author: Billy O'Mahony <billy.o.mah...@intel.com>

Date:   Tue Aug 1 14:38:43 2017 -0700



dpif-netdev: Assign ports to pmds on non-local numa node.



Previously if there is no available (non-isolated) pmd on the numa node

for a port then the port is not polled at all. This can result in a

non-operational system until such time as nics are physically

repositioned. It is preferable to operate with a pmd on the 'wrong' numa

node albeit with lower performance. Local pmds are still chosen when

available.



Signed-off-by: Billy O'Mahony <billy.o.mah...@intel.com>

Signed-off-by: Ilya Maximets <i.maxim...@samsung.com>

Co-authored-by: Ilya Maximets <i.maxim...@samsung.com>





The sentence “The rx queues are assigned to pmd threads on the same NUMA 
node in a round-robin fashion.”



under



DPDK Physical Port Rx Queues¶



should be removed since it is outdated in a couple of ways and there is 
other correct documentation on the same page

and also here 
https://urldefense.proofpoint.com/v2/url?u=http-3A__docs.openvswitch.org_en_latest_howto_dpdk_=DwIGaQ=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=iNebKvfYjcXbjMsmtLJqThRUImv8W4PRrYWpD-QwUVg=KG3MmQe4QkUkyG3xsCoF6DakFsZh_eg9aEyhYFUKF2c=
 



Maybe you could submit a patch ?



Thanks Darrell





On 9/5/17, 7:18 PM, "ovs-dev-boun...@openvswitch.org on behalf of 王志克" 
<ovs-dev-boun...@openvswitch.org on behalf of wangzh...@jd.com> wrote:



Hi All,







I read below doc about pmd assignment for physical port. I think the 
limitation “on the same NUMA node” may be not efficient.








https://urldefense.proofpoint.com/v2/url?u=http-3A__docs.openvswitch.org_en_latest_intro_install_dpdk_=DwIGaQ=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=pqvCrQwfrcDxvwcpuouzVymiBkev1vHpnOlef-ZMev8=4wch_Q6fqo0stIDE4K2loh0z-dshuligqsrAV_h-QuU=
 



DPDK Physical Port Rx 
Queues¶<https://urldefense.proofpoint.com/v2/url?u=http-3A__docs.openvswitch.org_en_latest_intro_install_dpdk_-23dpdk-2Dphysical-2Dport-2Drx-2Dqueues=DwIGaQ=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=pqvCrQwfrcDxvwcpuouzVymiBkev1vHpnOlef-ZMev8=SexDthg-hfPaGjvjCRjkPPY1kK1NfycLQSDw6WHVArQ=>







$ ovs-vsctl set Interface  options:n_rxq=







The above command sets the number of rx queues for DPDK physical 
interface. The rx queues are assigned to pmd threads on the same NUMA node in a 
round-robin fashion.



Consider below case:







One host has one PCI NIC on NUMA node 0, and has 4 VMs, which spread in 
NUMA node 0 and 1. There are multiple rx queues configured on the physical NIC. 
We configured 4 pmd (two cpu from NUMA node0, and two cpu from node 1). Since 
the physical NIC locates on NUMA node0, only pmds on same NUMA node can poll 
its rxq. As a result, only two cpu can be used for polling physical NIC.







If we compare the OVS kernel mode, there is no such limitation.







So question:



should we remove “same NUMA node” limitation fro physical port rx 
queues? Or 

Re: [ovs-discuss] [ovs-dev] OVS DPDK NUMA pmd assignment question for physical port

[Darrell Ball]

This same numa node limitation was already removed, although same numa is 
preferred for performance reasons.

commit c37813fdb030b4270d05ad61943754f67021a50d
Author: Billy O'Mahony 
Date:   Tue Aug 1 14:38:43 2017 -0700

dpif-netdev: Assign ports to pmds on non-local numa node.

Previously if there is no available (non-isolated) pmd on the numa node
for a port then the port is not polled at all. This can result in a
non-operational system until such time as nics are physically
repositioned. It is preferable to operate with a pmd on the 'wrong' numa
node albeit with lower performance. Local pmds are still chosen when
available.

Signed-off-by: Billy O'Mahony 
Signed-off-by: Ilya Maximets 
Co-authored-by: Ilya Maximets 


The sentence “The rx queues are assigned to pmd threads on the same NUMA node 
in a round-robin fashion.”

under

DPDK Physical Port Rx Queues¶

should be removed since it is outdated in a couple of ways and there is other 
correct documentation on the same page
and also here http://docs.openvswitch.org/en/latest/howto/dpdk/

Maybe you could submit a patch ?

Thanks Darrell


On 9/5/17, 7:18 PM, "ovs-dev-boun...@openvswitch.org on behalf of 王志克" 
 wrote:

Hi All,



I read below doc about pmd assignment for physical port. I think the 
limitation “on the same NUMA node” may be not efficient.




https://urldefense.proofpoint.com/v2/url?u=http-3A__docs.openvswitch.org_en_latest_intro_install_dpdk_=DwIGaQ=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=pqvCrQwfrcDxvwcpuouzVymiBkev1vHpnOlef-ZMev8=4wch_Q6fqo0stIDE4K2loh0z-dshuligqsrAV_h-QuU=
 

DPDK Physical Port Rx 
Queues¶



$ ovs-vsctl set Interface  options:n_rxq=



The above command sets the number of rx queues for DPDK physical interface. 
The rx queues are assigned to pmd threads on the same NUMA node in a 
round-robin fashion.

Consider below case:



One host has one PCI NIC on NUMA node 0, and has 4 VMs, which spread in 
NUMA node 0 and 1. There are multiple rx queues configured on the physical NIC. 
We configured 4 pmd (two cpu from NUMA node0, and two cpu from node 1). Since 
the physical NIC locates on NUMA node0, only pmds on same NUMA node can poll 
its rxq. As a result, only two cpu can be used for polling physical NIC.



If we compare the OVS kernel mode, there is no such limitation.



So question:

should we remove “same NUMA node” limitation fro physical port rx queues? 
Or we have other options to improve the performance for this case?



Br,

Wang Zhike



___
dev mailing list
d...@openvswitch.org

https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev=DwIGaQ=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=pqvCrQwfrcDxvwcpuouzVymiBkev1vHpnOlef-ZMev8=Whz73vLTYWkBuEL6reD88bkzCgSfqpgb7MDiCG5fB4A=
 


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Reg: Ovs-Dpdk Forwarding Plane.

[Darrell Ball]

From:  on behalf of Durai Velan 
Chockalingam 
Date: Sunday, August 20, 2017 at 12:12 PM
To: "ovs-discuss@openvswitch.org" 
Subject: [ovs-discuss] Reg: Ovs-Dpdk Forwarding Plane.

Hello All,
Am trying to look for very comprehensive information on How Packet are Handled 
in Dataplane, for the following communication
1) VM-2-VM in Same compute host ( and both of them are vhostdpdkuser )
I understand that vhostdpdkuser, is nothing but a Unix Socket open, by Ovs-Dpdk 
and VM are Client.
However, I could not undertstand how forwarding of packets are happening 
between the VM via Socket ??
Does OVS Maintains any Forwarding Information bases for DPDK Vhostuser and if 
so what is tool to interact without those fibs ??

>>
At the forwarding layer, it a logical dp port (and at openflow layer, it is a 
of port), similar to other ports. When the packets are
received from a port and sent to a port, there is a difference, which is 
embodied in the netdev layer (in this case, netdev-dpdk),
which has vhost specific support, in addition to dpdk managed physical device 
support.
See the below links as well.
http://docs.openvswitch.org/en/latest/howto/dpdk/
http://docs.openvswitch.org/en/latest/topics/dpdk/vhost-user/
<<<

2) VM (Compute Host Network / or VLAN Say 10.0.0.1)-2-PHY--- L2 DEVICE 2-VM 
(Another Compute Host, Same Network / or VLAN Say 10.0.0.2 )
Similary, how does Packet flow in this Scenario, and what kind of configuration 
should be make in L2 Device
>
check the above links as well.
<






Any References, or Documentation explaining this would be also appreciated.

Thanks and Regards
Durai Velan.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [openvswitch 2.8.0 dpdk] testsuite: 1211 1212 1213 1214 1215 1217 1218 1219 1220 1221 1222 1224 1225 1226 2338 failed

[Darrell Ball]

-Original Message-
From: Ben Pfaff <b...@ovn.org>
Date: Tuesday, August 8, 2017 at 4:07 PM
To: Darrell Ball <db...@vmware.com>
Cc: Joe Stringer <j...@ovn.org>, "b...@openvswitch.org" <b...@openvswitch.org>
Subject: Re: [ovs-discuss] [openvswitch 2.8.0 dpdk] testsuite: 1211 1212 1213 
1214 1215 1217 1218 1219 1220 1221 1222 1224 1225 1226 2338 failed

On Tue, Aug 08, 2017 at 10:52:36PM +, Darrell Ball wrote:
> 
> 
> -Original Message-
> From: Joe Stringer <j...@ovn.org>
> Date: Tuesday, August 8, 2017 at 3:43 PM
> To: Darrell Ball <db...@vmware.com>
> Cc: James Page <james.p...@ubuntu.com>, "b...@openvswitch.org" 
<b...@openvswitch.org>
> Subject: Re: [ovs-discuss] [openvswitch 2.8.0 dpdk] testsuite: 1211 1212 
1213 1214 1215 1217 1218 1219 1220 1221 1222 1224 1225 1226 2338 failed
> 
> On 8 August 2017 at 09:26, Darrell Ball <db...@vmware.com> wrote:
> >
> >
> >
> >
> > From: <ovs-discuss-boun...@openvswitch.org> on behalf of James Page
> > <james.p...@ubuntu.com>
> > Date: Tuesday, August 8, 2017 at 2:49 AM
> > To: "b...@openvswitch.org" <b...@openvswitch.org>
> > Subject: [ovs-discuss] [openvswitch 2.8.0 dpdk] testsuite: 1211 
1212 1213
> > 1214 1215 1217 1218 1219 1220 1221 1222 1224 1225 1226 2338 failed
> >
> >
> >
> > Hi
> >
> >
> >
> > I'm cutting builds from branch-2.8 in preparation for the ovs 2.8.0 
release
> > for Ubuntu; we build and test two sets of binaries - a vanilla one 
and one
> > with dpdk enabled.
> >
> >
> >
> > I see test failures on all of the "ofproto-dpif - conntrack" tests 
with the
> > DPDK build and with the ovn ACL test (see attached logs).  Vanilla 
build is
> > fine.
> >
> >
> >
> > James
> >
> >
> >
> > These are generic tests and should not be run with-dpdk set.
> >
> > If you run these tests --with-dpdk, some tests will consider the 
packets
> > coming an actual dpdk interface, which they are not.
> >
> > In this case, the packets will be marked with a bad checksum.
> >
> >
> >
> > Are you able to run these tests as we do without “–with-dpdk” ?
> 
> Hmm, this seems surprising to me - I thought that "--with-dpdk" mostly
> just enables another netdevice implementation. Why would this affect
> input/output with netdev-dummy devices?
> 
> For what it's worth, I tried a run of the testsuite with OVS built
> "--with-dpdk" on branch-2.7 and it worked fine:
> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__travis-2Dci.org_joestringer_openvswitch_jobs_262439494=DwIFaQ=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=2rYtIAwBngD_iZxhgs9_RxL9aNIlVqYJNRfdSppMEKw=j1JxZ5I8Yj0xapAPLtfpPqwTHiqQEUmUf2ZBdqdJkOo=
 
> 
> The test failures for the first few are hard-failures (ie ovs uses
> WAIT_UNTIL for something that never succeeds), examples below where
> OVS was waiting to receive packets that never arrive:
> 
> ../../tests/ofproto-dpif.at:9016: ovs-appctl netdev-dummy/receive p2
> 
'in_port(2),eth(src=50:54:00:00:00:0a,dst=50:54:00:00:00:09),eth_type(0x0800),ipv4(src=10.1.1.2,dst=10.1.1.1,proto=17,tos=0,ttl=64,frag=no),udp(src=2,dst=1)'
> ../../tests/ofproto-dpif.at:9018: hard failure
> 
> ---
> 
> Some of the later failures are a bit more interesting:
> 
> ../../tests/ofproto-dpif.at:9161: ovs-appctl netdev-dummy/receive p2
> 
'in_port(2),eth(src=50:54:00:00:00:0a,dst=50:54:00:00:00:09),eth_type(0x0800),ipv4(src=10.1.1.2,dst=10.1.1.1,proto=17,tos=0,ttl=64,frag=no),udp(src=2,dst=1)'
> ../../tests/ofproto-dpif.at:9164: cat ovs-vswitchd.log | strip_ufid |
> filter_flow_install
> --- - 2017-08-08 09:39:36.051525087 +
> +++ 
/build/openvswitch-NQWKUM/openvswitch-2.8.0~git20170807.17b6e3ce8/_dpdk/tests/testsuite.dir/at-groups/1214/stdout
> 2017-08-08 09:39:36.046218819 +
> @@ -1,5 +1,4 @@
> 
-ct_state(+new-est+trk),recirc_id(0x1),in_port(2),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(frag=no),
> actions:d

Re: [ovs-discuss] [openvswitch 2.8.0 dpdk] testsuite: 1211 1212 1213 1214 1215 1217 1218 1219 1220 1221 1222 1224 1225 1226 2338 failed

[Darrell Ball]

-Original Message-
From: Joe Stringer <j...@ovn.org>
Date: Tuesday, August 8, 2017 at 3:43 PM
To: Darrell Ball <db...@vmware.com>
Cc: James Page <james.p...@ubuntu.com>, "b...@openvswitch.org" 
<b...@openvswitch.org>
Subject: Re: [ovs-discuss] [openvswitch 2.8.0 dpdk] testsuite: 1211 1212 1213 
1214 1215 1217 1218 1219 1220 1221 1222 1224 1225 1226 2338 failed

On 8 August 2017 at 09:26, Darrell Ball <db...@vmware.com> wrote:
>
>
>
>
> From: <ovs-discuss-boun...@openvswitch.org> on behalf of James Page
> <james.p...@ubuntu.com>
> Date: Tuesday, August 8, 2017 at 2:49 AM
> To: "b...@openvswitch.org" <b...@openvswitch.org>
> Subject: [ovs-discuss] [openvswitch 2.8.0 dpdk] testsuite: 1211 1212 1213
> 1214 1215 1217 1218 1219 1220 1221 1222 1224 1225 1226 2338 failed
>
>
>
> Hi
>
>
>
> I'm cutting builds from branch-2.8 in preparation for the ovs 2.8.0 
release
> for Ubuntu; we build and test two sets of binaries - a vanilla one and one
> with dpdk enabled.
>
>
>
> I see test failures on all of the "ofproto-dpif - conntrack" tests with 
the
> DPDK build and with the ovn ACL test (see attached logs).  Vanilla build 
is
> fine.
>
>
>
> James
>
>
>
> These are generic tests and should not be run with-dpdk set.
>
> If you run these tests --with-dpdk, some tests will consider the packets
> coming an actual dpdk interface, which they are not.
>
> In this case, the packets will be marked with a bad checksum.
>
>
>
> Are you able to run these tests as we do without “–with-dpdk” ?

Hmm, this seems surprising to me - I thought that "--with-dpdk" mostly
just enables another netdevice implementation. Why would this affect
input/output with netdev-dummy devices?

For what it's worth, I tried a run of the testsuite with OVS built
"--with-dpdk" on branch-2.7 and it worked fine:

https://urldefense.proofpoint.com/v2/url?u=https-3A__travis-2Dci.org_joestringer_openvswitch_jobs_262439494=DwIFaQ=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=2rYtIAwBngD_iZxhgs9_RxL9aNIlVqYJNRfdSppMEKw=j1JxZ5I8Yj0xapAPLtfpPqwTHiqQEUmUf2ZBdqdJkOo=
 

The test failures for the first few are hard-failures (ie ovs uses
WAIT_UNTIL for something that never succeeds), examples below where
OVS was waiting to receive packets that never arrive:

../../tests/ofproto-dpif.at:9016: ovs-appctl netdev-dummy/receive p2

'in_port(2),eth(src=50:54:00:00:00:0a,dst=50:54:00:00:00:09),eth_type(0x0800),ipv4(src=10.1.1.2,dst=10.1.1.1,proto=17,tos=0,ttl=64,frag=no),udp(src=2,dst=1)'
../../tests/ofproto-dpif.at:9018: hard failure

---

Some of the later failures are a bit more interesting:

../../tests/ofproto-dpif.at:9161: ovs-appctl netdev-dummy/receive p2

'in_port(2),eth(src=50:54:00:00:00:0a,dst=50:54:00:00:00:09),eth_type(0x0800),ipv4(src=10.1.1.2,dst=10.1.1.1,proto=17,tos=0,ttl=64,frag=no),udp(src=2,dst=1)'
../../tests/ofproto-dpif.at:9164: cat ovs-vswitchd.log | strip_ufid |
filter_flow_install
--- - 2017-08-08 09:39:36.051525087 +
+++ 
/build/openvswitch-NQWKUM/openvswitch-2.8.0~git20170807.17b6e3ce8/_dpdk/tests/testsuite.dir/at-groups/1214/stdout
2017-08-08 09:39:36.046218819 +
@@ -1,5 +1,4 @@

-ct_state(+new-est+trk),recirc_id(0x1),in_port(2),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(frag=no),
actions:drop

-ct_state(-new+est+trk),recirc_id(0x1),in_port(2),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(proto=17,frag=no),
actions:1

+ct_state(-new-est+trk),recirc_id(0x1),in_port(2),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(frag=no),
actions:drop
 
recirc_id(0),in_port(1),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(proto=17,frag=no),
actions:ct(commit),2
 
recirc_id(0),in_port(2),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(proto=17,frag=no),
actions:ct,recirc(0x1)

---

../../tests/ofproto-dpif.at:9738: ovs-appctl netdev-dummy/receive p1

'505400095054000a08004528258e40004006ff3d0a0101020a01010100020001396bb55e8cadbf8a501a5ec1'
../../tests/ofproto-dpif.at:9740: ovs-appctl revalidator/purge
../../tests/ofproto-dpif.at:9744: cat ofctl_monitor.log
--- /dev/null 2017-04-26 10:10:32.404961898 +
+++ 
/build/openvswitch-NQWKUM/openvswitch-2.8.0~git20170807.17b6e3ce8/_dpdk/tests/testsuite.dir/at-groups/1225/stdout
2017-08-08 09:40:40.454215126 +
@@ -0,0 +1,22 @@
+NXT_PACKET_IN (xid=0x0): table_id=1 cookie=0x1 total_len=54
ct_state=inv|trk,in_port=1 (via action) data_len=54 (unbuffered)

+tcp,vlan_tci=0x00

Re: [ovs-discuss] [openvswitch 2.8.0 dpdk] testsuite: 1211 1212 1213 1214 1215 1217 1218 1219 1220 1221 1222 1224 1225 1226 2338 failed

[Darrell Ball]

From:  on behalf of James Page 

Date: Tuesday, August 8, 2017 at 2:49 AM
To: "b...@openvswitch.org" 
Subject: [ovs-discuss] [openvswitch 2.8.0 dpdk] testsuite: 1211 1212 1213 1214 
1215 1217 1218 1219 1220 1221 1222 1224 1225 1226 2338 failed

Hi

I'm cutting builds from branch-2.8 in preparation for the ovs 2.8.0 release for 
Ubuntu; we build and test two sets of binaries - a vanilla one and one with 
dpdk enabled.

I see test failures on all of the "ofproto-dpif - conntrack" tests with the 
DPDK build and with the ovn ACL test (see attached logs).  Vanilla build is 
fine.

James

These are generic tests and should not be run with-dpdk set.
If you run these tests --with-dpdk, some tests will consider the packets coming 
an actual dpdk interface, which they are not.
In this case, the packets will be marked with a bad checksum.

Are you able to run these tests as we do without “–with-dpdk” ?

Thanks Darrell


Also tracking this in Ubuntu under [0].

Cheers

James

[0] https://bugs.launchpad.net/ubuntu/+source/openvswitch/+bug/1709272
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS-DPDK IP fragmentation require

[Darrell Ball]

From: Hui Xiang <xiangh...@gmail.com>
Date: Thursday, July 27, 2017 at 8:10 PM
To: Darrell Ball <db...@vmware.com>
Cc: "ovs-discuss@openvswitch.org" <ovs-discuss@openvswitch.org>
Subject: Re: [ovs-discuss] OVS-DPDK IP fragmentation require



On Fri, Jul 28, 2017 at 10:54 AM, Darrell Ball 
<db...@vmware.com<mailto:db...@vmware.com>> wrote:


From: Hui Xiang <xiangh...@gmail.com<mailto:xiangh...@gmail.com>>
Date: Thursday, July 27, 2017 at 6:59 PM
To: Darrell Ball <db...@vmware.com<mailto:db...@vmware.com>>
Cc: "ovs-discuss@openvswitch.org<mailto:ovs-discuss@openvswitch.org>" 
<ovs-discuss@openvswitch.org<mailto:ovs-discuss@openvswitch.org>>
Subject: Re: [ovs-discuss] OVS-DPDK IP fragmentation require



On Fri, Jul 28, 2017 at 1:12 AM, Darrell Ball 
<db...@vmware.com<mailto:db...@vmware.com>> wrote:


From: Hui Xiang <xiangh...@gmail.com<mailto:xiangh...@gmail.com>>
Date: Thursday, July 27, 2017 at 3:18 AM
To: Darrell Ball <db...@vmware.com<mailto:db...@vmware.com>>
Cc: "ovs-discuss@openvswitch.org<mailto:ovs-discuss@openvswitch.org>" 
<ovs-discuss@openvswitch.org<mailto:ovs-discuss@openvswitch.org>>
Subject: Re: [ovs-discuss] OVS-DPDK IP fragmentation require


Blow is the diagram (using OVS-DPDK):

1. For packets coming to vm1 from internet where could have MTU 1500, there 
could be including some fragmented packets,
how does the ALC/Security groups handle these fragmented packets? do 
nothing and pass it next which may pass the packets
should be dropped or any special handling?

Lets assume the fragments get thru. the physical switch and/or firewall.

Are you using DPDK in GW and using OVS kernel datapath in br-int where you 
apply ACL/Security groups policy ?
All are using DPDK, the ACL/Security groups policy said is OVS-DPDK conntrack 
implementation.
With the case that we should have dropped some packets by creating special 
security group rules, but now due to they are fragmented and get thru by 
default, this is not what is expected.

I would check your configuration.
The dpdk connection tracker marks fragments as ‘invalid’ today and your rules 
should drop ‘invalid’.
OK, thanks. here are the two scenarios we are discussing:

1.  For packets out from vms, use Jumbo Frame supported physical 
switches/routers within OpenStack cloud and enable it in all OVS-DPDK or do not 
allow application to send large frames.

Try to use jumbo frames for performance reasons.

On going out, if you get fragmentation done in HW at the physical switches, then

1)  If it could go back into one of your dpdk networks, then encourage 
using smaller packets

2)  If it goes somewhere else, then it does not matter, keep bigger packets
Are you sure the physical switches do not support jumbo frames?

Maybe it is just a config. change fix there.


2. For packets coming from internet to OVS-DPDK, fragmented packets could be 
arrived, they are all dropped due to marks as 'invalid'.
 With above analysis,  if these fragments are marked as 'invalid' and being 
dropped, the best way I can think about is to not use security group in 
OVS-DPDK if there could be fragments generated.

If you already trust what gets to GW because you have a HW firewall, yes
This assumes internally generated is always safe.

Otherwise, you want to keep security groups and ‘encourage’ no fragments coming 
in, if you can
‘Encourage’ can be done by dropping and triggering checking why the fragments 
got generated in the first place
Fragments may also indicate an exploit attempt, in which case, dropping is good.


Please correct me if I misunderstand anything.

2. For packets egress from vm1, if all internal physical switch support Jumbo 
Frame, that's fine, but if there are some physical swithes
just support 1500/2000 MTU, then fragmented packets generated again. The 
ACL/Security groups face problem as item 1 as well.


For packets that reach the physical switches on the way out, then the decision 
how to handle them is at the physical switch/router
The packets may be fragmented at this point; depending on the switch; there 
will be HW firewall policies to contend with, so depends.

Here, again what I mean is the packets are fragmented by the physical 
switch/router, and they are switching/routing to a next node where has the 
OVS-DPDK set with security group, and OVS-DPDK may let them thru with ignoring 
the security group rules.

Sorry, you lost me a bit here; in point ‘2’ above you said packets are going 
from vm1 to internet and are fine until they hit the physical switch
Where you are assuming they are fragmented because the mtu is lower.
If this is not going to the internet but rather another set of nodes running 
dpdk, then this is another variation of ‘1’ and hence we don’t
need to discuss it.


[ine image 1]

On Thu, Jul 27, 2017 at 2:49 PM, Darrell Ball 
<

Re: [ovs-discuss] OVS-DPDK IP fragmentation require

[Darrell Ball]

From: Hui Xiang <xiangh...@gmail.com>
Date: Thursday, July 27, 2017 at 6:59 PM
To: Darrell Ball <db...@vmware.com>
Cc: "ovs-discuss@openvswitch.org" <ovs-discuss@openvswitch.org>
Subject: Re: [ovs-discuss] OVS-DPDK IP fragmentation require



On Fri, Jul 28, 2017 at 1:12 AM, Darrell Ball 
<db...@vmware.com<mailto:db...@vmware.com>> wrote:


From: Hui Xiang <xiangh...@gmail.com<mailto:xiangh...@gmail.com>>
Date: Thursday, July 27, 2017 at 3:18 AM
To: Darrell Ball <db...@vmware.com<mailto:db...@vmware.com>>
Cc: "ovs-discuss@openvswitch.org<mailto:ovs-discuss@openvswitch.org>" 
<ovs-discuss@openvswitch.org<mailto:ovs-discuss@openvswitch.org>>
Subject: Re: [ovs-discuss] OVS-DPDK IP fragmentation require


Blow is the diagram (using OVS-DPDK):

1. For packets coming to vm1 from internet where could have MTU 1500, there 
could be including some fragmented packets,
how does the ALC/Security groups handle these fragmented packets? do 
nothing and pass it next which may pass the packets
should be dropped or any special handling?

Lets assume the fragments get thru. the physical switch and/or firewall.

Are you using DPDK in GW and using OVS kernel datapath in br-int where you 
apply ACL/Security groups policy ?
All are using DPDK, the ACL/Security groups policy said is OVS-DPDK conntrack 
implementation.
With the case that we should have dropped some packets by creating special 
security group rules, but now due to they are fragmented and get thru by 
default, this is not what is expected.

I would check your configuration.
The dpdk connection tracker marks fragments as ‘invalid’ today and your rules 
should drop ‘invalid’.

2. For packets egress from vm1, if all internal physical switch support Jumbo 
Frame, that's fine, but if there are some physical swithes
just support 1500/2000 MTU, then fragmented packets generated again. The 
ACL/Security groups face problem as item 1 as well.


For packets that reach the physical switches on the way out, then the decision 
how to handle them is at the physical switch/router
The packets may be fragmented at this point; depending on the switch; there 
will be HW firewall policies to contend with, so depends.

Here, again what I mean is the packets are fragmented by the physical 
switch/router, and they are switching/routing to a next node where has the 
OVS-DPDK set with security group, and OVS-DPDK may let them thru with ignoring 
the security group rules.

Sorry, you lost me a bit here; in point ‘2’ above you said packets are going 
from vm1 to internet and are fine until they hit the physical switch
Where you are assuming they are fragmented because the mtu is lower.
If this is not going to the internet but rather another set of nodes running 
dpdk, then this is another variation of ‘1’ and hence we don’t
need to discuss it.


[line image 1]

On Thu, Jul 27, 2017 at 2:49 PM, Darrell Ball 
<db...@vmware.com<mailto:db...@vmware.com>> wrote:


From: Hui Xiang <xiangh...@gmail.com<mailto:xiangh...@gmail.com>>
Date: Wednesday, July 26, 2017 at 9:43 PM
To: Darrell Ball <db...@vmware.com<mailto:db...@vmware.com>>
Cc: "ovs-discuss@openvswitch.org<mailto:ovs-discuss@openvswitch.org>" 
<ovs-discuss@openvswitch.org<mailto:ovs-discuss@openvswitch.org>>
Subject: Re: [ovs-discuss] OVS-DPDK IP fragmentation require

Thanks Darrell, comment inline.

On Thu, Jul 27, 2017 at 12:08 PM, Darrell Ball 
<db...@vmware.com<mailto:db...@vmware.com>> wrote:


From: 
<ovs-discuss-boun...@openvswitch.org<mailto:ovs-discuss-boun...@openvswitch.org>>
 on behalf of Hui Xiang <xiangh...@gmail.com<mailto:xiangh...@gmail.com>>
Date: Wednesday, July 26, 2017 at 7:47 PM
To: "ovs-discuss@openvswitch.org<mailto:ovs-discuss@openvswitch.org>" 
<ovs-discuss@openvswitch.org<mailto:ovs-discuss@openvswitch.org>>
Subject: [ovs-discuss] OVS-DPDK IP fragmentation require

Hi guys,

  Seems OVS-DPDK still missing IP fragmentation support, is there any schedule 
to have it?
OVS 2.9
I'm  transferring to use OVN, but for those nodes which have external network 
connection, they may face this problem,
except to configure Jumbo frames, is there any other workaround?

I am not clear on the situation however.
You mention about configuring jumbo frames which means you can avoid the 
fragments by doing this ?
No, I can't guarantee that, only can do it inside OpenStack, it is limited.
If this is true, then this is the best way to proceed since performance will be 
better.
What is wrong with jumbo frames ?
It's good but it's limited can't be guaranteed, so I am asking is there any 
other way without IP fragmentation so far.

It sounds like you want to avoid IP fragmentation; so far so good.
I am not sure I understand the whole picture though.
Maybe you can describe what you see ?; maybe a simple diagram would help ?


BR.
Hui.



___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS-DPDK IP fragmentation require

[Darrell Ball]

From: Hui Xiang <xiangh...@gmail.com>
Date: Thursday, July 27, 2017 at 3:18 AM
To: Darrell Ball <db...@vmware.com>
Cc: "ovs-discuss@openvswitch.org" <ovs-discuss@openvswitch.org>
Subject: Re: [ovs-discuss] OVS-DPDK IP fragmentation require


Blow is the diagram (using OVS-DPDK):

1. For packets coming to vm1 from internet where could have MTU 1500, there 
could be including some fragmented packets,
how does the ALC/Security groups handle these fragmented packets? do 
nothing and pass it next which may pass the packets
should be dropped or any special handling?

Lets assume the fragments get thru. the physical switch and/or firewall.

Are you using DPDK in GW and using OVS kernel datapath in br-int where you 
apply ACL/Security groups policy ?

2. For packets egress from vm1, if all internal physical switch support Jumbo 
Frame, that's fine, but if there are some physical swithes
just support 1500/2000 MTU, then fragmented packets generated again. The 
ACL/Security groups face problem as item 1 as well.


For packets that reach the physical switches on the way out, then the decision 
how to handle them is at the physical switch/router
The packets may be fragmented at this point; depending on the switch; there 
will be HW firewall policies to contend with, so depends.



[nline image 1]

On Thu, Jul 27, 2017 at 2:49 PM, Darrell Ball 
<db...@vmware.com<mailto:db...@vmware.com>> wrote:


From: Hui Xiang <xiangh...@gmail.com<mailto:xiangh...@gmail.com>>
Date: Wednesday, July 26, 2017 at 9:43 PM
To: Darrell Ball <db...@vmware.com<mailto:db...@vmware.com>>
Cc: "ovs-discuss@openvswitch.org<mailto:ovs-discuss@openvswitch.org>" 
<ovs-discuss@openvswitch.org<mailto:ovs-discuss@openvswitch.org>>
Subject: Re: [ovs-discuss] OVS-DPDK IP fragmentation require

Thanks Darrell, comment inline.

On Thu, Jul 27, 2017 at 12:08 PM, Darrell Ball 
<db...@vmware.com<mailto:db...@vmware.com>> wrote:


From: 
<ovs-discuss-boun...@openvswitch.org<mailto:ovs-discuss-boun...@openvswitch.org>>
 on behalf of Hui Xiang <xiangh...@gmail.com<mailto:xiangh...@gmail.com>>
Date: Wednesday, July 26, 2017 at 7:47 PM
To: "ovs-discuss@openvswitch.org<mailto:ovs-discuss@openvswitch.org>" 
<ovs-discuss@openvswitch.org<mailto:ovs-discuss@openvswitch.org>>
Subject: [ovs-discuss] OVS-DPDK IP fragmentation require

Hi guys,

  Seems OVS-DPDK still missing IP fragmentation support, is there any schedule 
to have it?
OVS 2.9
I'm  transferring to use OVN, but for those nodes which have external network 
connection, they may face this problem,
except to configure Jumbo frames, is there any other workaround?

I am not clear on the situation however.
You mention about configuring jumbo frames which means you can avoid the 
fragments by doing this ?
No, I can't guarantee that, only can do it inside OpenStack, it is limited.
If this is true, then this is the best way to proceed since performance will be 
better.
What is wrong with jumbo frames ?
It's good but it's limited can't be guaranteed, so I am asking is there any 
other way without IP fragmentation so far.

It sounds like you want to avoid IP fragmentation; so far so good.
I am not sure I understand the whole picture though.
Maybe you can describe what you see ?; maybe a simple diagram would help ?


BR.
Hui.


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS-DPDK IP fragmentation require

[Darrell Ball]

From: Hui Xiang <xiangh...@gmail.com>
Date: Wednesday, July 26, 2017 at 9:43 PM
To: Darrell Ball <db...@vmware.com>
Cc: "ovs-discuss@openvswitch.org" <ovs-discuss@openvswitch.org>
Subject: Re: [ovs-discuss] OVS-DPDK IP fragmentation require

Thanks Darrell, comment inline.

On Thu, Jul 27, 2017 at 12:08 PM, Darrell Ball 
<db...@vmware.com<mailto:db...@vmware.com>> wrote:


From: 
<ovs-discuss-boun...@openvswitch.org<mailto:ovs-discuss-boun...@openvswitch.org>>
 on behalf of Hui Xiang <xiangh...@gmail.com<mailto:xiangh...@gmail.com>>
Date: Wednesday, July 26, 2017 at 7:47 PM
To: "ovs-discuss@openvswitch.org<mailto:ovs-discuss@openvswitch.org>" 
<ovs-discuss@openvswitch.org<mailto:ovs-discuss@openvswitch.org>>
Subject: [ovs-discuss] OVS-DPDK IP fragmentation require

Hi guys,

  Seems OVS-DPDK still missing IP fragmentation support, is there any schedule 
to have it?
OVS 2.9
I'm  transferring to use OVN, but for those nodes which have external network 
connection, they may face this problem,
except to configure Jumbo frames, is there any other workaround?

I am not clear on the situation however.
You mention about configuring jumbo frames which means you can avoid the 
fragments by doing this ?
No, I can't guarantee that, only can do it inside OpenStack, it is limited.
If this is true, then this is the best way to proceed since performance will be 
better.
What is wrong with jumbo frames ?
It's good but it's limited can't be guaranteed, so I am asking is there any 
other way without IP fragmentation so far.

It sounds like you want to avoid IP fragmentation; so far so good.
I am not sure I understand the whole picture though.
Maybe you can describe what you see ?; maybe a simple diagram would help ?


BR.
Hui.

___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS with DPDK QoS (Priority Queue)

[Darrell Ball]

-Original Message-
From:  on behalf of Aleksey Khalikov 

Date: Wednesday, July 19, 2017 at 1:06 AM
To: "ovs-discuss@openvswitch.org" 
Subject: [ovs-discuss] OVS with DPDK QoS (Priority Queue)

Hello guys!

I have another important question regarding QoS mechanisms.

Does OVS with DPDK have a possibility to create multiple queues and put 
the traffic with different priorities to corresponding queues.

Is this what you are looking for ?
https://mail.openvswitch.org/pipermail/ovs-dev/2017-July/335986.html


If not, will you put on the development of these features?

Thanks in advance!

Very best regards,

Aleksey


___
discuss mailing list
disc...@openvswitch.org

https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddiscuss=DwICAg=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=tMtWoJzQ8XByPuSKllI9T8nE4Mm_P9M-2PjiZun115E=YUddvIkJ-Uzprveu6cX-ZncdMB1ahJuQkLeYGFBSz1I=
 


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS-DPDK IP fragmentation require

[Darrell Ball]

From:  on behalf of Hui Xiang 

Date: Wednesday, July 26, 2017 at 7:47 PM
To: "ovs-discuss@openvswitch.org" 
Subject: [ovs-discuss] OVS-DPDK IP fragmentation require

Hi guys,

  Seems OVS-DPDK still missing IP fragmentation support, is there any schedule 
to have it?
OVS 2.9
I'm  transferring to use OVN, but for those nodes which have external network 
connection, they may face this problem,
except to configure Jumbo frames, is there any other workaround?

I am not clear on the situation however.
You mention about configuring jumbo frames which means you can avoid the 
fragments by doing this ?
If this is true, then this is the best way to proceed since performance will be 
better.
What is wrong with jumbo frames ?


BR.
Hui.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] max mega flow 64k per pmd or per dpcls?

[Darrell Ball]

From: Hui Xiang <xiangh...@gmail.com>
Date: Thursday, June 29, 2017 at 6:57 PM
To: Darrell Ball <db...@vmware.com>
Cc: "Bodireddy, Bhanuprakash" <bhanuprakash.bodire...@intel.com>, 
"ovs-discuss@openvswitch.org" <ovs-discuss@openvswitch.org>
Subject: Re: [ovs-discuss] max mega flow 64k per pmd or per dpcls?

I am interested about how to define 'reasonable' here, how it is got and what 
what is the 'many case'? is there any document/link to refer this information, 
please shed me some light.

It is based on real usage scenarios for the number of megaflows needed.
The usage may be less in most cases.
In cases where larger, it may imply that more threads are better and dividing 
among queues.

Why do think having more than 64k per PMD would be optimal ?
What is your use case(s) ?
Are you wanting for this number to be larger by default ?
Are you wanting for this number to be configurable ?


On Thu, Jun 29, 2017 at 10:47 PM, Darrell Ball 
<db...@vmware.com<mailto:db...@vmware.com>> wrote:
Q: “how it is calculated in such an exact number? “

A: It is a reasonable number to accommodate many cases.

Q: “If there are more ports added for polling, for avoid competing can I 
increase the 64k size into a
bigger one?”

A: If a larger number is needed, it may imply that adding another PMD and 
dividing the forwarding
work would be best.  Maybe even a smaller number of flows may be best served 
with more PMDs.





On 6/29/17, 7:23 AM, 
"ovs-discuss-boun...@openvswitch.org<mailto:ovs-discuss-boun...@openvswitch.org>
 on behalf of Bodireddy, Bhanuprakash" 
<ovs-discuss-boun...@openvswitch.org<mailto:ovs-discuss-boun...@openvswitch.org>
 on behalf of 
bhanuprakash.bodire...@intel.com<mailto:bhanuprakash.bodire...@intel.com>> 
wrote:

>

>I guess the answer is now the general LLC is 2.5M per core so that there 
is 64k

>flows per thread.



AFAIK, the no. of flows here may not have to do anything with LLC.  Also 
there is EMC cache(8k entries) of ~4MB per PMD thread.





Yes the performance will be nice with simple test cases (P2P with 1 PMD 
thread) as most of this fits in to LLC. But in real scenarios  OvS-DPDK can be 
memory bound.



BTW, on my DUT the LLC is 35MB and has 28 cores and so the assumption of 
2.5M/core isn't right.



- Bhanuprakash.



>

>On Fri, Jun 23, 2017 at 11:15 AM, Hui Xiang 
<xiangh...@gmail.com<mailto:xiangh...@gmail.com>> wrote:

>Thanks Darrell,

>

>More questions:

>Why not allocating 64k for each dpcls? does the 64k just fit in L3 cache or

>anywhere? how it is calculated in such an exact number?  If there are more

>ports added for polling, for avoid competing can I increase the 64k size 
into a

>bigger one? Thanks.

>

>Hui.

>

>


___
discuss mailing list
disc...@openvswitch.org<mailto:disc...@openvswitch.org>

https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddiscuss=DwIGaQ=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=-aL2AdnELLqgfD2paHXevABAGM7lXVTVcc-WMLHqINE=pSk0G_pj9n5VvpbG_ukDYkjSnSmA9Q9h37XchMZofuU=


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] max mega flow 64k per pmd or per dpcls?

[Darrell Ball]

Q: “how it is calculated in such an exact number? “

A: It is a reasonable number to accommodate many cases.

Q: “If there are more ports added for polling, for avoid competing can I 
increase the 64k size into a
bigger one?”

A: If a larger number is needed, it may imply that adding another PMD and 
dividing the forwarding
work would be best.  Maybe even a smaller number of flows may be best served 
with more PMDs.





On 6/29/17, 7:23 AM, "ovs-discuss-boun...@openvswitch.org on behalf of 
Bodireddy, Bhanuprakash"  wrote:

>

>I guess the answer is now the general LLC is 2.5M per core so that there 
is 64k

>flows per thread.



AFAIK, the no. of flows here may not have to do anything with LLC.  Also 
there is EMC cache(8k entries) of ~4MB per PMD thread.





Yes the performance will be nice with simple test cases (P2P with 1 PMD 
thread) as most of this fits in to LLC. But in real scenarios  OvS-DPDK can be 
memory bound.



BTW, on my DUT the LLC is 35MB and has 28 cores and so the assumption of 
2.5M/core isn't right. 



- Bhanuprakash.



>

>On Fri, Jun 23, 2017 at 11:15 AM, Hui Xiang  wrote:

>Thanks Darrell,

>

>More questions:

>Why not allocating 64k for each dpcls? does the 64k just fit in L3 cache or

>anywhere? how it is calculated in such an exact number?  If there are more

>ports added for polling, for avoid competing can I increase the 64k size 
into a

>bigger one? Thanks.

>

>Hui.

>

>



___
discuss mailing list
disc...@openvswitch.org

https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddiscuss=DwIGaQ=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=-aL2AdnELLqgfD2paHXevABAGM7lXVTVcc-WMLHqINE=pSk0G_pj9n5VvpbG_ukDYkjSnSmA9Q9h37XchMZofuU=
 


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [ovs-dev] rpmbuild failure for ovs_dpdk

[Darrell Ball]

Correction: ovs-discuss@openvswitch.org

On 6/20/17, 9:01 AM, "ovs-discuss-boun...@openvswitch.org on behalf of Darrell 
Ball" <ovs-discuss-boun...@openvswitch.org on behalf of db...@vmware.com> wrote:

Again, send to disc...@openvswitch.org



Do you see something like this ?



darrell@prmh-nsx-perf-server125:~/ovs/ovs_master$ grep -nr LDFLAGS 
_gcc/config.status 

846:S["OVS_LDFLAGS"]=" -L/usr/src/dpdk-16.11/x86_64-native-linuxapp-gcc/lib"



with dpdk-16.07 instead of dpdk-16.11

.

.

.



On 6/20/17, 5:43 AM, "ovs-dev-boun...@openvswitch.org on behalf of 王志克" 
<ovs-dev-boun...@openvswitch.org on behalf of wangzh...@jd.com> wrote:



Hi All,



I try to build rpm for ovs+dpdk, but met below compiling issue. Does 
someone know how to fix it? I guess it is related to LDFLAGS='-Wl,-z,relro 
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld, but no idea how to fix it.



If I follow below guide (non-rpm), everything is OK.


https://urldefense.proofpoint.com/v2/url?u=http-3A__docs.openvswitch.org_en_latest_intro_install_dpdk_=DwICAg=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=U_c6DG0MU2EKiNSi8V100nCZs5fqmWt3JWLXzyMTsCE=3m7uHcguxmbP_bpOW5kMPStCjz2C4mE5DPJSy1wYINY=
 



I use dpdk-16.07 and ovs 2.6 without any change.



[root@A01-R06-I187-15 openvswitch-2.6.0]# rpmbuild -bb --without check 
--with dpdk rhel/openvswitch-fedora.spec

Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.PBk26t

+ umask 022

+ cd /root/rpmbuild/BUILD

+ cd /root/rpmbuild/BUILD

+ rm -rf openvswitch-2.6.0

+ /usr/bin/gzip -dc /root/rpmbuild/SOURCES/openvswitch-2.6.0.tar.gz

+ /usr/bin/tar -xf -

+ STATUS=0

+ '[' 0 -ne 0 ']'

+ cd openvswitch-2.6.0

+ /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w .

+ exit 0

Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.ZxDsjh

+ umask 022

+ cd /root/rpmbuild/BUILD

+ cd openvswitch-2.6.0

+ CFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions 
-fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1  -m64 -mtune=generic'

+ export CFLAGS

+ CXXFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions 
-fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1  -m64 -mtune=generic'

+ export CXXFLAGS

+ FFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions 
-fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1  -m64 -mtune=generic 
-I/usr/lib64/gfortran/modules'

+ export FFLAGS

+ FCFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions 
-fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1  -m64 -mtune=generic 
-I/usr/lib64/gfortran/modules'

+ export FCFLAGS

+ LDFLAGS='-Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld'

+ export LDFLAGS

+ '[' 1 == 1 ']'

+ '[' x86_64 == ppc64le ']'

++ find . -name config.guess -o -name config.sub

+ for i in '$(find . -name config.guess -o -name config.sub)'

++ basename ./build-aux/config.guess

+ '[' -f /usr/lib/rpm/redhat/config.guess ']'

+ /usr/bin/rm -f ./build-aux/config.guess

++ basename ./build-aux/config.guess

+ /usr/bin/cp -fv /usr/lib/rpm/redhat/config.guess 
./build-aux/config.guess

'/usr/lib/rpm/redhat/config.guess' -> './build-aux/config.guess'

+ for i in '$(find . -name config.guess -o -name config.sub)'

++ basename ./build-aux/config.sub

+ '[' -f /usr/lib/rpm/redhat/config.sub ']'

+ /usr/bin/rm -f ./build-aux/config.sub

++ basename ./build-aux/config.sub

+ /usr/bin/cp -fv /usr/lib/rpm/redhat/config.sub ./build-aux/config.sub

'/usr/lib/rpm/redhat/config.sub' -> './build-aux/config.sub'

++ dirname /usr/share/dpdk/x86_64-default-linuxapp-gcc/.config

+ ./configure --build=x86_64-redhat-linux-gnu 
--host=x86_64-redhat-linux-gnu --program-prefix= --disable-dependency-tracking 
--prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin 
--sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include 
--libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var 
--sharedstatedir=/var/lib --mandir=/usr/share/man --infodir

Re: [ovs-discuss] OVS-DPDK - Very poor performance when connected to namespace/container

[Darrell Ball]

This should be quite a bit better than the AF_PACKET PMD. 
This becomes available in 17.08 and is important, it would be nice to get into 
the next OVS release.

Also, any existing data on the performance advantage of AF_PACKET PMD with 
single queue ?

Darrell


On 6/16/17, 1:56 AM, "ovs-discuss-boun...@openvswitch.org on behalf of Gray, 
Mark D"  wrote:

Hi Avi,

The other option is to use virtio-use 
(https://urldefense.proofpoint.com/v2/url?u=http-3A__dpdk.org_doc_guides_howto_virtio-5Fuser-5Ffor-5Fcontainer-5Fnetworking.html=DwICAg=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=_7l_cdKorhow4zRqAu5lnTmzv9Etgn5TX7D6P0pqP8c=ThmUVGZC2M1LBAIhnvs-5OiSZz7ywpez2Qj70BrQjoM=
 ) which gives dpdk-like performance to a dpdk application running in a 
container. The configuration for ovs-dpdk has not been documented but it is 
possible to use (as a vdev).

Also, I have dropped the dpdk-...@lists.01.org mail address as this is for 
the discontinued ovdk project.

Mark

> -Original Message-
> From: Dpdk-ovs [mailto:dpdk-ovs-boun...@lists.01.org] On Behalf Of
> Mooney, Sean K
> Sent: Thursday, June 15, 2017 12:33 PM
> To: Avi Cohen (A) ; dpdk-...@lists.01.org;
> us...@dpdk.org; ovs-discuss@openvswitch.org
> Subject: Re: [Dpdk-ovs] OVS-DPDK - Very poor performance when
> connected to namespace/container
> 
> 
> 
> > -Original Message-
> > From: Avi Cohen (A) [mailto:avi.co...@huawei.com]
> > Sent: Thursday, June 15, 2017 9:50 AM
> > To: Mooney, Sean K ; dpdk-...@lists.01.org;
> > us...@dpdk.org; ovs-discuss@openvswitch.org
> > Subject: RE: OVS-DPDK - Very poor performance when connected to
> > namespace/container
> >
> >
> >
> > > -Original Message-
> > > From: Mooney, Sean K [mailto:sean.k.moo...@intel.com]
> > > Sent: Thursday, 15 June, 2017 11:24 AM
> > > To: Avi Cohen (A); dpdk-...@lists.01.org; us...@dpdk.org; ovs-
> > > disc...@openvswitch.org
> > > Cc: Mooney, Sean K
> > > Subject: RE: OVS-DPDK - Very poor performance when connected to
> > > namespace/container
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Dpdk-ovs [mailto:dpdk-ovs-boun...@lists.01.org] On Behalf Of
> > > > Avi Cohen (A)
> > > > Sent: Thursday, June 15, 2017 8:14 AM
> > > > To: dpdk-...@lists.01.org; us...@dpdk.org;
> > > > ovs-discuss@openvswitch.org
> > > > Subject: [Dpdk-ovs] OVS-DPDK - Very poor performance when
> > > > connected to namespace/container
> > > >
> > > > Hello   All,
> > > > I have OVS-DPDK connected to a namespace via veth pair device.
> > > >
> > > > I've got a very poor performance - compared to normal OVS (i.e. no
> > > > DPDK).
> > > > For example - TCP jumbo pkts throughput: normal OVS  ~ 10Gbps ,
> > OVS-
> > > > DPDK 1.7 Gbps.
> > > >
> > > > This can be explained as follows:
> > > > veth is implemented in kernel - in OVS-DPDK data is transferred
> > from
> > > > veth to user space while in normal OVS we save this transfer
> > > [Mooney, Sean K] that is part of the reason, the other reson this is
> > > slow and The main limiter to scalling adding veth pairs or ovs
> > > internal port to ovs with dpdk is That these linux kernel ports are
> > > not processed by the dpdk pmds. They are server by the Ovs-vswitchd
> > > main thread via a fall back to the non dpdk acclarated netdev
> > implementation.
> > > >
> > > > Is there any other device to connect to namespace ? something like
> > > > vhost-user ? I understand that vhost-user cannot be used for
> > > > namespace
> > > [Mooney, Sean K] I have been doing some experiments in this regard.
> > > You should be able to use the tap, pcap or afpacket pmd to add a
> > > vedv that will improve Performance. I have seen some strange issue
> > > with
> > the
> > > tap pmd that cause packet to be drop By the kernel on tx on some
> > ports
> > > but not others so there may be issues with that dirver.
> > >
> > > Previous experiment with libpcap seemed to work well with ovs 2.5
> > > but I have not tried it With ovs 2.7/master since the introduction
> > > of generic vdev support at runtime. Previously vdevs And to be
> > > allocated
> > using the dpdk args.
> > >
> > > I would try following the af_packet example here
> > >
> >
> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openvswitch_ovs_blob_b132189d8456f38f3ee139f126d68=DwICAg=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=_7l_cdKorhow4zRqAu5lnTmzv9Etgn5TX7D6P0pqP8c=REyqxTB8Gd9BnEtetH_Aul0OgyyGK0DFhKl3tFGzOGI=
 
> 0
> > > 9 01a9ee9a8/Documentation/howto/dpdk.rst#vdev-support
> > >

Re: [ovs-discuss] [ovs-dev] How to efficiently connect docker network to ovs+dpdk switch

[Darrell Ball]

Pls use the ovs-discuss mailing list


On 6/15/17, 5:46 AM, "ovs-dev-boun...@openvswitch.org on behalf of 王志克" 
 wrote:

Hi All,

Previously I use kernel ovs, and docker veth-pair port can be added to ovs 
bridge directly. In this case, docker traffic from kernel will direct to ovs 
kernel module.

Now I want to use ovs+dpdk to speed up the forwarding performance, but I am 
wondering how docker traffic would go to ovs userspace bridge. From my 
understanding, veth-pair traffic would
always go from kernel, and it needs to be copied to userspace, then bridged 
by ovs+dpdk. The performance is quite low.

So question:
1) What is the proposed docker network port for ovs+dpdk? Ideally kernel 
should NOT be involved. I am not sure whether it is possible.
2) currently veth-pair port can only be handled by main thread 
(NON_PMD_CORE_ID) since its is_pmd attributes is false. This means it can only 
be handled by 1 CPU. How can multiple CPU handle such case?

Br,
Wang Zhike

___
dev mailing list
d...@openvswitch.org

https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev=DwICAg=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=XStPvCJIaKLmJge8S1ORuqJ8EtXnY3eVeGxZgW7F3Xo=jAxn10xcjrlumptia0fIu73EfFFut5hMd2_P-GjZ5HY=
 


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] vhost-user multiqueue PMD RSS

[Darrell Ball]

Try not to drop the list

In the general case, including the specific case that you mention, today’s 
design
is to select a queue from the tx port queues starting from low ID, that has the
least contending PMD threads.


From: Hui Jing <h.jing...@gmail.com>
Date: Sunday, June 11, 2017 at 2:33 PM
To: Darrell Ball <db...@vmware.com>
Subject: Re: [ovs-discuss] vhost-user multiqueue PMD RSS

Hi Darrell Ball,

Thanks for your reply with the link. Actually, my question comes from there 
when I was reading the article. In the article, Everything makes perfect sense 
when it says each PMD handle a single queue of the NIC. I am wondering what if 
one PMD thread is responsible for more queues (which is possible) of the VNIC, 
or in other words, number of  PMD threads is less than the number of queues of  
vhost-user. In this case, how the PMD distribute traffic.

Best regards,
Hui

On Sun, Jun 11, 2017 at 7:21 PM, Darrell Ball 
<db...@vmware.com<mailto:db...@vmware.com>> wrote:
https://software.intel.com/en-us/articles/configure-vhost-user-multiqueue-for-ovs-with-dpdk<https://urldefense.proofpoint.com/v2/url?u=https-3A__software.intel.com_en-2Dus_articles_configure-2Dvhost-2Duser-2Dmultiqueue-2Dfor-2Dovs-2Dwith-2Ddpdk=DwMFaQ=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=t6e4fxDY-056Dec9-A_jqM07-wRZIe-IM57ykiU0cuU=5rFLcAUhoV5uqReRdeUzso2tbYhv67Az02iDwKvWs3I=>


From: 
<ovs-discuss-boun...@openvswitch.org<mailto:ovs-discuss-boun...@openvswitch.org>>
 on behalf of Hui Jing <h.jing...@gmail.com<mailto:h.jing...@gmail.com>>
Date: Sunday, June 11, 2017 at 5:04 AM
To: "ovs-discuss@openvswitch.org<mailto:ovs-discuss@openvswitch.org>" 
<ovs-discuss@openvswitch.org<mailto:ovs-discuss@openvswitch.org>>
Subject: [ovs-discuss] vhost-user multiqueue PMD RSS

Hi all,

I am new to OVS-DPDK and trying to figure out the mechanism of vhost-user 
multiqueue scenario. I understand that the PMD thread is created for polling 
the queues of vhost-user or physical NIC and the affinity bind PMD to queues. 
However, the PMD transmission side confused me, I would like to learn PMD 
thread mechanism and how it distributes traffic to different queues.

Let's consider this scenario: one PMD thread is responsible for two queues of 
one vhost-user, when packet destined to the vhost-user, how it decide which 
queue to trasmit? is there equivalence to RSS?
  =
  |Rx Queue0|
Traffic ==>PMD thread ==>  ==>Virtio Frontend in VM
  |Rx Queue1|
  =
Thanks in advance
Best Regards,
Hui

___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS-DPDK polling cycles and processing cycles for pmd

[Darrell Ball]

From: <ovs-discuss-boun...@openvswitch.org> on behalf of Darrell Ball 
<db...@vmware.com>
Date: Sunday, June 11, 2017 at 10:55 AM
To: Hui Xiang <xiangh...@gmail.com>, "ovs-discuss@openvswitch.org" 
<ovs-discuss@openvswitch.org>
Subject: Re: [ovs-discuss] OVS-DPDK polling cycles and processing cycles for pmd



From: <ovs-discuss-boun...@openvswitch.org> on behalf of Hui Xiang 
<xiangh...@gmail.com>
Date: Saturday, June 10, 2017 at 9:06 PM
To: "ovs-discuss@openvswitch.org" <ovs-discuss@openvswitch.org>
Subject: [ovs-discuss] OVS-DPDK polling cycles and processing cycles for pmd

Hi guys,

  I got below results on my environment, but confusing with the cycles 
percents, it looks like the polling plus processing cycles per pmd is 100%, but 
as I recalled there are some improvment document that showed their processing 
cycles are 100% percents which means 0 for polling cycles? how should be the 
rate of polling and processing cycles take? should it be better for less 
polling and much processing for performance's benefits?

“polling” is checking for packets, but there are none to process.

Above will be the definition when
https://patchwork.ozlabs.org/patch/729970/
is pushed.
In the software that you are using,  “polling” is the time spent polling
when there are no packets and also polling/receiving/batching packets.
Using this definition, polling percentage will not go below “some value”,
since even if all polling cycles receive packets that time spent 
polling/receiving/batching
is counted as “polling”.


input more packets -> higher “processing” percentage.

pmd thread numa_id 1 core_id 27:
emc hits:141332792126
megaflow hits:263
avg. subtable lookups per hit:1.00
miss:59
lost:0
polling cycles:19832152639760 (12.60%)
processing cycles:137517517407771 (87.40%)
avg cycles per packet: 1113.33 (157349670047531/141332792711)
avg processing cycles per packet: 973.01 (137517517407771/141332792711)


Thanks a lot.
BR.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS-DPDK polling cycles and processing cycles for pmd

[Darrell Ball]

From:  on behalf of Hui Xiang 

Date: Saturday, June 10, 2017 at 9:06 PM
To: "ovs-discuss@openvswitch.org" 
Subject: [ovs-discuss] OVS-DPDK polling cycles and processing cycles for pmd

Hi guys,

  I got below results on my environment, but confusing with the cycles 
percents, it looks like the polling plus processing cycles per pmd is 100%, but 
as I recalled there are some improvment document that showed their processing 
cycles are 100% percents which means 0 for polling cycles? how should be the 
rate of polling and processing cycles take? should it be better for less 
polling and much processing for performance's benefits?

“polling” is checking for packets, but there are none to process.
input more packets -> higher “processing” percentage.

pmd thread numa_id 1 core_id 27:
emc hits:141332792126
megaflow hits:263
avg. subtable lookups per hit:1.00
miss:59
lost:0
polling cycles:19832152639760 (12.60%)
processing cycles:137517517407771 (87.40%)
avg cycles per packet: 1113.33 (157349670047531/141332792711)
avg processing cycles per packet: 973.01 (137517517407771/141332792711)


Thanks a lot.
BR.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] vhost-user multiqueue PMD RSS

[Darrell Ball]

https://software.intel.com/en-us/articles/configure-vhost-user-multiqueue-for-ovs-with-dpdk


From:  on behalf of Hui Jing 

Date: Sunday, June 11, 2017 at 5:04 AM
To: "ovs-discuss@openvswitch.org" 
Subject: [ovs-discuss] vhost-user multiqueue PMD RSS

Hi all,

I am new to OVS-DPDK and trying to figure out the mechanism of vhost-user 
multiqueue scenario. I understand that the PMD thread is created for polling 
the queues of vhost-user or physical NIC and the affinity bind PMD to queues. 
However, the PMD transmission side confused me, I would like to learn PMD 
thread mechanism and how it distributes traffic to different queues.

Let's consider this scenario: one PMD thread is responsible for two queues of 
one vhost-user, when packet destined to the vhost-user, how it decide which 
queue to trasmit? is there equivalence to RSS?
  =
  |Rx Queue0|
Traffic ==>PMD thread ==>  ==>Virtio Frontend in VM
  |Rx Queue1|
  =
Thanks in advance
Best Regards,
Hui
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] UFID - is flow ufid persistent ?

[Darrell Ball]

ufid is derived from a hash of the flow key, so the value of ufid is 
“consistent”


On 5/17/17, 1:33 AM, "ovs-discuss-boun...@openvswitch.org on behalf of Avi 
Cohen (A)"  wrote:

TWIMC - Solved - the answer is yes.
Just add flow in open-flow and make it installed in dp , then evicted , 
then reinstalled  - the ufid is the same.

> -Original Message-
> From: Avi Cohen (A)
> Sent: Wednesday, 17 May, 2017 9:41 AM
> To: 'ovs-discuss@openvswitch.org'
> Subject: UFID - is flow ufid persistent ?
> 
> Hello,
> Please can you help with this short question:
> Is the unique  flow identifier (ufid)  persistent ?
> i.e. flow-a is in dp-cache with  ufid = 1000, then the flow is evicted 
from dp-
> cache , and after 5 minutes the same flow-a is reinstalled in dp-cache.  
The
> question - is  flow-a is being assigned  ufid = 1000 again ?
> Best Regards
> avi
___
discuss mailing list
disc...@openvswitch.org

https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddiscuss=DwICAg=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=grxSdzUqPgCIrBl1ob9VtoSgF7AMeevbBB49XXoC9UQ=eNR1s7rgKE3saH_6-542hGHkwPsmmQIjCbX_7aOPlVk=
 


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS 2.7.0 + DPDK 17.02 + multicore

[Darrell Ball]

From: Levente Csikor <csi...@tmit.bme.hu>
Date: Sunday, May 7, 2017 at 6:31 AM
To: Darrell Ball <db...@vmware.com>, "disc...@openvswitch.org" 
<disc...@openvswitch.org>
Subject: Re: [ovs-discuss] OVS 2.7.0 + DPDK 17.02 + multicore

Thanks, it's working now! The 'interface' was the keyword indeed!

Do I need to do the affinity ``trick'' as well?
I mean the part similar to after '\' in the following:

ovs-vsctl set interface dpdk-p0 options:n_rxq=4 \

other_config:pmd-rxq-affinity="0:3,1:7,3:8"
I realized that without this OVS automatically assigns cores/threads to the 
queues, however when I explicitly set it (like above), the output of 
'ovs-appctl dpif-netdev/pmd-rxq-show' says for those threads that they are 
isolated (isolated: true).
Otherwise, the value of isolated is false.
Does it have any (significant) impact on the performance or on anything else?

“Isolated” is just an attribute of a PMD and means the PMD will only poll a 
specified set of queues.
Affinity could be used to enforce more predictability (in terms of throughout 
and latency) for those queues.




Cheers


On 05/07/2017 01:12 AM, Darrell Ball wrote:


From: 
<ovs-discuss-boun...@openvswitch.org><mailto:ovs-discuss-boun...@openvswitch.org>
 on behalf of Levente Csikor <csi...@tmit.bme.hu><mailto:csi...@tmit.bme.hu>
Date: Saturday, May 6, 2017 at 3:36 AM
To: "disc...@openvswitch.org"<mailto:disc...@openvswitch.org> 
<disc...@openvswitch.org><mailto:disc...@openvswitch.org>
Subject: [ovs-discuss] OVS 2.7.0 + DPDK 17.02 + multicore

Dear All,

I would like to run OVS with DPDK using multiple cores by multiple poll-mode 
driver threads to fine tune the performance and achieve higher packet rate.
I realized that since version 2.5.0 the multiple core assignment changed a bit, 
and I followed the instructions at 
http://docs.openvswitch.org/en/latest/intro/install/dpdk/<https://urldefense.proofpoint.com/v2/url?u=http-3A__docs.openvswitch.org_en_latest_intro_install_dpdk_=DwMDaQ=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=L_sO_555UZCkLTLLfgsvpixjfPj6uRLy9AJhNbSppMA=5qBNp8XzYYYmUz6gGXR0eYxcQ3QIjEF3jU526iCJe00=>

Everything is properly installed and set with respect to hugepages, dpdk 
drivers, etc.

Here is the relevant part of my init-script, for instance, in case of 3 cores:
sudo $OVS_PATH/utilities/ovs-vsctl --no-wait set Open_vSwitch . 
other_config:dpdk-init=true
sudo $OVS_PATH/utilities/ovs-vsctl --no-wait set Open_vSwitch . 
other_config:dpdk-lcore-mask=e
sudo $OVS_PATH/utilities/ovs-vsctl --no-wait set Open_vSwitch . 
other_config:dpdk-socket-mem="4096,0"
sudo $OVS_PATH/utilities/ovs-vsctl --no-wait set Open_vSwitch . 
other_config:dpdk-hugepage-dir="/mnt/huge"

sudo $OVS_PATH/utilities/ovs-vsctl --no-wait set Open_vSwitch . 
other_config:pmd-cpu-mask=e
sudo $OVS_PATH/utilities/ovs-vsctl --no-wait set Open_vSwitch . 
other_config:n-rxq=3



*

I guess you want “options : n_rxq” in Interface table

see
http://openvswitch.org/support/dist-docs/ovs-vswitchd.conf.db.5.pdf<https://urldefense.proofpoint.com/v2/url?u=http-3A__openvswitch.org_support_dist-2Ddocs_ovs-2Dvswitchd.conf.db.5.pdf=DwMDaQ=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=3jDNcjtjrAEW8uHiSQEpQ8wq18Wqmzww-elLHB8A3-U=R2ZvfMV-uexWNNs3kOvrbfbXl_6X6N_YKhVVbtwIV4M=>

also, you should read

http://docs.openvswitch.org/en/latest/howto/dpdk/<https://urldefense.proofpoint.com/v2/url?u=http-3A__docs.openvswitch.org_en_latest_howto_dpdk_=DwMDaQ=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=3jDNcjtjrAEW8uHiSQEpQ8wq18Wqmzww-elLHB8A3-U=4Rtw6dRrXrG4vsf12kGPzhnYGLVbHoV4pWiqc39Q4pU=>


*



sudo $OVS_PATH/vswitchd/ovs-vswitchd   unix:$DB_SOCK --pidfile --detach

I also tried the older version of rx_queue setup that worked for version 2.5.0:
sudo $OVS_PATH/utilities/ovs-vsctl set Open_vSwitch . other_config:n-dpdk-rxqs=3

Open vSwitch starts, but after installing numerous flow rules, sending 
different packets with different L2/L3/L4 headers (to foster RSS), it did not 
scale up. It still used only 1 core.
Linux command top showed only 100% CPU load instead of 300%, or even when I 
checked /proc/cpuinfo it also showed that only 1 core is scaled up to the 
maximum CPU frequency.
(Furthermore, if the outputs of these programs were wrong after all, I check 
the packet rate as well, but it did not change unfortunately)


Would anyone be so kind as to further assist me towards using multiple cores?
What did I miss/do wrong?

Thank you in advance,
Levi







___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS 2.7.0 + DPDK 17.02 + multicore

[Darrell Ball]

From:  on behalf of Levente Csikor 

Date: Saturday, May 6, 2017 at 3:36 AM
To: "disc...@openvswitch.org" 
Subject: [ovs-discuss] OVS 2.7.0 + DPDK 17.02 + multicore

Dear All,

I would like to run OVS with DPDK using multiple cores by multiple poll-mode 
driver threads to fine tune the performance and achieve higher packet rate.
I realized that since version 2.5.0 the multiple core assignment changed a bit, 
and I followed the instructions at 
http://docs.openvswitch.org/en/latest/intro/install/dpdk/

Everything is properly installed and set with respect to hugepages, dpdk 
drivers, etc.

Here is the relevant part of my init-script, for instance, in case of 3 cores:
sudo $OVS_PATH/utilities/ovs-vsctl --no-wait set Open_vSwitch . 
other_config:dpdk-init=true
sudo $OVS_PATH/utilities/ovs-vsctl --no-wait set Open_vSwitch . 
other_config:dpdk-lcore-mask=e
sudo $OVS_PATH/utilities/ovs-vsctl --no-wait set Open_vSwitch . 
other_config:dpdk-socket-mem="4096,0"
sudo $OVS_PATH/utilities/ovs-vsctl --no-wait set Open_vSwitch . 
other_config:dpdk-hugepage-dir="/mnt/huge"

sudo $OVS_PATH/utilities/ovs-vsctl --no-wait set Open_vSwitch . 
other_config:pmd-cpu-mask=e
sudo $OVS_PATH/utilities/ovs-vsctl --no-wait set Open_vSwitch . 
other_config:n-rxq=3



*

I guess you want “options : n_rxq” in Interface table

see
http://openvswitch.org/support/dist-docs/ovs-vswitchd.conf.db.5.pdf

also, you should read

http://docs.openvswitch.org/en/latest/howto/dpdk/


*



sudo $OVS_PATH/vswitchd/ovs-vswitchd   unix:$DB_SOCK --pidfile --detach

I also tried the older version of rx_queue setup that worked for version 2.5.0:
sudo $OVS_PATH/utilities/ovs-vsctl set Open_vSwitch . other_config:n-dpdk-rxqs=3

Open vSwitch starts, but after installing numerous flow rules, sending 
different packets with different L2/L3/L4 headers (to foster RSS), it did not 
scale up. It still used only 1 core.
Linux command top showed only 100% CPU load instead of 300%, or even when I 
checked /proc/cpuinfo it also showed that only 1 core is scaled up to the 
maximum CPU frequency.
(Furthermore, if the outputs of these programs were wrong after all, I check 
the packet rate as well, but it did not change unfortunately)


Would anyone be so kind as to further assist me towards using multiple cores?
What did I miss/do wrong?

Thank you in advance,
Levi




___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] DPDK OVS HW offload related question

[Darrell Ball]

On 5/3/17, 12:52 PM, "Ben Pfaff"  wrote:

On Wed, May 03, 2017 at 04:56:43AM +, Patil, Harish wrote:
> >
> >
> >
> >
> >On 4/26/17, 11:45 AM, "ovs-discuss-boun...@openvswitch.org on behalf of
> >Patil, Harish"  >harish.pa...@cavium.com> wrote:
> >
> >
> >
> >>Hello,
> >
> >>
> >
> >>We are planning to utilize the rte_flow (generic flow interface)
> >
> >>introduced in DPDK 16.11. It provides, among other things, a flow
> >action
> >
> >>type called RTE_FLOW_ACTION_TYPE_MARK that attaches an arbitrary
> >32-bit
> >
> >>integer value for packets matching the flow director rules and sets
> >
> >>PKT_RX_FDIR_ID flag (flow director ID reported if FDIR match). Would
> >like
> >
> >>to understand the following:
> >
> >>1) Are the OVS changes in place to be able to make use of this 
driver
> >
> >>returned ³hint² (or flow-id) in the data path for lookups?
> >
> >No
> >
> > If so, can you
> >
> >>please provide code pointer?
> >
> >>2) Is that 32-bit tag/flow_id meant to be used for megaflow cache
> >only? 
> >
> >TBD, if future support were to exist.
> >
> >In
> >> the existing implementation, it seems NIC computed RSS hash is used
> >for
> >
> >>EMC only.
> >
> >right
> >
> >>
> >
> >>
> >
> >>Thanks,
> >
> >>Harish
> >
> >>
> >
> >>___
> >
> >>discuss mailing list
> >
> >>disc...@openvswitch.org
> >
> >
> 
>>https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org
> 
>>_mailman_listinfo_ovs-2Ddiscuss=DwIGaQ=uilaK90D4TOVoH58JNXRgQ=BVhFA
> 
>>09CGX7JQ5Ih-uZnsw=NovoJUYtW_IELGmBQfcq_LmZIGaZjtiobvV3LQZNsTM=0JxsIyI
> >>P8DxTHzgbXFk5ziJmbIfB3j1xcUl-4ri8KV8=
> >
> >>
> >
> >
> >
> >Reposting this question, haven’t received any response.
> >
> >First of all, is this the right forum for this question?
> >
> >Could someone at least suggest who would the right folks to answer
> >this?
> >
> >
> >
> >Thanks.
> >
> >
> >
> >___
> >discuss mailing list
> >disc...@openvswitch.org
> >
> 
>https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_
> 
>mailman_listinfo_ovs-2Ddiscuss=DwIGaQ=uilaK90D4TOVoH58JNXRgQ=BVhFA09
> 
>CGX7JQ5Ih-uZnsw=NovoJUYtW_IELGmBQfcq_LmZIGaZjtiobvV3LQZNsTM=0JxsIyIP8D
> >xTHzgbXFk5ziJmbIfB3j1xcUl-4ri8KV8=
> >
> >
> >
> 
> I missed this email due to my filter settings.
> Thanks Darrell for your response.
> Do you know when OVS changes might be available to take advantage of HW
> provided flow_id info for the matching flows?

Has anyone proposed such changes?

This fits into the HWOL category of Partial Offload of Classification.
There are “related proposals”; I am not sure what level of exploratory
work, if any, is being done here. I am not aware of any “concrete efforts”
at this moment.

  I am not aware of it.  I'd suggest
that, if it's something that is likely to help with your project, then
you should consider implementing these changes yourself.







___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] DPDK OVS HW offload related question

[Darrell Ball]

On 4/26/17, 11:45 AM, "ovs-discuss-boun...@openvswitch.org on behalf of Patil, 
Harish"  wrote:



>Hello,

>

>We are planning to utilize the rte_flow (generic flow interface)

>introduced in DPDK 16.11. It provides, among other things, a flow action

>type called RTE_FLOW_ACTION_TYPE_MARK that attaches an arbitrary 32-bit

>integer value for packets matching the flow director rules and sets

>PKT_RX_FDIR_ID flag (flow director ID reported if FDIR match). Would like

>to understand the following:

>1) Are the OVS changes in place to be able to make use of this driver

>returned ³hint² (or flow-id) in the data path for lookups?

No

 If so, can you

>please provide code pointer?

>2) Is that 32-bit tag/flow_id meant to be used for megaflow cache only? 

TBD, if future support were to exist.

In
> the existing implementation, it seems NIC computed RSS hash is used for

>EMC only.

right

>

>

>Thanks,

>Harish

>

>___

>discuss mailing list

>disc...@openvswitch.org


>https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddiscuss=DwIGaQ=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=NovoJUYtW_IELGmBQfcq_LmZIGaZjtiobvV3LQZNsTM=0JxsIyIP8DxTHzgbXFk5ziJmbIfB3j1xcUl-4ri8KV8=
 

>



Reposting this question, haven’t received any response.

First of all, is this the right forum for this question?

Could someone at least suggest who would the right folks to answer this?



Thanks.



___
discuss mailing list
disc...@openvswitch.org

https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddiscuss=DwIGaQ=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=NovoJUYtW_IELGmBQfcq_LmZIGaZjtiobvV3LQZNsTM=0JxsIyIP8DxTHzgbXFk5ziJmbIfB3j1xcUl-4ri8KV8=
 


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] dpdkvhostuser interface

[Darrell Ball]

On 4/26/17, 12:06 AM, "ovs-discuss-boun...@openvswitch.org on behalf of Avi 
Cohen (A)"  wrote:

Hello,
dpdkvhostuserclient interface type  is used to connect a VM to the ovs-dpdk 
Is it possible to connect a container/namespace to ovs-dpdk with this 
interface type ?

No
dpdkvhostuser and dpdkvhostuserclient (which are preferred) socket ports are 
used to
connect OVS-dpdk in a host to qemu for VM connectivity.

Currently I use veth pair , but got poor performance
Best Regards
avi 
___
discuss mailing list
disc...@openvswitch.org

https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddiscuss=DwICAg=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=Okbwpv6yDJHjjqoDbvCyLbKduJS4TG1aJ-0HyaAeApE=dj4nOGTQtZBPSgNbhBY63SWb5WaGtnnzO2nsA1dBIG4=
 


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] support for ct argument alg=ftp when running openvswitch with dpdk in userspace

[Darrell Ball]

I am working on it.

Thanks Darrell

On 4/3/17, 8:40 AM, "ovs-discuss-boun...@openvswitch.org on behalf of Patrick 
Bergamin"  wrote:

Hi,

It doesn't appear that openvswitch using dpdk and running in
userspace supports the ct argument alg=ftp.  I was wondering
if anyone is currently working on adding support for it? If not
has any thought been put into how it might be implemented.
Would it be done in a similar fashion to the iptables
implementation?

thanks,
Patrick

___
discuss mailing list
disc...@openvswitch.org

https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddiscuss=DwICAg=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=awCdx3tZCZjfwldowypCei--fEtuX8vDqwW7jqZy6v4=EOu9Mg945e98o8VtN0T-5AVYe0SoR65oIbcP7lUTxTc=
 


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] SR-IOV with Open vSwitch

[Darrell Ball]

The topology diagram provided makes it clear that all the packet flow is 
internal to a single PF.
Maybe check that the nic bridge is working as expected; you don’t need OVS 
running to verify that.

From: Advith Nagappa <advith.naga...@gmail.com>
Date: Saturday, April 1, 2017 at 11:18 PM
To: Purnendu <purne...@gmail.com>
Cc: Darrell Ball <db...@vmware.com>, discuss <disc...@openvswitch.org>
Subject: Re: [ovs-discuss] SR-IOV with Open vSwitch

Hi  Purnendu,

Thank you for the response.

I d like to apologize for the mistake that I made in the diagram.

I mixed up the ip addresses in my init diagram. The configuration actually is:


10.0.0.1(SOURCE)      10.0.0.3(OVS)   --- 10.0.0.2(SINK)

@10.0.0.1<https://urldefense.proofpoint.com/v2/url?u=http-3A__10.0.0.1=DwMFaQ=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=TCOMlrhKLGP3O2h7ruzgIA6-5j5iuvyDEC0752E3Qyk=N5ubGAAnPxDmlL4E0r00s-bFdN1yzadL9FDlviOSWm0=>
ip route 10.0.0.2 gw 10.0.0.3

@10.0.0.3<https://urldefense.proofpoint.com/v2/url?u=http-3A__10.0.0.3=DwMFaQ=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=TCOMlrhKLGP3O2h7ruzgIA6-5j5iuvyDEC0752E3Qyk=droEZDI_huugicsU3sLA4XsgNIUUyMPbdUGUTRJVWHA=>
ip_forwarding=on
ovs-ofctl add-flow br0  
priority=,dl_type=0x0800,nw_proto=17,nw_src=10.0.0.1,nw_dst=10.0.0.2,actions=




On Apr 1, 2017 23:05, "Purnendu" 
<purne...@gmail.com<mailto:purne...@gmail.com>> wrote:
Hi Advith,Darrel,

With SR-IOV configured the packet flow among the VMs would traverse through the 
PHY.
I put a diagram.

BR,
Purnendu

On Sat, Apr 1, 2017 at 1:38 PM, Advith Nagappa 
<advith.naga...@gmail.com<mailto:advith.naga...@gmail.com>> wrote:
I have attached a sketch of the topology.

I send 14 packets from Source(10.0.0.1), I receive 14 at Sink.(10.0.0.2)

I also see 14 packets hitting the rule at OVS(drop rule at 10.0.0.3)
 cookie=0x0, duration=123.175s, table=0, n_packets=14, n_bytes=60, idle_age=2, 
priority=,udp,nw_src=10.0.0.1,nw_dst=10.0.0.2 actions=drop

And I can say with confidence that there are no other UDP packets in the system.

On Fri, Mar 31, 2017 at 10:45 PM, Darrell Ball 
<db...@vmware.com<mailto:db...@vmware.com>> wrote:


From: Advith Nagappa <advith.naga...@gmail.com<mailto:advith.naga...@gmail.com>>
Date: Friday, March 31, 2017 at 1:14 PM
To: Darrell Ball <db...@vmware.com<mailto:db...@vmware.com>>
Cc: discuss <disc...@openvswitch.org<mailto:disc...@openvswitch.org>>
Subject: Re: [ovs-discuss] SR-IOV with Open vSwitch

Darrell,

Thank you for the resources and the response.

I am not using a Linux bridge at host. Just SR-IOV to pass through the 
hypervisor.

My guess here is that the although the three guests are assigned one virtual 
functions(VF) each, since all three VFs are sliced out of the same underlying 
Physical function (and this they are.), the rules at the OVS are somehow 
overridden. I don't know if this guess is anywhere close to being accurate..

The overriding hypothesis seems unlikely, at least by what I understand by the 
term.
It would be helpful to have a diagram of packet sourcing and sinking; i.e. 
where are the packets sent from and
where is the counting of the received ones - “but the packet is not dropped:”

Also, are the “received packets” the UDP packets you are tracking or some other 
ones.



On Mar 31, 2017 01:16, "Darrell Ball" 
<db...@vmware.com<mailto:db...@vmware.com>> wrote:


From: 
<ovs-discuss-boun...@openvswitch.org<mailto:ovs-discuss-boun...@openvswitch.org>>
 on behalf of Advith Nagappa 
<advith.naga...@gmail.com<mailto:advith.naga...@gmail.com>>
Date: Wednesday, March 29, 2017 at 9:39 PM
To: discuss <disc...@openvswitch.org<mailto:disc...@openvswitch.org>>
Subject: [ovs-discuss] SR-IOV with Open vSwitch

Hello All,


Has anyone used SR-IOV with Open vSwitch(in a guest)?

My understanding is that SR-IOV is hypervisor(host) by/pass, Hence using OVS at 
that level would not make sense..

So I tried deploying OVS in an SR-IOV enabled guest, and here is what I 
observed..

I have one virtual function within my guest, called ens7.

I have added that to by OVS-bridge..



d5f266fc-a6f1-448e-91c5-e6db8748f73f
Bridge "br0"
Port "ens7"
Interface "ens7"
Port "br0"
Interface "br0"
type: internal

I also, added the following rule:

ovs-ofctl add-flow br0  
priority=,dl_type=0x0800,nw_proto=17,nw_src=10.0.0.1,nw_dst=10.0.0.2,actions=


However every time I send a UDP datagram, I see that this rule is hit!, but the 
packet is not dropped:

 cookie=0x0, duration=123.175s, table=0, n_packets=14, n_bytes=60, idle_age=2, 
priority=,udp,nw_src=10.0.0.1,nw_dst=10.0.0.2 actions=drop

The thing here is 10.0.0.1 and 10.0.0.2 share a physical function,.. and, 
despite the rule hit, the datagram is forwar

Re: [ovs-discuss] SR-IOV with Open vSwitch

[Darrell Ball]

From: Advith Nagappa <advith.naga...@gmail.com>
Date: Friday, March 31, 2017 at 1:14 PM
To: Darrell Ball <db...@vmware.com>
Cc: discuss <disc...@openvswitch.org>
Subject: Re: [ovs-discuss] SR-IOV with Open vSwitch

Darrell,

Thank you for the resources and the response.

I am not using a Linux bridge at host. Just SR-IOV to pass through the 
hypervisor.

My guess here is that the although the three guests are assigned one virtual 
functions(VF) each, since all three VFs are sliced out of the same underlying 
Physical function (and this they are.), the rules at the OVS are somehow 
overridden. I don't know if this guess is anywhere close to being accurate..

The overriding hypothesis seems unlikely, at least by what I understand by the 
term.
It would be helpful to have a diagram of packet sourcing and sinking; i.e. 
where are the packets sent from and
where is the counting of the received ones - “but the packet is not dropped:”

Also, are the “received packets” the UDP packets you are tracking or some other 
ones.



On Mar 31, 2017 01:16, "Darrell Ball" 
<db...@vmware.com<mailto:db...@vmware.com>> wrote:


From: 
<ovs-discuss-boun...@openvswitch.org<mailto:ovs-discuss-boun...@openvswitch.org>>
 on behalf of Advith Nagappa 
<advith.naga...@gmail.com<mailto:advith.naga...@gmail.com>>
Date: Wednesday, March 29, 2017 at 9:39 PM
To: discuss <disc...@openvswitch.org<mailto:disc...@openvswitch.org>>
Subject: [ovs-discuss] SR-IOV with Open vSwitch

Hello All,


Has anyone used SR-IOV with Open vSwitch(in a guest)?

My understanding is that SR-IOV is hypervisor(host) by/pass, Hence using OVS at 
that level would not make sense..

So I tried deploying OVS in an SR-IOV enabled guest, and here is what I 
observed..

I have one virtual function within my guest, called ens7.

I have added that to by OVS-bridge..



d5f266fc-a6f1-448e-91c5-e6db8748f73f
Bridge "br0"
Port "ens7"
Interface "ens7"
Port "br0"
Interface "br0"
type: internal

I also, added the following rule:

ovs-ofctl add-flow br0  
priority=,dl_type=0x0800,nw_proto=17,nw_src=10.0.0.1,nw_dst=10.0.0.2,actions=


However every time I send a UDP datagram, I see that this rule is hit!, but the 
packet is not dropped:

 cookie=0x0, duration=123.175s, table=0, n_packets=14, n_bytes=60, idle_age=2, 
priority=,udp,nw_src=10.0.0.1,nw_dst=10.0.0.2 actions=drop

The thing here is 10.0.0.1 and 10.0.0.2 share a physical function,.. and, 
despite the rule hit, the datagram is forwarded, I wonder what may be causing 
this? I am guessing some kind of L2 switching at the NIC level, which overrides 
OVS? Does anyone have an experience with this..


You are running OVS in the VM(s), not the host.
I assume you are sending packets in one direction only and are constantly 
hitting an L2 broadcast case in the Linux bridge in the host
(this is also an assumption, since you don’t delineate all your config. and 
topology).
So, I guess one copy of the packet is bypassing OVS in the VM and another copy 
is sent to OVS in the VM to be dropped.

Below link has more information and child links from there.

https://github.com/intel/SDN-NFV-Hands-on-Samples/blob/master/SR-IOV_DPDK_Hands-on_Lab/docs/SR-IOV-HandsOn-IEEE.pdf<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_intel_SDN-2DNFV-2DHands-2Don-2DSamples_blob_master_SR-2DIOV-5FDPDK-5FHands-2Don-5FLab_docs_SR-2DIOV-2DHandsOn-2DIEEE.pdf=DwMFaQ=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=YxFaqFip6Yx8m_S1rRQJOt69mM8X50oOAA7F1TpEwNc=utBGEpRDhujM_F5GBaXHebC6S9K9UA0kf-o18GeeV8M=>



Best Regards
Advith Nagappa
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Error attaching device to DPDK

[Darrell Ball]

On 3/29/17, 7:40 AM, "O Mahony, Billy" <billy.o.mah...@intel.com> wrote:

Hi All,



Just to add something to this conversation that has not been explicitly 
mentioned below.



Brad outlines how to set other_config:dpdk-socket-mem to reserve hugepages 
from both NUMA nodes in order to be sure to avoid pci topology issues.



Strictly this doesn’t have to be done on both nodes – just on the correct 
node :) – but sometimes it’s easier to just cover all the bases.



In addition you will need to ensure that:

 * That linux has hugepages available on both (or the right) nodes.

 * There is a pmd thread created on each node by setting 
other_config:pmd-cpu-mask correctly – or again at least on the right node.



These config items are described in 

* ./Documentation/intro/install/dpdk.rst

* ./Documentation/howto/dpdk.rst



Currently if there is not a pmd thread on the NUMA node belonging to the 
PCI device the device will not be polled (a warning message is issued to this 
effect).


[Darrell]
From Linux POV, the “default” memory policy is to allocate the hugepage pool 
across numa nodes, if possible;
this assumes an allocation was done, which we have no reports here otherwise.
iirc based on the logs in this case, which I cannot view anymore, there was no 
pmd mask configuration specified.
The advertised behavior should be, in this case, that a pmd thread is allocated 
on each numa node with at
least one local dpdk interface bound.
iirc, the dpdk socket memory was left at default, which only pre-allocated from 
the hugepage pool on node 0
So, does it make sense to also try to pre-allocate hugepages on a numa node, 
where a PMD thread is allocated ?
Pls correct me in any respects.

 



There is currently a patch under consideration so that if a NUMA-local pmd 
is not available for a device then device will be assigned to some other pmd 
thread. While this is not as efficient due to the need for the data to travel 
between NUMA nodes it is less frustrating to configure. 




https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_pipermail_ovs-2Ddev_2017-2DFebruary_329175.html=DwIGaQ=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=IKHiqOFj5oogxEfx6OMgK9IHxp2aktbssMBTZUoA2P0=QmpnHwqCC8ZBxRGZgfCZuF-9SielPs89Yd-k7crooC8=
 



If you install the hwloc package you can use “hwloc-calc pci=:01:02.0 
--intersect Socket” to show the NUMA node that is local to a pci device. 
However I have seen some systems which report that pci device is local to both 
nodes. The lstopo command can also be used for this.



Hope some of that helps,



Billy.





From: ovs-discuss-boun...@openvswitch.org 
[mailto:ovs-discuss-boun...@openvswitch.org] On Behalf Of Darrell Ball

Sent: Wednesday, March 29, 2017 2:36 AM

To: Brad Cowie <b...@cowie.nz>; Shivaram Mysore <shivaram.mys...@gmail.com>

Cc: ovs-discuss@openvswitch.org

Subject: Re: [ovs-discuss] Error attaching device to DPDK







From: <ovs-discuss-boun...@openvswitch.org> on behalf of Brad Cowie 
<b...@cowie.nz>

Date: Tuesday, March 28, 2017 at 5:35 PM

To: Shivaram Mysore <shivaram.mys...@gmail.com>

Cc: "ovs-discuss@openvswitch.org" <ovs-discuss@openvswitch.org>

Subject: Re: [ovs-discuss] Error attaching device to DPDK



Hi folks,

I have been helping Shivaram off-list with this problem and just wanted to 
update this thread with the solution.

Basically the issue was with how hugepages were being preallocated by OVS 
for use with DPDK. I believe by default OVS sets other_config:dpdk-socket-mem 
to "1024,0". Which will give one 1GB hugepage to CPU0 and none to CPU1.

The ports Shivaram was trying to assign to DPDK were connected physically 
via a PCI-E bus to CPU1 and since there are no hugepages preallocated there for 
DPDK then we can't add it.

The fix is simple, to assign a hugepage to CPU1:



$ sudo ovs-vsctl --no-wait set Open_vSwitch . 
other_config:dpdk-socket-mem="1024,1024"

In OVS 2.7.0 unfortunately due to an issue (that is now fixed by commit 
ef6cca6fdc67f3cee21c6bb1c13c4ca7f8241314) you get a segfault rather than an 
error message telling you the problem.

In OVS 2.7.90 however the issue becomes quite clear as there is a nice log 
message like such:



2017-03-29T00:19:57Z|00067|netdev_dpdk|ERR|Insufficient memory to create 
memory pool for netdev dpdk-p0, with MTU 1500 on socket 1

There is documentation regarding these fields, but for case, the 
documentation could simply state something like

“you need to a

Re: [ovs-discuss] Error attaching device to DPDK

[Darrell Ball]

   1.688787] DMAR: Hardware identity mapping for device :00:04.1
>>[1.688790] DMAR: Hardware identity mapping for device :00:04.2
>>[1.688792] DMAR: Hardware identity mapping for device :00:04.3
>>[1.688794] DMAR: Hardware identity mapping for device :00:04.4
>>[1.688797] DMAR: Hardware identity mapping for device :00:04.5
>>[1.688799] DMAR: Hardware identity mapping for device :00:04.6
>>[1.688801] DMAR: Hardware identity mapping for device :00:04.7
>>[1.688803] DMAR: Hardware identity mapping for device :00:05.0
>>[1.688807] DMAR: Hardware identity mapping for device :00:05.1
>>[1.688809] DMAR: Hardware identity mapping for device :00:05.2
>>[1.688811] DMAR: Hardware identity mapping for device :00:05.4
>>[1.688814] DMAR: Hardware identity mapping for device :00:11.0
>>[1.688816] DMAR: Hardware identity mapping for device :00:11.4
>>[1.688818] DMAR: Hardware identity mapping for device :00:14.0
>>[1.688821] DMAR: Hardware identity mapping for device :00:16.0
>>[1.688823] DMAR: Hardware identity mapping for device :00:16.1
>>[1.688825] DMAR: Hardware identity mapping for device :00:1a.0
>>[1.688828] DMAR: Hardware identity mapping for device :00:1c.0
>>[1.688831] DMAR: Hardware identity mapping for device :00:1c.2
>>[1.688833] DMAR: Hardware identity mapping for device :00:1d.0
>>[1.688835] DMAR: Hardware identity mapping for device :00:1f.0
>>[1.688837] DMAR: Hardware identity mapping for device :00:1f.2
>>[1.688844] DMAR: Hardware identity mapping for device :00:1f.3
>>[1.688846] DMAR: Hardware identity mapping for device :00:1f.6
>>[1.688864] DMAR: Hardware identity mapping for device :01:00.0
>>[1.688870] DMAR: Hardware identity mapping for device :01:00.1
>>[1.688876] DMAR: Hardware identity mapping for device :01:00.2
>>[1.63] DMAR: Hardware identity mapping for device :01:00.3
>>[1.688895] DMAR: Hardware identity mapping for device :80:01.0
>>[1.688899] DMAR: Hardware identity mapping for device :80:02.0
>>[1.688903] DMAR: Hardware identity mapping for device :80:03.0
>>[1.688906] DMAR: Hardware identity mapping for device :80:04.0
>>[1.688908] DMAR: Hardware identity mapping for device :80:04.1
>>[1.688911] DMAR: Hardware identity mapping for device :80:04.2
>>[1.688913] DMAR: Hardware identity mapping for device :80:04.3
>>[1.688915] DMAR: Hardware identity mapping for device :80:04.4
>>[1.688918] DMAR: Hardware identity mapping for device :80:04.5
>>[1.688920] DMAR: Hardware identity mapping for device :80:04.6
>>[1.688923] DMAR: Hardware identity mapping for device :80:04.7
>>[1.688936] DMAR: Hardware identity mapping for device :80:05.0
>>[1.688940] DMAR: Hardware identity mapping for device :80:05.1
>>[1.688943] DMAR: Hardware identity mapping for device :80:05.2
>>[1.688945] DMAR: Hardware identity mapping for device :80:05.4
>>[1.688956] DMAR: Hardware identity mapping for device :81:00.0
>>[1.688961] DMAR: Hardware identity mapping for device :81:00.1
>>[1.688974] DMAR: Hardware identity mapping for device :82:00.0
>>[1.688980] DMAR: Hardware identity mapping for device :82:00.1
>>[1.688986] DMAR: Hardware identity mapping for device :82:00.2
>>[1.688992] DMAR: Hardware identity mapping for device :82:00.3
>>[1.689006] DMAR: Hardware identity mapping for device :83:00.0
>>[1.689012] DMAR: Hardware identity mapping for device :83:00.1
>>[1.689018] DMAR: Hardware identity mapping for device :83:00.2
>>[1.689024] DMAR: Hardware identity mapping for device :83:00.3
>>[1.689025] DMAR: Setting RMRR:
>>[1.689026] DMAR: Ignoring identity map for HW passthrough device
>>:00:14.0 [0x7ba75000 - 0x7ba84fff]
>>[1.689027] DMAR: Ignoring identity map for HW passthrough device
>>:00:1a.0 [0x7ba75000 - 0x7ba84fff]
>>[1.689028] DMAR: Ignoring identity map for HW passthrough device
>>:00:1d.0 [0x7ba75000 - 0x7ba84fff]
>>[1.689036] DMAR: Prepare 0-16MiB unity mapping for LPC
>>[1.689036] DMAR: Ignoring identity map for HW passthrough device
>>:00:1f.0 [0x0 - 0xff]
>>[1.689040] DMAR: Intel(R) Virtualization Technology for Directed I/O
>>[2.299766] DMAR: 32bit :00:11.4 uses non-identity mapping
>>[2.301941] DMAR: 32bit :00:1a.0 uses non-identity mapping
>&g

Re: [ovs-discuss] Error attaching device to DPDK

[Darrell Ball]

see inline below

But a few questions:

1)   Are you using the recommended version of dpdk with OVS 2.7 – 16.11 ?

2)   Are you getting a crash still or is this post crash ?

3)   Was the previous crash still happening with 16.11 or only 17.02 ?

Thanks
Darrell

From:  on behalf of Shivaram Mysore 

Date: Monday, March 27, 2017 at 7:45 PM
To: "ovs-discuss@openvswitch.org" 
Subject: [ovs-discuss] Error attaching device to DPDK

Hello,

I have installed OVS 2.7 running.  When I do:
1.  # ovs-vsctl add-port ovs-ip64-br0 dpdk-p0 -- set Interface dpdk-p0 
type=dpdk options:dpdk-devargs=:82:00.0
2.  ovs-vsctl: Error detected while setting up 'dpdk-p0': Error attaching 
device ':82:00.0' to DPDK.  See ovs-vswitchd log for details.

Possibly, the port is not bound.
Check using
$DPDK_DIR/tools/dpdk-devbind.py –status
and see the documentation for more detail

and the log file shows:
1.  2017-03-28T02:04:40.004Z|00064|netdev_dpdk|WARN|Error attaching device 
':82:00.0' to DPDK
2.  2017-03-28T02:04:40.004Z|00065|netdev|WARN|dpdk-p0: could not set 
configuration (Invalid argument)

What would cause such a situation?

Commands run: 
https://pastebin.com/0P754x0t
Detailed OVS Log: 
https://pastebin.com/ctBhLuRG
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS-DPDK

[Darrell Ball]

Regarding the question:

“Also, what is OVS-2.6.1's version on options:dpdk-devargs='', by that I 
mean, how does the dpdk port know which interface should it bind to when its 
not specified.. “

Here is a previous thread that answers this question:
https://mail.openvswitch.org/pipermail/ovs-discuss/2016-March/040190.html

We could document this in OVS DPDK as it is function impacting.


From: Advith Nagappa <advith.naga...@gmail.com>
Date: Tuesday, March 21, 2017 at 2:46 PM
To: "Stokes, Ian" <ian.sto...@intel.com>
Cc: Darrell Ball <db...@vmware.com>, "disc...@openvswitch.org" 
<disc...@openvswitch.org>
Subject: Re: [ovs-discuss] OVS-DPDK

Hi Ian,

Yes, I am using OVS-2.6.1 release.

And yes, you are correct.

ovs-vsctl add-port br0 dpdk-p1 -- set Interface dpdk-p1 type=dpdk, infact fails 
in 2.6.1;

whereas, ovs-vsctl add-port br0 dpdk1 -- set Interface dpdk1 type=dpdk, 
succeeds.


As regards the use of

options:dpdk-devargs=:00:0a.0

It is only needed if you are using arbitrary port naming/hotplug support which 
is included in OVS 2.7.0.

This answers my query.

But, If i may continue to ask a related query: from the dpdk log..

2017-03-21T03:14:01Z|7|dpdk|INFO|EAL ARGS: ovs-vswitchd --socket-mem 1024,0 
-c 0x0001
EAL: Detected 5 lcore(s)
EAL: Probing VFIO support...
EAL: WARNING: cpu flags constant_tsc=yes nonstop_tsc=no -> using unreliable 
clock cycles !
EAL: PCI device :00:07.0 on NUMA socket -1
EAL:   probe driver: 8086:154c net_i40e_vf
EAL: PCI device :00:09.0 on NUMA socket -1
EAL:   probe driver: 8086:1572 net_i40e
PMD: eth_i40e_dev_init(): FW 5.0 API 1.5 NVM 05.00.02 eetrack 80002284
EAL: PCI device :00:0a.0 on NUMA socket -1
EAL:   probe driver: 8086:1572 net_i40e
PMD: eth_i40e_dev_init(): FW 5.0 API 1.5 NVM 05.00.02 eetrack 80002284


Since I have done the binding 09.0 and 0a.0 to igb_uio driver, shouldn't we see 
'igb_uio' instead of 'net_i40e'?

Also, what is OVS-2.6.1's version on options:dpdk-devargs='', by that I 
mean, how does the dpdk port know which interface should it bind to when its 
not specified..
Here is a previous thread that answers this question:
https://mail.openvswitch.org/pipermail/ovs-discuss/2016-March/040190.html

Best Regards
Advith Nagappa







On Mar 21, 2017 12:00 PM, "Stokes, Ian" 
<ian.sto...@intel.com<mailto:ian.sto...@intel.com>> wrote:
Apologies for top posting,

Hi Advith, there seems to be a mismatch of OVS versions and expected features 
from the details you have provided.

To confirm you are using OVS 2.6.1? Is there a specific commit ID you are 
using? Or are you using the 2.6.1 tag or release package?

From the commands you have provided it looks like your trying to add dpdk ports 
with arbitrary names and PCI addresses.

This is not possible in OVS 2.6.1, this ability was only added as of OVS 2.7.0.

If you wanted to add 2 physical dpdk ports with 2.6.1 can you try the following

ovs-vsctl add-port br0 dpdk0 -- set Interface dpdk0 type=dpdk
ovs-vsctl add-port br0 dpdk1 -- set Interface dpdk1 type=dpdk

Note the name of the dpdk port must start with dpdk followed by the number 
being added (starting at 0). This is a limitation that has since been removed 
in OVS 2.7.

I’m surprised that you say you can use

ovs-vsctl add-port br0 dpdk-p1 -- set Interface dpdk-p1 type=dpdk

Testing OVS 2.6.1 tag on master with that command returned the vsctl error

ovs-vsctl: Error detected while setting up 'dpdk-p1'.  See ovs-vswitchd log for 
details.

for myself which would be expected.

As regards the use of

options:dpdk-devargs=:00:0a.0

It is only needed if you are using arbitrary port naming/hotplug support which 
is included in OVS 2.7.0.

If you can give these suggestions a shot it will help narrow down the issue at 
hand.

Regards
Ian

From: 
ovs-discuss-boun...@openvswitch.org<mailto:ovs-discuss-boun...@openvswitch.org> 
[mailto:ovs-discuss-boun...@openvswitch.org<mailto:ovs-discuss-boun...@openvswitch.org>]
 On Behalf Of Advith Nagappa
Sent: Tuesday, March 21, 2017 8:12 AM
To: Darrell Ball <db...@vmware.com<mailto:db...@vmware.com>>
Cc: disc...@openvswitch.org<mailto:disc...@openvswitch.org>
Subject: Re: [ovs-discuss] OVS-DPDK

I don’t see the pci memory mapping logs here.
Can you also attach the full dpdk logs ?

I have attached the dpdk-log.

For PCI mapping, may below helps:



Bus info  Device  Class  Description

pci@:00:07.0<mailto:pci@:00:07.0>  ens7network
XL710/X710 Virtual Function
pci@:00:09.0<mailto:pci@:00:09.0>  networkEthernet 
Controller X710 for 10GbE   
   SFP+
pci@:00:0a.0<mailto:pci@:00:0a.0>  networkEthernet 
Controller X710 for 10GbE

Re: [ovs-discuss] OVS+DPDK: socket permissions' problem

[Darrell Ball]

From:  on behalf of Aynur Shakirov 

Date: Tuesday, March 21, 2017 at 6:17 AM
To: "ovs-discuss@openvswitch.org" 
Subject: [ovs-discuss] OVS+DPDK: socket permissions' problem


Hello.
Meta.
OVS ver: 2.7.90, today master (stp tests skipped)
Compiler: GCC 5.3.1, default flags
DPDK: 16.11.1 (from Ubuntu Cloud Archive: Ocata)
Env: Ubuntu 16.04.1 up-to-date.
Kernel: 4.8.0-41-generic

Problem.
When I adds a vhost-interface into bridge OVS specifies incorrect rights for 
the socket:

root@dpdk-compute0:/opt/build# ovs-vsctl add-port br-ex vhost-user-1 -- set 
Interface vhost-user-1 type=dpdkvhostuser

2017-03-21T12:09:33.436Z|00115|dpdk|INFO|VHOST_CONFIG: vhost-user server: 
socket created, fd: 46
2017-03-21T12:09:33.436Z|00116|dpdk|INFO|VHOST_CONFIG: bind to 
/var/run/openvswitch/vhost-user-1
2017-03-21T12:09:33.436Z|00117|dpdk|INFO|EAL: Socket 
/var/run/openvswitch/vhost-user-1 changed permissions to 
2017-03-21T12:09:33.436Z|00118|dpdk|ERR|EAL: user �ƿ not found,  aborting.
2017-03-21T12:09:33.436Z|00119|dpdk|ERR|EAL: vhost-user socket unable to get 
specified user/group: �ƿ



This worked better for me. I am using similar ovs and dpdk versions, but older 
kernel
and distro 3.16.0-77-generic #99~14.04.1-Ubuntu.

.
.
2017-03-21T23:09:21.662Z|00104|netdev_dpdk|INFO|Socket 
/usr/local/var/run/openvswitch/vhost-user-1 created for vhost-user port 
vhost-user-1
2017-03-21T23:09:21.662Z|00105|bridge|INFO|bridge br0: added interface 
vhost-user-1 on port 6
.
.


darrell@---server125:~/ovs/ovs_master$ ll 
/usr/local/var/run/openvswitch/vhost-user-1
srwxr-xr-x 1 root root 0 Mar 21 16:30 
/usr/local/var/run/openvswitch/vhost-user-1=


However, I have the libvirt-qemu user, you seem to be missing; well, at least
based on the EAL logs.

darrell@ ---server125:~/ovs/ovs_master$ cat /etc/passwd | grep 
libvirt
libvirt-qemu:x:105:109:Libvirt Qemu,,,:/var/lib/libvirt:/bin/false

darrell@ ---server125:~/ovs/ovs_master$ groups libvirt-qemu
libvirt-qemu : kvm

darrell@ ---server125:~/ovs/ovs_master$ cat /etc/group | grep kvm
kvm:x:109:




Debug Log is 
here.

For past master (2 weeks ago and with -03/march=native compiler flags) OVS was 
trying to configure the socket owner as fdb/show.

DPDK Settings:

root@dpdk-compute0:/opt/build# ovs-vsctl --no-wait get Open_vSwitch . 
other_config
{dpdk-alloc-mem="2048", dpdk-extra="--vhost-owner libvirt-qemu:kvm --vhost-perm 
0666", dpdk-init="true", dpdk-lcore-mask="0x1", dpdk-socket-mem="1024,0"}

OVS config:

root@dpdk-compute0:/opt/build# ovs-vsctl show
972154fa-857e-45e8-b56b-77e5cb6eb685
Manager "ptcp:6640:127.0.0.1"
is_connected: true
Bridge br-int
Controller "tcp:127.0.0.1:6633"
is_connected: true
fail_mode: secure
Port int-br-ex
Interface int-br-ex
type: patch
options: {peer=phy-br-ex}
Port patch-tun
Interface patch-tun
type: patch
options: {peer=patch-int}
Port br-int
Interface br-int
type: internal
Bridge br-ex
Controller "tcp:127.0.0.1:6633"
is_connected: true
fail_mode: secure
Port "vhost-user-1"
Interface "vhost-user-1"
type: dpdkvhostuser
Port phy-br-ex
Interface phy-br-ex
type: patch
options: {peer=int-br-ex}
Port br-ex
Interface br-ex
type: internal
Port "intel_1g_1"
Interface "intel_1g_1"
type: dpdk
options: {dpdk-devargs=":06:00.1"}
Bridge br-tun
Controller "tcp:127.0.0.1:6633"
is_connected: true
fail_mode: secure
Port patch-int
Interface patch-int
type: patch
options: {peer=patch-tun}
Port br-tun
Interface br-tun
type: internal
ovs_version: "2.7.90"
root@dpdk-compute0:/opt/build#

Command for port add:

root@dpdk-compute0:/opt/build# ovs-vsctl add-port br-ex vhost-user-1 -- set 
Interface vhost-user-1 type=dpdkvhostuser

Actual socket rights after vhost create:

root@dpdk-compute0:/opt/build# ll /var/run/openvswitch/vhost-user-1
s- 1 root root 0 Mar 21 07:14 /var/run/openvswitch/vhost-user-1=

Why this happening? And one more question: can enable a debug logs for EAL over 
OVS?

Thanks for help.


--

Sincerely,

Aynur Shakirov, 27.

TIONIX RUS.

Planet Earth, Solar System, Milky Way.
___
discuss mailing list
disc...@openvswitch.org

Re: [ovs-discuss] High Priority Traffic Path (dscp) for DPDK-OvS

[Darrell Ball]

That’s right; that is what I meant by “this is yet even further away from your 
needs”

On 3/20/17, 11:50 PM, "Ali Volkan Atli" <volkan.a...@argela.com.tr> wrote:


I know ingress/egress policier but they cannot give me traffic 
prioritization, right? 

- Volkan
____
    From: Darrell Ball [db...@vmware.com]
Sent: Tuesday, March 21, 2017 9:43 AM
To: Ali Volkan Atli; disc...@openvswitch.org
Subject: Re: [ovs-discuss] High Priority Traffic Path (dscp) for DPDK-OvS

For completeness
There is also ingress side policing for DPDK support, but this is yet even 
further away from your needs

On 3/20/17, 11:08 PM, "ovs-discuss-boun...@openvswitch.org on behalf of 
Darrell Ball" <ovs-discuss-boun...@openvswitch.org on behalf of 
db...@vmware.com> wrote:

Afaik
OVS-DPDK only supports egress-policing qos

https://urldefense.proofpoint.com/v2/url?u=http-3A__openvswitch.org_support_dist-2Ddocs_ovs-2Dvswitchd.conf.db.5.pdf=DwICAg=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=RIWw06JUXu6nQ6rBtMjodUMOfYzlTQWCpl3cvhBcMqQ=dEB0J4ZNbb6D3fyTCQtQSOL4ESw61sttj73HOUu81OI=
see egress--policer

On 3/20/17, 10:30 PM, "ovs-discuss-boun...@openvswitch.org on behalf of 
Ali Volkan Atli" <ovs-discuss-boun...@openvswitch.org on behalf of 
volkan.a...@argela.com.tr> wrote:


Hi all

I need to specify a number of classes of service according to DSCP 
bits. Each class of service should be associated with a priority. For example: 
Packet A is sent with a DSCP value of 0 and packet B is sent with a value of 
46; 0 has a lower priority than 46. Packet A arrives before packet B. If 
DPDK-OvS has been configured as such, Packet B will be transmitted before 
Packet A.

I know that hardware switches have been designed to ensure certain 
classes of traffic can be scheduled ahead of other classes, also kernel mode 
OvS has the similar behavior coming from Linux kernel (tc, qdisk etc..). 
However, does DPDK-OvS have the same behavior? In master branch, I could not 
find any kind of scheduler to achieve this behavior.

Thanks in advance..

- Volkan
___
discuss mailing list
disc...@openvswitch.org

https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddiscuss=DwICAg=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=t_URk5HzgDgCEYW7ckfF7YlE3wYVnLqEFyHzFpjEWXk=OyfZtaFWTFg_JXtm1LpO0IIaABYbz8EWtKp3NZ7amGE=


___
discuss mailing list
disc...@openvswitch.org

https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddiscuss=DwICAg=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=RIWw06JUXu6nQ6rBtMjodUMOfYzlTQWCpl3cvhBcMqQ=KZd3tmsCEFpyjf2b4rRZRTqJmQaeFDy8dK0Xvrggjdo=




___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS-DPDK

[Darrell Ball]

From: Darrell Ball <db...@vmware.com>
Date: Monday, March 20, 2017 at 10:12 PM
To: Advith Nagappa <advith.naga...@gmail.com>, Ben Pfaff <b...@ovn.org>
Cc: "disc...@openvswitch.org" <disc...@openvswitch.org>
Subject: Re: [ovs-discuss] OVS-DPDK



From: <ovs-discuss-boun...@openvswitch.org> on behalf of Advith Nagappa 
<advith.naga...@gmail.com>
Date: Monday, March 20, 2017 at 8:19 PM
To: Ben Pfaff <b...@ovn.org>
Cc: "disc...@openvswitch.org" <disc...@openvswitch.org>
Subject: Re: [ovs-discuss] OVS-DPDK

It did not tell me anything:

Mar 20 11:42:23  ovs-vsctl: ovs|1|vsctl|INFO|Called as ovs-vsctl add-port 
br0 dpdk-p0 -- set Interface dpdk-p0 type=dpdk options:dpdk-devargs=:00:0a.0
Mar 20 11:42:23  ovs-vswitchd[23906]: ovs|00042|bridge|WARN|could not open 
network device dpdk-p0 (No such device)
Mar 20 11:42:23  ovs-vswitchd[23906]: ovs|00044|bridge|WARN|could not open 
network device dpdk-p0 (No such device)


A ./dpdk-devbind.py --status shows the below results, confirming device binding

Network devices using DPDK-compatible driver

:00:09.0 'Ethernet Controller X710 for 10GbE SFP+' drv=igb_uio unused=i40e
:00:0a.0 'Ethernet Controller X710 for 10GbE SFP+' drv=igb_uio unused=i40e



Network devices using kernel driver
===
:00:07.0 'XL710/X710 Virtual Function' if=ens7 drv=i40evf unused=igb_uio 
*Active*

Other network devices
=


Crypto devices using DPDK-compatible driver
===


Crypto devices using kernel driver
==


Other crypto devices



But, I did notice a curious thing:

when I init OVS with dpdk, using:

ovs-vsctl --no-wait set Open_vSwitch . other_config:dpdk-init=true
ovs-vsctl --no-wait set Open_vSwitch . other_config:dpdk-socket-mem="1024,0"




2017-03-21T03:14:01Z|7|dpdk|INFO|EAL ARGS: ovs-vswitchd --socket-mem 1024,0 
-c 0x0001
EAL: Detected 5 lcore(s)
EAL: Probing VFIO support...
EAL: WARNING: cpu flags constant_tsc=yes nonstop_tsc=no -> using unreliable 
clock cycles !
EAL: PCI device :00:07.0 on NUMA socket -1
EAL:   probe driver: 8086:154c net_i40e_vf
EAL: PCI device :00:09.0 on NUMA socket -1
EAL:   probe driver: 8086:1572 net_i40e
PMD: eth_i40e_dev_init(): FW 5.0 API 1.5 NVM 05.00.02 eetrack 80002284
EAL: PCI device :00:0a.0 on NUMA socket -1
EAL:   probe driver: 8086:1572 net_i40e
PMD: eth_i40e_dev_init(): FW 5.0 API 1.5 NVM 05.00.02 eetrack 80002284

I don’t see the pci memory mapping logs here.
Can you also attach the full dpdk logs ?
What is your kernel and dpdk versions ?
Can you share which portion of the following configuration you followed
http://docs.openvswitch.org/en/latest/intro/install/dpdk/



I was wondering if the probe driver for 09.0 and 0a.0 should have been 
something like 'igb_uio'.. I am not sure if this is how it should be?

Appreciate your inputs.

Best Regards
Advith Nagappa

On Tue, Mar 21, 2017 at 3:33 AM, Ben Pfaff <b...@ovn.org<mailto:b...@ovn.org>> 
wrote:
On Tue, Mar 21, 2017 at 02:36:23AM +0100, Advith Nagappa wrote:
> Hi,
>
> I have DPDK 16.11.1 and OVS 2.6.1, with 1 Gb Huge page/ and 2 NICs bound
> with Igb_uio drivers.
>
> I run in to trouble while creating DPDK ports on the OVS bridge.
>
>
> *ovs-vsctl add-port br0 dpdk-p1 -- set Interface dpdk-p1 type=dpdk*
>
> works perfectly fine.
>
> But,
>
> *ovs-vsctl add-port br0 dpdk-p0 -- set Interface dpdk-p0 type=dpdk
> options:dpdk-devargs=:00:0a.0*
>
> gives an error:
> ovs-vsctl: Error detected while setting up 'dpdk-p0'.  See ovs-vswitchd log
> for details.

What's in the log?

___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] High Priority Traffic Path (dscp) for DPDK-OvS

[Darrell Ball]

For completeness
There is also ingress side policing for DPDK support, but this is yet even 
further away from your needs

On 3/20/17, 11:08 PM, "ovs-discuss-boun...@openvswitch.org on behalf of Darrell 
Ball" <ovs-discuss-boun...@openvswitch.org on behalf of db...@vmware.com> wrote:

Afaik
OVS-DPDK only supports egress-policing qos

https://urldefense.proofpoint.com/v2/url?u=http-3A__openvswitch.org_support_dist-2Ddocs_ovs-2Dvswitchd.conf.db.5.pdf=DwICAg=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=RIWw06JUXu6nQ6rBtMjodUMOfYzlTQWCpl3cvhBcMqQ=dEB0J4ZNbb6D3fyTCQtQSOL4ESw61sttj73HOUu81OI=
 
see egress--policer

On 3/20/17, 10:30 PM, "ovs-discuss-boun...@openvswitch.org on behalf of Ali 
Volkan Atli" <ovs-discuss-boun...@openvswitch.org on behalf of 
volkan.a...@argela.com.tr> wrote:


Hi all

I need to specify a number of classes of service according to DSCP 
bits. Each class of service should be associated with a priority. For example: 
Packet A is sent with a DSCP value of 0 and packet B is sent with a value of 
46; 0 has a lower priority than 46. Packet A arrives before packet B. If 
DPDK-OvS has been configured as such, Packet B will be transmitted before 
Packet A.

I know that hardware switches have been designed to ensure certain 
classes of traffic can be scheduled ahead of other classes, also kernel mode 
OvS has the similar behavior coming from Linux kernel (tc, qdisk etc..). 
However, does DPDK-OvS have the same behavior? In master branch, I could not 
find any kind of scheduler to achieve this behavior. 

Thanks in advance..

- Volkan
___
discuss mailing list
disc...@openvswitch.org

https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddiscuss=DwICAg=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=t_URk5HzgDgCEYW7ckfF7YlE3wYVnLqEFyHzFpjEWXk=OyfZtaFWTFg_JXtm1LpO0IIaABYbz8EWtKp3NZ7amGE=
 


___
discuss mailing list
disc...@openvswitch.org

https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddiscuss=DwICAg=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=RIWw06JUXu6nQ6rBtMjodUMOfYzlTQWCpl3cvhBcMqQ=KZd3tmsCEFpyjf2b4rRZRTqJmQaeFDy8dK0Xvrggjdo=
 


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] High Priority Traffic Path (dscp) for DPDK-OvS

[Darrell Ball]

Afaik
OVS-DPDK only supports egress-policing qos
http://openvswitch.org/support/dist-docs/ovs-vswitchd.conf.db.5.pdf
see egress--policer

On 3/20/17, 10:30 PM, "ovs-discuss-boun...@openvswitch.org on behalf of Ali 
Volkan Atli"  wrote:


Hi all

I need to specify a number of classes of service according to DSCP bits. 
Each class of service should be associated with a priority. For example: Packet 
A is sent with a DSCP value of 0 and packet B is sent with a value of 46; 0 has 
a lower priority than 46. Packet A arrives before packet B. If DPDK-OvS has 
been configured as such, Packet B will be transmitted before Packet A.

I know that hardware switches have been designed to ensure certain classes 
of traffic can be scheduled ahead of other classes, also kernel mode OvS has 
the similar behavior coming from Linux kernel (tc, qdisk etc..). However, does 
DPDK-OvS have the same behavior? In master branch, I could not find any kind of 
scheduler to achieve this behavior. 

Thanks in advance..

- Volkan
___
discuss mailing list
disc...@openvswitch.org

https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddiscuss=DwICAg=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=t_URk5HzgDgCEYW7ckfF7YlE3wYVnLqEFyHzFpjEWXk=OyfZtaFWTFg_JXtm1LpO0IIaABYbz8EWtKp3NZ7amGE=
 


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss