Re: [ovs-discuss] OVS layer3 GRE support

[Ben Pfaff]

Can you test or examine the recent patches to see if they avoid the
problem you mention?  It probably won't be obvious as a problem during
review.

On Tue, Apr 25, 2017 at 01:46:41AM +, Hexin Wang wrote:
> Thanks. Good to know that this is being merged back to OVS mainline.
> 
> The old way of Layer3 GRE implementation via “base_layer” seems to have an 
> issue with ct_state_nat feature.
> Specifically if pop_mpls happens before ct(nat,), pop_mpls recirculation 
> would cause both flow->base_layer and base_flow->base_layer to be LAYER_3. 
> The recirculation triggered by ct(nat,) would fail if one of the commit 
> actions is to set layer2 header.
> 
> Regards,
> 
> Hexin 
> 
> 
> On 4/24/17, 5:29 PM, "Yang, Yi Y"  wrote:
> 
> >The userspace L3 patch set Zoltan posted has included L3 support for GRE, 
> >here it is.
> >
> >https://mail.openvswitch.org/pipermail/ovs-dev/2017-April/330490.html
> >
> >
> >-Original Message-
> >From: ovs-discuss-boun...@openvswitch.org 
> >[mailto:ovs-discuss-boun...@openvswitch.org] On Behalf Of Hexin Wang
> >Sent: Tuesday, April 25, 2017 2:42 AM
> >To: Ben Pfaff 
> >Cc: simon.hor...@netronome.com; ovs-discuss@openvswitch.org
> >Subject: Re: [ovs-discuss] OVS layer3 GRE support
> >
> >Right. I was specifically referring to the OVS layer3 tunnel support 
> >originated by Lorand Jakab and Simon Horman.
> >The changes made in kernel data path is merged back to Linux mainline by 
> >Jiri Benc. But the user space OVS changes are missing in ovs main tree.
> >
> >Thanks.
> >
> >Hexin
> >
> >
> >
> >
> >On 4/24/17, 11:37 AM, "Ben Pfaff"  wrote:
> >
> >>On Mon, Apr 24, 2017 at 06:25:07PM +, Hexin Wang wrote:
> >>> I got a question on OVS layer3 GRE tunnel support. The OVS kernel 
> >>> piece that supports layer 3 GRE is merged into linux upstream since
> >>> 4.10 RC6. Do we need any extra user land OVS merge for it to work 
> >>> end-to-end? I am referring to the “options:layer3=true” ovs-vsctl 
> >>> interface changes. Essentially, how is “push_mpls” action triggering 
> >>> the pop_eth action in kernel data path?
> >>
> >>This is not a subject I know well.  That said, it looks like OVS 
> >>userspace doesn't currently support layer-3 GRE tunnels in an 
> >>appropriate way.  I mainly base this on the code in 
> >>netdev_vport_is_layer3(), which considers only LISP ports to be layer-3 
> >>ports.
> >___
> >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] OVN knob to control floating IP NAT action

[Hexin Wang]

If I were to qualify the NAT action based on some route lookup instead of 
outport, is there any bit/register available for me to carry the nat decision 
down in the pipeline?

Thanks.

Hexin

From: 
>
 on behalf of Hexin Wang
Date: Monday, April 24, 2017 at 2:57 PM
To: Guru Shetty
Cc: "ovs-discuss@openvswitch.org"
Subject: Re: [ovs-discuss] OVN knob to control floating IP NAT action

Hi Guru,

Thanks. You probably referred to the unit test "ovn -- DNAT and SNAT on 
distributed router - E/W" in tests/system-ovn.at? Is there anyway for me to 
configure route based dnat_and_snat from ovn-nbctl? Specifically can I qualify 
the following command with some prefix routes?

  ovn-nbctl lr-nat-add R1 dnat_and_snat

Or maybe there is another way to achieve the same functionality?

Regards,

Hexin

From: Guru Shetty
Date: Monday, April 24, 2017 at 12:44 PM
To: Hexin Wang
Cc: "ovs-discuss@openvswitch.org"
Subject: Re: [ovs-discuss] OVN knob to control floating IP NAT action



On 24 April 2017 at 11:39, Hexin Wang 
> wrote:
Hi Guru,

Let me try with the following use cases.
1. No floating IP is used for east-west routing traffic.
E.g. VM1 <-> VM2: Private IPs are used. No NAT applied.

2. Floating IP is used for south-north default route to internet traffic.
E.g. VM originated internet traffic: SNAT is applied to change source IP to 
floating IP. UNSNAT is applied to change destination IP back to private IP.

Yes. There are examples in tests/system-traffic.at


Thanks.

Hexin

From: Guru Shetty
Date: Monday, April 24, 2017 at 11:34 AM
To: Hexin Wang
Cc: "ovs-discuss@openvswitch.org"
Subject: Re: [ovs-discuss] OVN knob to control floating IP NAT action



On 24 April 2017 at 11:31, Hexin Wang 
> wrote:
Hi,

Is there any knob in OVN to control when floating IP will be applied in the 
distributed NAT? Specifically:

  1.  If the destination IP is part of some private layer3 domain, the usual 
private IP is used to to reach the destination in the private layer3 domain.
  2.  If the destination IP is not part of the private layer3 domain but part 
of the public layer3 domain, the public IP (I.e. Floating IP) is used to 
replace the private IP address of the source packet.

I don't understand what you mean above. Please re-phrase with the direction of 
the packet.

Does OVN support this behavior today?

Thanks.

Hexin

___
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] OVS layer3 GRE support

[Hexin Wang]

Thanks. Good to know that this is being merged back to OVS mainline.

The old way of Layer3 GRE implementation via “base_layer” seems to have an 
issue with ct_state_nat feature.
Specifically if pop_mpls happens before ct(nat,), pop_mpls recirculation would 
cause both flow->base_layer and base_flow->base_layer to be LAYER_3. The 
recirculation triggered by ct(nat,) would fail if one of the commit actions is 
to set layer2 header.

Regards,

Hexin 


On 4/24/17, 5:29 PM, "Yang, Yi Y"  wrote:

>The userspace L3 patch set Zoltan posted has included L3 support for GRE, here 
>it is.
>
>https://mail.openvswitch.org/pipermail/ovs-dev/2017-April/330490.html
>
>
>-Original Message-
>From: ovs-discuss-boun...@openvswitch.org 
>[mailto:ovs-discuss-boun...@openvswitch.org] On Behalf Of Hexin Wang
>Sent: Tuesday, April 25, 2017 2:42 AM
>To: Ben Pfaff 
>Cc: simon.hor...@netronome.com; ovs-discuss@openvswitch.org
>Subject: Re: [ovs-discuss] OVS layer3 GRE support
>
>Right. I was specifically referring to the OVS layer3 tunnel support 
>originated by Lorand Jakab and Simon Horman.
>The changes made in kernel data path is merged back to Linux mainline by Jiri 
>Benc. But the user space OVS changes are missing in ovs main tree.
>
>Thanks.
>
>Hexin
>
>
>
>
>On 4/24/17, 11:37 AM, "Ben Pfaff"  wrote:
>
>>On Mon, Apr 24, 2017 at 06:25:07PM +, Hexin Wang wrote:
>>> I got a question on OVS layer3 GRE tunnel support. The OVS kernel 
>>> piece that supports layer 3 GRE is merged into linux upstream since
>>> 4.10 RC6. Do we need any extra user land OVS merge for it to work 
>>> end-to-end? I am referring to the “options:layer3=true” ovs-vsctl 
>>> interface changes. Essentially, how is “push_mpls” action triggering 
>>> the pop_eth action in kernel data path?
>>
>>This is not a subject I know well.  That said, it looks like OVS 
>>userspace doesn't currently support layer-3 GRE tunnels in an 
>>appropriate way.  I mainly base this on the code in 
>>netdev_vport_is_layer3(), which considers only LISP ports to be layer-3 
>>ports.
>___
>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

[ovs-discuss] 答复: 答复: about

[qintao (F)]

the valgrind's report as follows:

2017-04-25T01:38:16Z|00025|coverage|INFO|bridge_reconfigure 0.0/sec 
0.000/sec0./sec   total: 1
2017-04-25T01:38:16Z|00026|coverage|INFO|ofproto_flush  0.0/sec 
0.000/sec0./sec   total: 1
2017-04-25T01:38:16Z|00027|coverage|INFO|ofproto_update_port0.0/sec 
0.000/sec0./sec   total: 2
2017-04-25T01:38:16Z|00028|coverage|INFO|cmap_expand0.0/sec 
0.000/sec0./sec   total: 3
2017-04-25T01:38:16Z|00029|coverage|INFO|dpif_port_add  0.0/sec 
0.000/sec0./sec   total: 2
2017-04-25T01:38:16Z|00030|coverage|INFO|dpif_flow_flush0.0/sec 
0.000/sec0./sec   total: 2
2017-04-25T01:38:16Z|00031|coverage|INFO|dpif_flow_get  0.0/sec 
0.000/sec0./sec   total: 5
2017-04-25T01:38:16Z|00032|coverage|INFO|dpif_flow_put  0.0/sec 
0.000/sec0./sec   total: 9
2017-04-25T01:38:16Z|00033|coverage|INFO|dpif_flow_del  0.0/sec 
0.000/sec0./sec   total: 5
2017-04-25T01:38:16Z|00034|coverage|INFO|dpif_execute   0.0/sec 
0.000/sec0./sec   total: 2
2017-04-25T01:38:16Z|00035|coverage|INFO|flow_extract   0.0/sec 
0.000/sec0./sec   total: 1
2017-04-25T01:38:16Z|00036|coverage|INFO|miniflow_malloc0.0/sec 
0.000/sec0./sec   total: 44
2017-04-25T01:38:16Z|00037|coverage|INFO|hmap_pathological  0.0/sec 
0.000/sec0./sec   total: 2
2017-04-25T01:38:16Z|00038|coverage|INFO|hmap_expand0.0/sec 
0.000/sec0./sec   total: 412
2017-04-25T01:38:16Z|00039|coverage|INFO|netdev_get_stats   0.0/sec 
0.000/sec0./sec   total: 2
2017-04-25T01:38:16Z|00040|coverage|INFO|poll_create_node   0.0/sec 
0.000/sec0./sec   total: 9
2017-04-25T01:38:16Z|00041|coverage|INFO|seq_change 0.0/sec 
0.000/sec0./sec   total: 598
2017-04-25T01:38:16Z|00042|coverage|INFO|pstream_open   0.0/sec 
0.000/sec0./sec   total: 3
2017-04-25T01:38:16Z|00043|coverage|INFO|stream_open0.0/sec 
0.000/sec0./sec   total: 1
2017-04-25T01:38:16Z|00044|coverage|INFO|util_xalloc0.0/sec 
0.000/sec0./sec   total: 10064
2017-04-25T01:38:16Z|00045|coverage|INFO|netdev_set_policing0.0/sec 
0.000/sec0./sec   total: 2
2017-04-25T01:38:16Z|00046|coverage|INFO|netdev_get_ifindex 0.0/sec 
0.000/sec0./sec   total: 2
2017-04-25T01:38:16Z|00047|coverage|INFO|netdev_get_hwaddr  0.0/sec 
0.000/sec0./sec   total: 11
2017-04-25T01:38:16Z|00048|coverage|INFO|netdev_set_hwaddr  0.0/sec 
0.000/sec0./sec   total: 1
2017-04-25T01:38:16Z|00049|coverage|INFO|netdev_get_ethtool 0.0/sec 
0.000/sec0./sec   total: 4
2017-04-25T01:38:16Z|00050|coverage|INFO|netlink_received   0.0/sec 
0.000/sec0./sec   total: 16
2017-04-25T01:38:16Z|00051|coverage|INFO|netlink_recv_jumbo 0.0/sec 
0.000/sec0./sec   total: 2
2017-04-25T01:38:16Z|00052|coverage|INFO|netlink_sent   0.0/sec 
0.000/sec0./sec   total: 15
2017-04-25T01:38:16Z|00053|coverage|INFO|72 events never hit
2017-04-25T01:38:16Z|00054|bridge|INFO|ifname=enp1s0f0, vlan=4095, oper=1
BRIDGE_AA_VLA:i:0,reconfigure:0
==22676== Conditional jump or move depends on uninitialised value(s)
==22676==at 0x4E10DA: uuid_compare_3way (uuid.c:139)
==22676==by 0x4BB8AD: ovsdb_datum_find_key (ovsdb-data.c:1633)
==22676==by 0x40E922: bridge_configure_aa (bridge.c:3865)
==22676==by 0x40E922: bridge_reconfigure (bridge.c:710)
==22676==by 0x40FF67: bridge_run (bridge.c:2996)
==22676==by 0x40690C: main (ovs-vswitchd.c:120)
==22676== 
==22676== Conditional jump or move depends on uninitialised value(s)
==22676==at 0x4BB8B0: ovsdb_datum_find_key (ovsdb-data.c:1634)
==22676==by 0x40E922: bridge_configure_aa (bridge.c:3865)
==22676==by 0x40E922: bridge_reconfigure (bridge.c:710)
==22676==by 0x40FF67: bridge_run (bridge.c:2996)
==22676==by 0x40690C: main (ovs-vswitchd.c:120)
==22676== 
==22676== Conditional jump or move depends on uninitialised value(s)
==22676==at 0x4BB888: ovsdb_datum_find_key (ovsdb-data.c:1636)
==22676==by 0x40E922: bridge_configure_aa (bridge.c:3865)
==22676==by 0x40E922: bridge_reconfigure (bridge.c:710)
==22676==by 0x40FF67: bridge_run (bridge.c:2996)
==22676==by 0x40690C: main (ovs-vswitchd.c:120)
==22676== 
2017-04-25T01:38:17Z|00055|bridge|INFO|Deleting isid=1, vlan=4095
2017-04-25T01:38:17Z|00056|ovs_lldp|INFO|Removing mapping aux=0x7b663d0
2017-04-25T01:38:17Z|00057|ovs_lldp|INFO|Removing mapping ISID=1, 
VLAN=4095 (lldp->name=enp1s0f0)

Re: [ovs-discuss] OVS layer3 GRE support

[Yang, Yi Y]

The userspace L3 patch set Zoltan posted has included L3 support for GRE, here 
it is.

https://mail.openvswitch.org/pipermail/ovs-dev/2017-April/330490.html


-Original Message-
From: ovs-discuss-boun...@openvswitch.org 
[mailto:ovs-discuss-boun...@openvswitch.org] On Behalf Of Hexin Wang
Sent: Tuesday, April 25, 2017 2:42 AM
To: Ben Pfaff 
Cc: simon.hor...@netronome.com; ovs-discuss@openvswitch.org
Subject: Re: [ovs-discuss] OVS layer3 GRE support

Right. I was specifically referring to the OVS layer3 tunnel support originated 
by Lorand Jakab and Simon Horman.
The changes made in kernel data path is merged back to Linux mainline by Jiri 
Benc. But the user space OVS changes are missing in ovs main tree.

Thanks.

Hexin




On 4/24/17, 11:37 AM, "Ben Pfaff"  wrote:

>On Mon, Apr 24, 2017 at 06:25:07PM +, Hexin Wang wrote:
>> I got a question on OVS layer3 GRE tunnel support. The OVS kernel 
>> piece that supports layer 3 GRE is merged into linux upstream since
>> 4.10 RC6. Do we need any extra user land OVS merge for it to work 
>> end-to-end? I am referring to the “options:layer3=true” ovs-vsctl 
>> interface changes. Essentially, how is “push_mpls” action triggering 
>> the pop_eth action in kernel data path?
>
>This is not a subject I know well.  That said, it looks like OVS 
>userspace doesn't currently support layer-3 GRE tunnels in an 
>appropriate way.  I mainly base this on the code in 
>netdev_vport_is_layer3(), which considers only LISP ports to be layer-3 
>ports.
___
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] OVN knob to control floating IP NAT action

[Hexin Wang]

Hi Guru,

Thanks. You probably referred to the unit test "ovn -- DNAT and SNAT on 
distributed router - E/W" in tests/system-ovn.at? Is there anyway for me to 
configure route based dnat_and_snat from ovn-nbctl? Specifically can I qualify 
the following command with some prefix routes?

  ovn-nbctl lr-nat-add R1 dnat_and_snat

Or maybe there is another way to achieve the same functionality?

Regards,

Hexin

From: Guru Shetty
Date: Monday, April 24, 2017 at 12:44 PM
To: Hexin Wang
Cc: "ovs-discuss@openvswitch.org"
Subject: Re: [ovs-discuss] OVN knob to control floating IP NAT action



On 24 April 2017 at 11:39, Hexin Wang 
> wrote:
Hi Guru,

Let me try with the following use cases.
1. No floating IP is used for east-west routing traffic.
E.g. VM1 <-> VM2: Private IPs are used. No NAT applied.

2. Floating IP is used for south-north default route to internet traffic.
E.g. VM originated internet traffic: SNAT is applied to change source IP to 
floating IP. UNSNAT is applied to change destination IP back to private IP.

Yes. There are examples in tests/system-traffic.at


Thanks.

Hexin

From: Guru Shetty
Date: Monday, April 24, 2017 at 11:34 AM
To: Hexin Wang
Cc: "ovs-discuss@openvswitch.org"
Subject: Re: [ovs-discuss] OVN knob to control floating IP NAT action



On 24 April 2017 at 11:31, Hexin Wang 
> wrote:
Hi,

Is there any knob in OVN to control when floating IP will be applied in the 
distributed NAT? Specifically:

  1.  If the destination IP is part of some private layer3 domain, the usual 
private IP is used to to reach the destination in the private layer3 domain.
  2.  If the destination IP is not part of the private layer3 domain but part 
of the public layer3 domain, the public IP (I.e. Floating IP) is used to 
replace the private IP address of the source packet.

I don't understand what you mean above. Please re-phrase with the direction of 
the packet.

Does OVN support this behavior today?

Thanks.

Hexin

___
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] OVN knob to control floating IP NAT action

[Guru Shetty]

On 24 April 2017 at 11:39, Hexin Wang  wrote:

> Hi Guru,
>
> Let me try with the following use cases.
> 1. No floating IP is used for east-west routing traffic.
> E.g. VM1 <-> VM2: Private IPs are used. No NAT applied.
>
> 2. Floating IP is used for south-north default route to internet traffic.
> E.g. VM originated internet traffic: SNAT is applied to change source IP
> to floating IP. UNSNAT is applied to change destination IP back to private
> IP.
>
> Yes. There are examples in tests/system-traffic.at



> Thanks.
>
> Hexin
>
> From: Guru Shetty
> Date: Monday, April 24, 2017 at 11:34 AM
> To: Hexin Wang
> Cc: "ovs-discuss@openvswitch.org"
> Subject: Re: [ovs-discuss] OVN knob to control floating IP NAT action
>
>
>
> On 24 April 2017 at 11:31, Hexin Wang  wrote:
>
>> Hi,
>>
>> Is there any knob in OVN to control when floating IP will be applied in
>> the distributed NAT? Specifically:
>>
>>1. If the destination IP is part of some private layer3 domain, the
>>usual private IP is used to to reach the destination in the private layer3
>>domain.
>>2. If the destination IP is not part of the private layer3 domain but
>>part of the public layer3 domain, the public IP (I.e. Floating IP) is used
>>to replace the private IP address of the source packet.
>>
>> I don't understand what you mean above. Please re-phrase with the
> direction of the packet.
>
>
>> Does OVN support this behavior today?
>>
>> Thanks.
>>
>> Hexin
>>
>> ___
>> 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] OVS layer3 GRE support

[Ben Pfaff]

Oh, I see.

Lori or Simon, are you planning to send patches for master?

On Mon, Apr 24, 2017 at 06:42:07PM +, Hexin Wang wrote:
> Right. I was specifically referring to the OVS layer3 tunnel support 
> originated by Lorand Jakab and Simon Horman.
> The changes made in kernel data path is merged back to Linux mainline by Jiri 
> Benc. But the user space OVS changes are missing in ovs main tree.
> 
> Thanks.
> 
> Hexin
> 
> 
> 
> 
> On 4/24/17, 11:37 AM, "Ben Pfaff"  wrote:
> 
> >On Mon, Apr 24, 2017 at 06:25:07PM +, Hexin Wang wrote:
> >> I got a question on OVS layer3 GRE tunnel support. The OVS kernel
> >> piece that supports layer 3 GRE is merged into linux upstream since
> >> 4.10 RC6. Do we need any extra user land OVS merge for it to work
> >> end-to-end? I am referring to the “options:layer3=true” ovs-vsctl
> >> interface changes. Essentially, how is “push_mpls” action triggering
> >> the pop_eth action in kernel data path?
> >
> >This is not a subject I know well.  That said, it looks like OVS
> >userspace doesn't currently support layer-3 GRE tunnels in an
> >appropriate way.  I mainly base this on the code in
> >netdev_vport_is_layer3(), which considers only LISP ports to be layer-3
> >ports.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVS layer3 GRE support

[Hexin Wang]

Right. I was specifically referring to the OVS layer3 tunnel support originated 
by Lorand Jakab and Simon Horman.
The changes made in kernel data path is merged back to Linux mainline by Jiri 
Benc. But the user space OVS changes are missing in ovs main tree.

Thanks.

Hexin




On 4/24/17, 11:37 AM, "Ben Pfaff"  wrote:

>On Mon, Apr 24, 2017 at 06:25:07PM +, Hexin Wang wrote:
>> I got a question on OVS layer3 GRE tunnel support. The OVS kernel
>> piece that supports layer 3 GRE is merged into linux upstream since
>> 4.10 RC6. Do we need any extra user land OVS merge for it to work
>> end-to-end? I am referring to the “options:layer3=true” ovs-vsctl
>> interface changes. Essentially, how is “push_mpls” action triggering
>> the pop_eth action in kernel data path?
>
>This is not a subject I know well.  That said, it looks like OVS
>userspace doesn't currently support layer-3 GRE tunnels in an
>appropriate way.  I mainly base this on the code in
>netdev_vport_is_layer3(), which considers only LISP ports to be layer-3
>ports.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVN knob to control floating IP NAT action

[Hexin Wang]

Hi Guru,

Let me try with the following use cases.
1. No floating IP is used for east-west routing traffic.
E.g. VM1 <-> VM2: Private IPs are used. No NAT applied.

2. Floating IP is used for south-north default route to internet traffic.
E.g. VM originated internet traffic: SNAT is applied to change source IP to 
floating IP. UNSNAT is applied to change destination IP back to private IP.

Thanks.

Hexin

From: Guru Shetty
Date: Monday, April 24, 2017 at 11:34 AM
To: Hexin Wang
Cc: "ovs-discuss@openvswitch.org"
Subject: Re: [ovs-discuss] OVN knob to control floating IP NAT action



On 24 April 2017 at 11:31, Hexin Wang 
> wrote:
Hi,

Is there any knob in OVN to control when floating IP will be applied in the 
distributed NAT? Specifically:

  1.  If the destination IP is part of some private layer3 domain, the usual 
private IP is used to to reach the destination in the private layer3 domain.
  2.  If the destination IP is not part of the private layer3 domain but part 
of the public layer3 domain, the public IP (I.e. Floating IP) is used to 
replace the private IP address of the source packet.

I don't understand what you mean above. Please re-phrase with the direction of 
the packet.

Does OVN support this behavior today?

Thanks.

Hexin

___
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] OVS layer3 GRE support

[Ben Pfaff]

On Mon, Apr 24, 2017 at 06:25:07PM +, Hexin Wang wrote:
> I got a question on OVS layer3 GRE tunnel support. The OVS kernel
> piece that supports layer 3 GRE is merged into linux upstream since
> 4.10 RC6. Do we need any extra user land OVS merge for it to work
> end-to-end? I am referring to the “options:layer3=true” ovs-vsctl
> interface changes. Essentially, how is “push_mpls” action triggering
> the pop_eth action in kernel data path?

This is not a subject I know well.  That said, it looks like OVS
userspace doesn't currently support layer-3 GRE tunnels in an
appropriate way.  I mainly base this on the code in
netdev_vport_is_layer3(), which considers only LISP ports to be layer-3
ports.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVN knob to control floating IP NAT action

[Guru Shetty]

On 24 April 2017 at 11:31, Hexin Wang  wrote:

> Hi,
>
> Is there any knob in OVN to control when floating IP will be applied in
> the distributed NAT? Specifically:
>
>1. If the destination IP is part of some private layer3 domain, the
>usual private IP is used to to reach the destination in the private layer3
>domain.
>2. If the destination IP is not part of the private layer3 domain but
>part of the public layer3 domain, the public IP (I.e. Floating IP) is used
>to replace the private IP address of the source packet.
>
> I don't understand what you mean above. Please re-phrase with the
direction of the packet.


> Does OVN support this behavior today?
>
> Thanks.
>
> Hexin
>
> ___
> 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

[ovs-discuss] OVN knob to control floating IP NAT action

[Hexin Wang]

Hi,

Is there any knob in OVN to control when floating IP will be applied in the 
distributed NAT? Specifically:

  1.  If the destination IP is part of some private layer3 domain, the usual 
private IP is used to to reach the destination in the private layer3 domain.
  2.  If the destination IP is not part of the private layer3 domain but part 
of the public layer3 domain, the public IP (I.e. Floating IP) is used to 
replace the private IP address of the source packet.

Does OVN support this behavior today?

Thanks.

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

[ovs-discuss] OVS layer3 GRE support

[Hexin Wang]

Hi Ben,

I got a question on OVS layer3 GRE tunnel support. The OVS kernel piece that 
supports layer 3 GRE is merged into linux upstream since 4.10 RC6. Do we need 
any extra user land OVS merge for it to work end-to-end? I am referring to the 
“options:layer3=true” ovs-vsctl interface changes. Essentially, how is 
“push_mpls” action triggering the pop_eth action in kernel data path?

Thanks.

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

Re: [ovs-discuss] 答复: about

[Ben Pfaff]

OK, let's figure out the problem.  Can you provide a backtrace?  Or run
OVS until valgrind and provide valgrind's report?  Or can you provide
reproduction information for us?

Thanks,

Ben.

On Thu, Apr 20, 2017 at 08:21:54AM +, qintao (F) wrote:
> hi,Pettit
>   I have reprodeuced the same issue with 2.5.2, but the result is still 
> disappointing ,which is the crash of the process "ovs-vswitchd".
> 
> best regards,
>  Tony tao
> -邮件原件-
> 发件人: Justin Pettit [mailto:jpet...@ovn.org] 
> 发送时间: 2017年4月20日 5:05
> 收件人: qintao (F)
> 抄送: ovs-discuss@openvswitch.org; wuhao (S); Liuguifeng; Lukai (Look); 
> Guoyilong
> 主题: Re: [ovs-discuss] about  "ovs-vswitchd"with the userspace ovs 2.5.0>
> 
> 
> > On Apr 18, 2017, at 6:59 PM, qintao (F)  wrote:
> > 
> >  
> >  
> > Dear all ,
> >  we create a bridge “br1” with the type of netdev .And the version of 
> > the ovs is 2.5.0. Then we run the command “ovs-vsctl set int br1 
> > lldp:enable=true “ to make the interface br1 enable the function lldp.After 
> > that ,we delete the bridge br1 ,we found the the process “ovs-vswitchd” has 
> > been lost.
> > ”
> 
> Thanks for the report.  There are a couple of releases in the 2.5.x series 
> since 2.5.0.  Are you able to reproduce the same issue with 2.5.2?
> 
> --Justin
> 
> 
> ___
> 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] Question on in_port reference in xlate_normal@ofproto-dpif-xlate.c

[Ben Pfaff]

On Mon, Apr 24, 2017 at 04:30:51PM +, Hexin Wang wrote:
> In ovs 2.6.90, we are seeing NULL reference to in_port if 
> lookup_input_bundle() sets in_port to NULL.
> 
> /* Learn source MAC. */
> if (ctx->xin->may_learn && !in_port->is_layer3) {
> update_learning_table(ctx->xbridge, flow, wc, vlan, in_xbundle);
> }
> 
> This happens when a flow being processed in xlate_normal is OFPP_NONE.
> (gdb) print ctx->xin->flow.in_port
> 
> $5 = {odp_port = 65535, ofp_port = 65535}
> 
> We don’t see this issue on 2.5.0. Is ofp_port 65535 expected in 
> xlate_normal()?

As far as I can tell, the code you cite never existed in the Open
vSwitch repository: only a single commit against master ever added the
string "is_layer3" to the code base, and not in the same file as any
reference to update_learning_table().  I guess that you are using some
fork of OVS that added it.  In that case, probably you need to ask
whoever supplied the fork.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] Question on in_port reference in xlate_normal@ofproto-dpif-xlate.c

[Hexin Wang]

Hi,

In ovs 2.6.90, we are seeing NULL reference to in_port if lookup_input_bundle() 
sets in_port to NULL.

/* Learn source MAC. */
if (ctx->xin->may_learn && !in_port->is_layer3) {
update_learning_table(ctx->xbridge, flow, wc, vlan, in_xbundle);
}

This happens when a flow being processed in xlate_normal is OFPP_NONE.
(gdb) print ctx->xin->flow.in_port

$5 = {odp_port = 65535, ofp_port = 65535}

We don’t see this issue on 2.5.0. Is ofp_port 65535 expected in xlate_normal()?

Thanks.

Hexin


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

Re: [ovs-discuss] Regarding openvswitch group, type=select, hashing

[Ben Pfaff]

No, select buckets don't use mod-n to select a bucket.  Instead, for
each live bucket, OVS hashes flow data with the bucket ID and multiplies
by the bucket weight to obtain a "score", and then selects the bucket
with the highest score.

On Mon, Apr 24, 2017 at 12:27:16AM +0530, Ahmed Khan wrote:
> Hi ben,
> Let me rephrase.
> 
> Does hashing involve mod on number of buckets in a group ? If a new bucket
> is added/deleted in a group, would it result in different hash value and
> hence a selection of different bucket for the same 5 tuple ?
> 
> Also, how many buckets per group does ovs support ? And how many group
> tables are supported ?
> 
> Thanks.
> 
> On 22 Apr 2017 02:34, "Ben Pfaff"  wrote:
> 
> > On Thu, Apr 20, 2017 at 04:12:20PM +0530, Ahmed Khan wrote:
> > > I understand that,
> > >
> > > *"""*
> > >
> > > *Open vSwitch 2.4 and later by default hashes the source and
> > > **destination Ethernet address, VLAN ID, Ethernet type, IPv4/v6
> > > **source and destination address and protocol, and for TCP and SCTP
> > > **only, the source and destination ports.  The hash is "symmetric",
> > > **meaning that exchanging source and destination addresses does not
> > > **change the bucket selection.*
> > >
> > > *"""*
> > >
> > > *How does bucket size impact selection ? If entries are added/deleted
> > > to/from bucket, then for the same 5tuple is it rehashed and new entry
> > > could get selected ?*
> >
> > OpenFlow groups do contain buckets, but buckets do not have entries.
> > Therefore, entries cannot be added or deleted within buckets, so I don't
> > understand the question.  Can you rephrase it?
> >
> > Thanks,
> >
> > Ben.
> >
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] Wrong ovsdb update after "switch s1 stop/start" and role request message.

[Tulio Ribeiro]

Hi : )

I'm facing an weird behavior regarding on role change.
When I send a role message to change the role of one specific switch, 
all switches change to this role.


I think the problem is when open vSwitch mount the transaction message 
to send to ovsdb.


A simple test is, start a mininet network with 4 switches, linear topo.
stop s1, and start it again.

Look Controller table, before and after stop and start switch s1.

Before Stop:
sudo ovsdb-client dump tcp:192.168.1.200:5000 Controller
Controller table
2ab2e756-cc3a-47d6-9421-1b69ae035be0 [] [] 
[][] {}   []   true 
[][] []1000{}   master 
{*sec_since_connect="40"*, state=ACTIVE} "tcp:192.168.1.215:6653"
333dc741-daa2-472c-9c9d-8337dead0318 [] [] 
[][] {}   []   true 
[][] []1000{}   master 
{*sec_since_connect="40"*, state=ACTIVE} "tcp:192.168.1.215:6653"
bcb46630-8509-485e-a7c0-c5df7cfa8141 [] [] 
[][] {}   []   true 
[][] []1000{}   master 
{*sec_since_connect="40",* state=ACTIVE} "tcp:192.168.1.215:6653"
dc0e199a-cd0c-4077-93b8-3b5d265f4b25 [] [] 
[][] {}   []   true 
[][] []1000{}   master 
{*sec_since_connect="40"*, state=ACTIVE} "tcp:192.168.1.215:6653"



After stop and start switch S1:
2ab2e756-cc3a-47d6-9421-1b69ae035be0 [] [] 
[][] {}   []   true 
[][] []1000{}   master 
{*sec_since_connect="200"*, state=ACTIVE} "tcp:192.168.1.215:6653"
333dc741-daa2-472c-9c9d-8337dead0318 [] [] 
[][] {}   []   true 
[][] []1000{}   master 
{*sec_since_connect="200"*, state=ACTIVE} "tcp:192.168.1.215:6653"
bcb46630-8509-485e-a7c0-c5df7cfa8141 [] [] 
[][] {}   []   true 
[][] []1000{}   master 
{*sec_since_connect="200"*, state=ACTIVE} "tcp:192.168.1.215:6653"
dc0e199a-cd0c-4077-93b8-3b5d265f4b25 [] [] 
[][] {}   []   true 
[][] []1000{}   master 
{*sec_since_connect="200"*, state=ACTIVE} "tcp:192.168.1.215:6653"



The sec_since_connection of S1 should differs from the others, right?
As you can see they are all the same.



Here I'll show when I use different roles. S1:master, S2:slave, 
S3:master and S4 slave.


2017-04-25T05:59:50.947Z|44091|vconn|DBG|tcp:192.168.1.215:6653: 
received: OFPT_ROLE_REQUEST (OF1.4) (xid=0x26):*role=master* generation_id=0
2017-04-25T05:59:50.953Z|44092|vconn|DBG|tcp:192.168.1.215:6653: sent 
(Success): OFPT_ROLE_REPLY (OF1.4) (xid=0x26): role=master generation_id=0
2017-04-25T05:59:50.953Z|44093|vconn|DBG|tcp:192.168.1.215:6653: 
received: OFPT_ROLE_REQUEST (OF1.4) (xid=0x24): *role=slave* generation_id=0
2017-04-25T05:59:50.954Z|44094|vconn|DBG|tcp:192.168.1.215:6653: sent 
(Success): OFPT_ROLE_REPLY (OF1.4) (xid=0x24): role=slave generation_id=0
2017-04-25T05:59:50.954Z|44097|vconn|DBG|tcp:192.168.1.215:6653: 
received: OFPT_ROLE_REQUEST (OF1.4) (xid=0x22): *role=master* 
generation_id=0
2017-04-25T05:59:50.955Z|44098|vconn|DBG|tcp:192.168.1.215:6653: sent 
(Success): OFPT_ROLE_REPLY (OF1.4) (xid=0x22): role=master generation_id=0
2017-04-25T05:59:50.955Z|44099|vconn|DBG|tcp:192.168.1.215:6653: 
received: OFPT_ROLE_REQUEST (OF1.4) (xid=0x28):*role=slave *generation_id=0
2017-04-25T05:59:50.955Z|44100|vconn|DBG|tcp:192.168.1.215:6653: sent 
(Success): OFPT_ROLE_REPLY (OF1.4) (xid=0x28): role=slave generation_id=0


2017-04-25T05:59:53.906Z|44179|jsonrpc|DBG|tcp:192.168.1.200:5000: send 
request, method="transact", 
params=["Open_vSwitch",{"lock":"ovs_vswitchd","op":"assert"},{"where":[["_uuid","==",["uuid","bcb46630-8509-485e-a7c0-c5df7cfa8141"]]],"row":{"is_connected":true,"status":["map",[["last_error","Connection 
refused"],["sec_since_connect","3"],["sec_since_disconnect","4"],["state","ACTIVE"]]]*,"role":"master"*},"op":"update","table":"Controller"},{"where":[["_uuid","==",["uuid","333dc741-daa2-472c-9c9d-8337dead0318"]]],"row":{"is_connected":true,"status":["map",[["last_error","Connection 

Re: [ovs-discuss] prioritizing latency-sensitive traffic

[Ben Pfaff]

If that's useful, then it makes sense to me and I'd have no objection.

On Mon, Apr 24, 2017 at 10:06:17AM +, O Mahony, Billy wrote:
> Hi Ben, Darrell,
> 
> I've done some PoC work on this kind of traffic prioritization. However with 
> OVS-DPDK's run-to-completion model the issue I find the same issue as you 
> outlined - by the time the priority of the packet has been determined most of 
> the effort to process the packet has already been spent. 
> 
> So, I relied on using hardware offload i.e. FlowDirector on the NIC to 
> analyse and allocate  packets to high and low priority queues and then 
> modifying the PMD (dpif_netdev_run ) to read preferentially from the high 
> priority queue. The results were  good for overload situations - packets on 
> the priority queue not dropped. In terms of latency there was an improvement 
> but there was still a long tail to the latency profile. i..e The latency 
> profile moved down but not left.
> 
> As Darrell pointed out for egress scheduling, perhaps this kind of ingress 
> prioritization can be encapsulated as an optional property of a port? 
> 
> If the port can implement the prioritization (either by offloading to 
> hardware or in software) it can accept the property being set; If not it can 
> return ENOTSUPP?
> 
> There is currently HWOL use-cases being gathered for OVS-DPDK:  
> https://docs.google.com/document/d/1A8adu1xzg53bzcFKINhffYyC0nCQjqwqnI1jAFx2sck/edit?usp=sharing
>  + Kevin who is co-ordinating that.
> 
> Thanks,
> Billy.
> 
> 
> > -Original Message-
> > From: Ben Pfaff [mailto:b...@ovn.org]
> > Sent: Friday, April 21, 2017 10:39 PM
> > To: O Mahony, Billy 
> > Cc: ovs-discuss@openvswitch.org; Darrell Ball 
> > Subject: Re: [ovs-discuss] prioritizing latency-sensitive traffic
> > 
> > Thanks for letting us know.  I'm happy to continue the conversation if there
> > are interesting ideas; it's a frustrating situation, frankly, and I'd love 
> > to hear
> > creative approaches.
> > 
> > On Tue, Apr 18, 2017 at 10:01:28AM +, O Mahony, Billy wrote:
> > > Hi Ben, Darrell,
> > >
> > > It sounds like the general feeling is that any kind of tc pre-processing 
> > > is not
> > worth it and the existing egress queing/QoS facilities should suffice.
> > >
> > > Thanks for your comments.
> > >
> > > /Billy
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Ben Pfaff [mailto:b...@ovn.org]
> > > > Sent: Thursday, April 13, 2017 7:47 PM
> > > > To: O Mahony, Billy 
> > > > Cc: ovs-discuss@openvswitch.org
> > > > Subject: Re: [ovs-discuss] prioritizing latency-sensitive traffic
> > > >
> > > > I don't know how much more OVS can contribute to this than it already
> > does.
> > > > By the time that OVS has classified a packet to the extent that is
> > > > necessary to determine that it should be handled with a high
> > > > priority, OVS has already done most of the work that it does on a 
> > > > packet.
> > > [[BO'M]] I'm investigating how I could go about classifying packets
> > > before the main The work to transmit the
> > > > packet is not part of OVS's job, it is the job of the driver, and at
> > > > most OVS can mark the packet with a priority or a queue.  OVS can
> > > > already do that.  So the usual answer is that it's a matter of
> > > > configuring QoS in the driver to do what the user wants.
> > > >
> > > > On Mon, Apr 10, 2017 at 09:30:12AM +, O Mahony, Billy wrote:
> > > > > Hi Everybody,
> > > > >
> > > > > I just wanted to reflag this discussion below about possible
> > > > > methods of
> > > > how to prioritize certain types of traffic handled by OVS.
> > > > >
> > > > > By prioritize I mean either or both of:
> > > > > a) 'priority' packets are sent to their destination port faster
> > > > > than other packets
> > > > > b) in an overloaded situation the switch drops non-prioritized
> > > > > packets
> > > > rather than prioritized packets.
> > > > >
> > > > > Also just to be clear I am discussing kernel ovs here. Also I'm
> > > > > looking at
> > > > doing this without writing new code - ie is it possible and if so
> > > > how is it configured using existing OVS.
> > > > >
> > > > > Thanks again,
> > > > > Billy.
> > > > >
> > > > > > -Original Message-
> > > > > > From: ovs-discuss-boun...@openvswitch.org [mailto:ovs-discuss-
> > > > > > boun...@openvswitch.org] On Behalf Of O Mahony, Billy
> > > > > > Sent: Friday, November 25, 2016 5:04 PM
> > > > > > To: ovs-discuss@openvswitch.org
> > > > > > Subject: [ovs-discuss] prioritizing latency-sensitive traffic
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I have been performing tests investigating latency profiles of
> > > > > > low-bandwidth time-sensitive traffic when the system is busy
> > > > > > with
> > > > 'normal' traffic.
> > > > > > Unsurprisingly the latency-sensitive traffic is affected by the
> > > > > > normal traffic and has basically the same latency profile as 

Re: [ovs-discuss] prioritizing latency-sensitive traffic

[O Mahony, Billy]

Hi Ben, Darrell,

I've done some PoC work on this kind of traffic prioritization. However with 
OVS-DPDK's run-to-completion model the issue I find the same issue as you 
outlined - by the time the priority of the packet has been determined most of 
the effort to process the packet has already been spent. 

So, I relied on using hardware offload i.e. FlowDirector on the NIC to analyse 
and allocate  packets to high and low priority queues and then modifying the 
PMD (dpif_netdev_run ) to read preferentially from the high priority queue. The 
results were  good for overload situations - packets on the priority queue not 
dropped. In terms of latency there was an improvement but there was still a 
long tail to the latency profile. i..e The latency profile moved down but not 
left.

As Darrell pointed out for egress scheduling, perhaps this kind of ingress 
prioritization can be encapsulated as an optional property of a port? 

If the port can implement the prioritization (either by offloading to hardware 
or in software) it can accept the property being set; If not it can return 
ENOTSUPP?

There is currently HWOL use-cases being gathered for OVS-DPDK:  
https://docs.google.com/document/d/1A8adu1xzg53bzcFKINhffYyC0nCQjqwqnI1jAFx2sck/edit?usp=sharing
 + Kevin who is co-ordinating that.

Thanks,
Billy.


> -Original Message-
> From: Ben Pfaff [mailto:b...@ovn.org]
> Sent: Friday, April 21, 2017 10:39 PM
> To: O Mahony, Billy 
> Cc: ovs-discuss@openvswitch.org; Darrell Ball 
> Subject: Re: [ovs-discuss] prioritizing latency-sensitive traffic
> 
> Thanks for letting us know.  I'm happy to continue the conversation if there
> are interesting ideas; it's a frustrating situation, frankly, and I'd love to 
> hear
> creative approaches.
> 
> On Tue, Apr 18, 2017 at 10:01:28AM +, O Mahony, Billy wrote:
> > Hi Ben, Darrell,
> >
> > It sounds like the general feeling is that any kind of tc pre-processing is 
> > not
> worth it and the existing egress queing/QoS facilities should suffice.
> >
> > Thanks for your comments.
> >
> > /Billy
> >
> >
> >
> > > -Original Message-
> > > From: Ben Pfaff [mailto:b...@ovn.org]
> > > Sent: Thursday, April 13, 2017 7:47 PM
> > > To: O Mahony, Billy 
> > > Cc: ovs-discuss@openvswitch.org
> > > Subject: Re: [ovs-discuss] prioritizing latency-sensitive traffic
> > >
> > > I don't know how much more OVS can contribute to this than it already
> does.
> > > By the time that OVS has classified a packet to the extent that is
> > > necessary to determine that it should be handled with a high
> > > priority, OVS has already done most of the work that it does on a packet.
> > [[BO'M]] I'm investigating how I could go about classifying packets
> > before the main The work to transmit the
> > > packet is not part of OVS's job, it is the job of the driver, and at
> > > most OVS can mark the packet with a priority or a queue.  OVS can
> > > already do that.  So the usual answer is that it's a matter of
> > > configuring QoS in the driver to do what the user wants.
> > >
> > > On Mon, Apr 10, 2017 at 09:30:12AM +, O Mahony, Billy wrote:
> > > > Hi Everybody,
> > > >
> > > > I just wanted to reflag this discussion below about possible
> > > > methods of
> > > how to prioritize certain types of traffic handled by OVS.
> > > >
> > > > By prioritize I mean either or both of:
> > > > a) 'priority' packets are sent to their destination port faster
> > > > than other packets
> > > > b) in an overloaded situation the switch drops non-prioritized
> > > > packets
> > > rather than prioritized packets.
> > > >
> > > > Also just to be clear I am discussing kernel ovs here. Also I'm
> > > > looking at
> > > doing this without writing new code - ie is it possible and if so
> > > how is it configured using existing OVS.
> > > >
> > > > Thanks again,
> > > > Billy.
> > > >
> > > > > -Original Message-
> > > > > From: ovs-discuss-boun...@openvswitch.org [mailto:ovs-discuss-
> > > > > boun...@openvswitch.org] On Behalf Of O Mahony, Billy
> > > > > Sent: Friday, November 25, 2016 5:04 PM
> > > > > To: ovs-discuss@openvswitch.org
> > > > > Subject: [ovs-discuss] prioritizing latency-sensitive traffic
> > > > >
> > > > > Hi,
> > > > >
> > > > > I have been performing tests investigating latency profiles of
> > > > > low-bandwidth time-sensitive traffic when the system is busy
> > > > > with
> > > 'normal' traffic.
> > > > > Unsurprisingly the latency-sensitive traffic is affected by the
> > > > > normal traffic and has basically the same latency profile as the
> > > > > normal
> > > traffic.
> > > > >
> > > > > I would like to be able to perform prioritization of traffic as
> > > > > some protocols such as PTP would benefit greatly from having
> > > > > it's packets 'jump
> > > the queue'.
> > > > >
> > > > > From skimming the documentation it looks that ingress QoS offers
> > > > > only policing (rate-limiting). Is 

[ovs-discuss] Are there some difference in flow table between normal ovs and dpdk ovs?

[Heung Sik Choi]

Hello

I have some question about ovs' flow table implementation after visiting
this url

https://software.intel.com/en-us/articles/ovs-dpdk-datapath-classifier-part-2

Are there some difference in flow table implementation between original ovs
and dpdk ovs?

Also, are there any differences in hash functions between them in terms of
algorithm or performance?

Thank you for reading this mail.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] ovs-dpdk bond mode

[Chandran, Sugesh]

Regards
_Sugesh

From: ovs-discuss-boun...@openvswitch.org 
[mailto:ovs-discuss-boun...@openvswitch.org] On Behalf Of Vishal Deep Ajmera
Sent: Monday, April 24, 2017 8:01 AM
To: ovs-discuss@openvswitch.org
Subject: [ovs-discuss] ovs-dpdk bond mode

Are we using DPDK Bond-PMD library for OVS bonding feature ? Or is it 
completely implemented in OVS itself ?
[Sugesh] Yes, it is implemented in OVS.

Regards,
Vishal

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