Re: [ovs-dev] [PATCH v3] ovn-sb.ovsschema: Avoid duplicated IPs in Encap table.

[Han Zhou]

On Thu, Nov 15, 2018 at 11:31 AM Ben Pfaff  wrote:
>
> On Thu, Nov 15, 2018 at 11:07:11AM -0800, Han Zhou wrote:
> > From: Han Zhou 
> >
> > When adding a new chassis, if there is an old chassis with same IP
> > existed in Encap table, it is allowed to be added today. However,
> > allowing it to be added results in problems:
> >
> > 1. The new chassis cannot work because none of the other chassises
> >are able to create tunnel to it, because of the IP confliction
> >with already existed tunnel to the old chassis.
> >
> > 2. All the other chassises will continuously retry creating the tunnel
> >and complaining about the error.
> >
> > So, instead of hiding the problem, it is better to expose it while
> > trying to add the second chassis with duplicated IP. This patch
> > ensures it from the ovsdb schema.
> >
> > Signed-off-by: Han Zhou 
> > ---
> > v2 -> v3: update NEWS for the potential DB upgrading failure
>
> Thanks a lot for adding some upgrade information.
>
> It's probably better to put detailed information like this for OVN
> upgrades in Documentation/intro/install/ovn-upgrades.rst.  Then NEWS
> could point to that advice.
>
> Thanks,
>
> Ben.

Makes sense! Please check v4:
https://mail.openvswitch.org/pipermail/ovs-dev/2018-November/353981.html
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] OVN multicast enhancements

[Mark Michelson]

Hi everyone,

In today's IRC meeting I brought up the fact I was enhancing multicast 
support in OVN, and I was asked to expand on this a bit. So here are 
details about what all I am working on.


Right now, OVN logical switches treat all multicast destinations as if 
they were broadcast. That is, the packet gets sent to all ports on the 
switch. OVN logical routers block all traffic destined to a multicast 
address.


My goal is for there to be more intelligence. IP traffic sent to 
multicast addresses should be sent to members of that multicast group 
when possible.


My work consists of the following phases:

Phase 1: Northbound changes; multicast on a single logical switch port.

For this part, we create a new northbound table called Multicast_Group. 
It consists of:

* A name
* A multicast IP address
* A list of logical switch ports
The general idea is that traffic sent to the IP address should reach all 
logical switch ports listed.


In practice, each northbound multicast group will result in southbound 
multicast groups being added to the datapaths that the logical switch 
ports reside on. Logical flows are introduced on the logical switch 
ingress pipelines to output packets that are destined for the multicast 
IP address and the corresponding derived multicast ethernet address [1] 
to the constituent ports.


In practice, this set of changes only works if all ports in the 
multicast group are on the same logical switch.


I already have this implemented and have a test written for the 
testsuite that passes. You can see what I have at 
https://github.com/putnopvut/ovs/tree/multicast-improvements


Phase 2: Add multicast routing support

This expands on the work in phase 1 by creating southbound multicast 
groups on logical router datapaths for router ports connected to logical 
switches with multicast groups on them. This way, a multicast group 
distributed across multiple logical switches can have the traffic routed 
as desired.


This also requires adding new logical flows for the router pipeline to 
ensure that traffic bound to known multicast IPs is sent where we expect.


I'm currently working on this phase. I have a test written and it is not 
passing.


Phase 3: Expand to IPv6 support.

The previous phases are very IPv4-centric. This phase expands on what we 
have already by making it work with IPv6 as well. Mostly, this means 
removing IPv4-centric idioms and installing IPv6 flows in parallel with 
the IPv4 flows.



With those three phases complete, I think I'll have a decent patchset to 
submit for approval. There are other enhancements that can be 
implemented as well later on:


* IGMP/MLD snooping in ovn-controller.
* Installation of rules for well-known multicast addresses with semantic 
significance.


That's all for that. If you have questions/concerns, please let me know.

Mark!

[1] I initially had wanted to only use the multicast ethernet address 
for determining where to send the packets. However, the way that 
multicast IP translates into multicast ethernet addresses, there can be 
ambiguity. Therefore the logical switch needs to also examine the 
multicast IP address.

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] ovn-sb.ovsschema: Avoid duplicated IPs in Encap table.

[0-day Robot]

Bleep bloop.  Greetings Han Zhou, I am a robot and I have tried out your patch.
Thanks for your contribution.

I encountered some error that I wasn't expecting.  See the details below.


checkpatch:
WARNING: Line is 82 characters long (recommended limit is 79)
#38 FILE: NEWS:13:
   user can delete the entries using command "ovn-sbctl chassis-del 
"

Lines checked: 70, Warnings: 1, Errors: 0


Please check this out.  If you feel there has been an error, please email 
acon...@bytheb.org

Thanks,
0-day Robot
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] (no subject)

[Spende via dev]

$500,000 wurden Ihnen von Ann-Marie Francis und Ian Warcup gespendet. Antwort 
für weitere Informationen: annwithian.foundationh...@gmail.com $500,000 has 
been donated to you by Ann-Marie Francis and Ian Warcup. reply for more info: 
annwithian.foundationh...@gmail.com Thanks
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v3] ovn-sb.ovsschema: Avoid duplicated IPs in Encap table.

[Ben Pfaff]

On Thu, Nov 15, 2018 at 11:07:11AM -0800, Han Zhou wrote:
> From: Han Zhou 
> 
> When adding a new chassis, if there is an old chassis with same IP
> existed in Encap table, it is allowed to be added today. However,
> allowing it to be added results in problems:
> 
> 1. The new chassis cannot work because none of the other chassises
>are able to create tunnel to it, because of the IP confliction
>with already existed tunnel to the old chassis.
> 
> 2. All the other chassises will continuously retry creating the tunnel
>and complaining about the error.
> 
> So, instead of hiding the problem, it is better to expose it while
> trying to add the second chassis with duplicated IP. This patch
> ensures it from the ovsdb schema.
> 
> Signed-off-by: Han Zhou 
> ---
> v2 -> v3: update NEWS for the potential DB upgrading failure

Thanks a lot for adding some upgrade information.

It's probably better to put detailed information like this for OVN
upgrades in Documentation/intro/install/ovn-upgrades.rst.  Then NEWS
could point to that advice.

Thanks,

Ben.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v2] ovn-sb.ovsschema: Avoid duplicated IPs in Encap table.

[Han Zhou]

On Thu, Nov 15, 2018 at 9:24 AM Ben Pfaff  wrote:
>
> On Tue, Nov 13, 2018 at 11:25:59AM -0800, Han Zhou wrote:
> > From: Han Zhou 
> >
> > When adding a new chassis, if there is an old chassis with same IP
> > existed in Encap table, it is allowed to be added today. However,
> > allowing it to be added results in problems:
> >
> > 1. The new chassis cannot work because none of the other chassises
> >are able to create tunnel to it, because of the IP confliction
> >with already existed tunnel to the old chassis.
> >
> > 2. All the other chassises will continuously retry creating the tunnel
> >and complaining about the error.
> >
> > So, instead of hiding the problem, it is better to expose it while
> > trying to add the second chassis with duplicated IP. This patch
> > ensures it from the ovsdb schema.
> >
> > Signed-off-by: Han Zhou 
>
> I'm worried that this will make it hard for users to upgrade: if they
> have any duplicate chassis, then they will have to manually delete them
> before ovsdb-server will accept the new database.
>
> I think you mentioned that ovn-controller can't delete the duplicates
> because of RBAC permissions.  What if ovn-northd deletes them instead?
> If it doesn't have a way to know which one is the "correct" one, it
> could just delete all of the duplicates, since the ovn-controller that
> is actually running will re-create its chassis if it disappears.

Hi Ben, as discussed in today's meeting, I sent v3 with NEWS updated.
https://mail.openvswitch.org/pipermail/ovs-dev/2018-November/353973.html
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] datapath-windows: Fix invalid reference in Buffermgmt.c

[Sairam Venugopal]

Thanks!

On 11/15/18, 10:45 AM, "Ben Pfaff"  wrote:

Alin already did that.

On Thu, Nov 15, 2018 at 06:40:00PM +, Sairam Venugopal wrote:
> Is it too late to backport this to 2.10?
> 
> On 11/15/18, 7:03 AM, "Alin Serdean"  
wrote:
> 
> I applied the patch on master and as far as it goes without conflicts.
> 
> --
> Alin.
> 
> > -Mesaj original-
> > De la: ovs-dev-boun...@openvswitch.org  > boun...@openvswitch.org> În numele aserd...@ovn.org
> > Trimis: Thursday, November 15, 2018 4:52 PM
> > Către: 'Sairam Venugopal' ; d...@openvswitch.org
> > Subiect: Re: [ovs-dev] [PATCH] datapath-windows: Fix invalid 
reference in
> > Buffermgmt.c
> > 
> > Thanks for the fix!
> > 
> > Acked-by: Alin Gabriel Serdean 
> > 
> > > -Mesaj original-
> > > De la: ovs-dev-boun...@openvswitch.org  > > boun...@openvswitch.org> În numele Sairam Venugopal
> > > Trimis: Wednesday, November 14, 2018 10:07 PM
> > > Către: d...@openvswitch.org
> > > Subiect: [ovs-dev] [PATCH] datapath-windows: Fix invalid 
reference in
> > > Buffermgmt.c
> > >
> > > OVS_BUFFER_CONTEXT gets cleared as part of
> > > NdisFreeNetBufferListContext function call. This causes an invalid
> > reference
> > > error.
> > >
> > > Found while testing with driver verifier enabled.
> > >
> > > Signed-off-by: Sairam Venugopal 
> > > ---
> > >  datapath-windows/ovsext/BufferMgmt.c | 6 --
> > >  1 file changed, 4 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/datapath-windows/ovsext/BufferMgmt.c b/datapath-
> > > windows/ovsext/BufferMgmt.c index 448cd76..da5c04a 100644
> > > --- a/datapath-windows/ovsext/BufferMgmt.c
> > > +++ b/datapath-windows/ovsext/BufferMgmt.c
> > 
> > ___
> > dev mailing list
> > d...@openvswitch.org
> > 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openvswitch.org%2Fmailman%2Flistinfo%2Fovs-devdata=02%7C01%7Cvsairam%40vmware.com%7C0354cc7dee7d477cb53108d64b2a7f97%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636779043242021462sdata=mvAm5BLoz21%2FNhURhoFdj%2FwZY4VcDHzfQx6UMxOh99c%3Dreserved=0
> 
> 
> ___
> dev mailing list
> d...@openvswitch.org
> 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openvswitch.org%2Fmailman%2Flistinfo%2Fovs-devdata=02%7C01%7Cvsairam%40vmware.com%7C0354cc7dee7d477cb53108d64b2a7f97%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636779043242021462sdata=mvAm5BLoz21%2FNhURhoFdj%2FwZY4VcDHzfQx6UMxOh99c%3Dreserved=0


___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [v3 dpdk-latest 3/3] travis: Update to use DPDK 18.11-rc3.

[Kevin Traynor]

Signed-off-by: Kevin Traynor 
---
 .travis/linux-build.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.travis/linux-build.sh b/.travis/linux-build.sh
index 4c9e95201..a402b1a85 100755
--- a/.travis/linux-build.sh
+++ b/.travis/linux-build.sh
@@ -84,5 +84,5 @@ fi
 if [ "$DPDK" ]; then
 if [ -z "$DPDK_VER" ]; then
-DPDK_VER="18.08"
+DPDK_VER="18.11-rc3"
 fi
 install_dpdk $DPDK_VER
-- 
2.19.0

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [v3 dpdk-latest 2/3] netdev-dpdk: Replace rte_eth_dev_attach/detach.

[Kevin Traynor]

rte_eth_dev_attach/detach have been removed from
DPDK 18.11. Replace them with rte_dev_probe/remove.

Signed-off-by: Kevin Traynor 
---
 lib/netdev-dpdk.c | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
index c586144f5..af310b06b 100644
--- a/lib/netdev-dpdk.c
+++ b/lib/netdev-dpdk.c
@@ -1352,5 +1352,5 @@ netdev_dpdk_destruct(struct netdev *netdev)
 {
 struct netdev_dpdk *dev = netdev_dpdk_cast(netdev);
-char devname[RTE_ETH_NAME_MAX_LEN];
+struct rte_eth_dev_info dev_info;
 
 ovs_mutex_lock(_mutex);
@@ -1361,8 +1361,9 @@ netdev_dpdk_destruct(struct netdev *netdev)
 if (dev->attached) {
 rte_eth_dev_close(dev->port_id);
-if (rte_eth_dev_detach(dev->port_id, devname) < 0) {
+rte_eth_dev_info_get(dev->port_id, _info);
+if (dev_info.device && !rte_dev_remove(dev_info.device)) {
+VLOG_INFO("Device '%s' has been detached", dev->devargs);
+} else {
 VLOG_ERR("Device '%s' can not be detached", dev->devargs);
-} else {
-VLOG_INFO("Device '%s' has been detached", devname);
 }
 }
@@ -1654,5 +1655,6 @@ netdev_dpdk_process_devargs(struct netdev_dpdk *dev,
 || !rte_eth_dev_is_valid_port(new_port_id)) {
 /* Device not found in DPDK, attempt to attach it */
-if (!rte_eth_dev_attach(devargs, _port_id)) {
+if (!rte_dev_probe(devargs)
+&& !rte_eth_dev_get_port_by_name(name, _port_id)) {
 /* Attach successful */
 dev->attached = true;
@@ -3210,9 +3212,8 @@ netdev_dpdk_detach(struct unixctl_conn *conn, int argc 
OVS_UNUSED,
const char *argv[], void *aux OVS_UNUSED)
 {
-int ret;
 char *response;
 dpdk_port_t port_id;
-char devname[RTE_ETH_NAME_MAX_LEN];
 struct netdev_dpdk *dev;
+struct rte_eth_dev_info dev_info;
 
 ovs_mutex_lock(_mutex);
@@ -3233,6 +3234,6 @@ netdev_dpdk_detach(struct unixctl_conn *conn, int argc 
OVS_UNUSED,
 rte_eth_dev_close(port_id);
 
-ret = rte_eth_dev_detach(port_id, devname);
-if (ret < 0) {
+rte_eth_dev_info_get(port_id, _info);
+if (!dev_info.device || rte_dev_remove(dev_info.device)) {
 response = xasprintf("Device '%s' can not be detached", argv[1]);
 goto error;
-- 
2.19.0

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] Windows: Fix broken kernel userspace communication

[Alin Serdean]

Yup in a couple of hours.

Sent from phone 

> On 15 Nov 2018, at 20:27, 0-day Robot  wrote:
> 
> Bleep bloop.  Greetings Alin Gabriel Serdean, I am a robot and I have tried 
> out your patch.
> Thanks for your contribution.
> 
> I encountered some error that I wasn't expecting.  See the details below.
> 
> 
> git-am:
> Failed to merge in the changes.
> Patch failed at 0001 Windows: Fix broken kernel userspace communication
> The copy of the patch that failed is found in:
>   
> /var/lib/jenkins/jobs/upstream_build_from_pw/workspace/.git/rebase-apply/patch
> When you have resolved this problem, run "git am --resolved".
> If you prefer to skip this patch, run "git am --skip" instead.
> To restore the original branch and stop patching, run "git am --abort".
> 
> 
> Please check this out.  If you feel there has been an error, please email 
> acon...@bytheb.org
> 
> Thanks,
> 0-day Robot
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] datapath-windows: Fix invalid reference in Buffermgmt.c

[Sairam Venugopal]

Is it too late to backport this to 2.10?

On 11/15/18, 7:03 AM, "Alin Serdean"  wrote:

I applied the patch on master and as far as it goes without conflicts.

--
Alin.

> -Mesaj original-
> De la: ovs-dev-boun...@openvswitch.org  boun...@openvswitch.org> În numele aserd...@ovn.org
> Trimis: Thursday, November 15, 2018 4:52 PM
> Către: 'Sairam Venugopal' ; d...@openvswitch.org
> Subiect: Re: [ovs-dev] [PATCH] datapath-windows: Fix invalid reference in
> Buffermgmt.c
> 
> Thanks for the fix!
> 
> Acked-by: Alin Gabriel Serdean 
> 
> > -Mesaj original-
> > De la: ovs-dev-boun...@openvswitch.org  > boun...@openvswitch.org> În numele Sairam Venugopal
> > Trimis: Wednesday, November 14, 2018 10:07 PM
> > Către: d...@openvswitch.org
> > Subiect: [ovs-dev] [PATCH] datapath-windows: Fix invalid reference in
> > Buffermgmt.c
> >
> > OVS_BUFFER_CONTEXT gets cleared as part of
> > NdisFreeNetBufferListContext function call. This causes an invalid
> reference
> > error.
> >
> > Found while testing with driver verifier enabled.
> >
> > Signed-off-by: Sairam Venugopal 
> > ---
> >  datapath-windows/ovsext/BufferMgmt.c | 6 --
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/datapath-windows/ovsext/BufferMgmt.c b/datapath-
> > windows/ovsext/BufferMgmt.c index 448cd76..da5c04a 100644
> > --- a/datapath-windows/ovsext/BufferMgmt.c
> > +++ b/datapath-windows/ovsext/BufferMgmt.c
> 
> ___
> dev mailing list
> d...@openvswitch.org
> 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openvswitch.org%2Fmailman%2Flistinfo%2Fovs-devdata=02%7C01%7Cvsairam%40vmware.com%7Ccb97b47b8b964d81494708d64b0b6ce3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636778909792412676sdata=DRZ%2FcHxQoIhqwjl2WZbHNOOI89jwASyJat7oY0qwoD8%3Dreserved=0


___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] datapath-windows: Fix invalid reference in Buffermgmt.c

[Ben Pfaff]

Alin already did that.

On Thu, Nov 15, 2018 at 06:40:00PM +, Sairam Venugopal wrote:
> Is it too late to backport this to 2.10?
> 
> On 11/15/18, 7:03 AM, "Alin Serdean"  wrote:
> 
> I applied the patch on master and as far as it goes without conflicts.
> 
> --
> Alin.
> 
> > -Mesaj original-
> > De la: ovs-dev-boun...@openvswitch.org  > boun...@openvswitch.org> În numele aserd...@ovn.org
> > Trimis: Thursday, November 15, 2018 4:52 PM
> > Către: 'Sairam Venugopal' ; d...@openvswitch.org
> > Subiect: Re: [ovs-dev] [PATCH] datapath-windows: Fix invalid reference 
> in
> > Buffermgmt.c
> > 
> > Thanks for the fix!
> > 
> > Acked-by: Alin Gabriel Serdean 
> > 
> > > -Mesaj original-
> > > De la: ovs-dev-boun...@openvswitch.org  > > boun...@openvswitch.org> În numele Sairam Venugopal
> > > Trimis: Wednesday, November 14, 2018 10:07 PM
> > > Către: d...@openvswitch.org
> > > Subiect: [ovs-dev] [PATCH] datapath-windows: Fix invalid reference in
> > > Buffermgmt.c
> > >
> > > OVS_BUFFER_CONTEXT gets cleared as part of
> > > NdisFreeNetBufferListContext function call. This causes an invalid
> > reference
> > > error.
> > >
> > > Found while testing with driver verifier enabled.
> > >
> > > Signed-off-by: Sairam Venugopal 
> > > ---
> > >  datapath-windows/ovsext/BufferMgmt.c | 6 --
> > >  1 file changed, 4 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/datapath-windows/ovsext/BufferMgmt.c b/datapath-
> > > windows/ovsext/BufferMgmt.c index 448cd76..da5c04a 100644
> > > --- a/datapath-windows/ovsext/BufferMgmt.c
> > > +++ b/datapath-windows/ovsext/BufferMgmt.c
> > 
> > ___
> > dev mailing list
> > d...@openvswitch.org
> > 
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openvswitch.org%2Fmailman%2Flistinfo%2Fovs-devdata=02%7C01%7Cvsairam%40vmware.com%7Ccb97b47b8b964d81494708d64b0b6ce3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636778909792412676sdata=DRZ%2FcHxQoIhqwjl2WZbHNOOI89jwASyJat7oY0qwoD8%3Dreserved=0
> 
> 
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [v3 dpdk-latest 0/3] Update to DPDK 18.11-rc3

[Kevin Traynor]

Sharing minimal set of changes to enable OVS to work with
DPDK 18.11-rc3.

- No docs yet as they mainly point at the release tarball.
- Split out to ease review but they should be squashed for a
  merge, or I can respin.

v3:
- Removed RFC as I think there are a candidate for dpdk-latest.
- 1/3 check offload flag capability
- 3/3 added

v2:
- 2/2 use rte_eth_dev_get_port_by_name() and fix indents 

Kevin Traynor (3):
  netdev-dpdk: Update for DPDK CRC strip flags change.
  netdev-dpdk: Replace rte_eth_dev_attach/detach.
  travis: Update to use DPDK 18.11-rc3.

 .travis/linux-build.sh |  2 +-
 lib/netdev-dpdk.c  | 24 +---
 2 files changed, 14 insertions(+), 12 deletions(-)

-- 
2.19.0

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] Windows: Fix broken kernel userspace communication

[0-day Robot]

Bleep bloop.  Greetings Alin Gabriel Serdean, I am a robot and I have tried out 
your patch.
Thanks for your contribution.

I encountered some error that I wasn't expecting.  See the details below.


git-am:
Failed to merge in the changes.
Patch failed at 0001 Windows: Fix broken kernel userspace communication
The copy of the patch that failed is found in:
   
/var/lib/jenkins/jobs/upstream_build_from_pw/workspace/.git/rebase-apply/patch
When you have resolved this problem, run "git am --resolved".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".


Please check this out.  If you feel there has been an error, please email 
acon...@bytheb.org

Thanks,
0-day Robot
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [v3 dpdk-latest 1/3] netdev-dpdk: Update for DPDK CRC strip flags change.

[Kevin Traynor]

DEV_RX_OFFLOAD_CRC_STRIP has been removed from
DPDK 18.11. DEV_RX_OFFLOAD_KEEP_CRC can now be
used to keep the CRC. Use the correct flag and
check it is supported.

Signed-off-by: Kevin Traynor 
---
 lib/netdev-dpdk.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
index 1480bf8d1..c586144f5 100644
--- a/lib/netdev-dpdk.c
+++ b/lib/netdev-dpdk.c
@@ -930,6 +930,7 @@ dpdk_eth_dev_port_config(struct netdev_dpdk *dev, int 
n_rxq, int n_txq)
 }
 
-if (dev->hw_ol_features & NETDEV_RX_HW_CRC_STRIP) {
-conf.rxmode.offloads |= DEV_RX_OFFLOAD_CRC_STRIP;
+if (!(dev->hw_ol_features & NETDEV_RX_HW_CRC_STRIP)
+&& info.rx_offload_capa & DEV_RX_OFFLOAD_KEEP_CRC) {
+conf.rxmode.offloads |= DEV_RX_OFFLOAD_KEEP_CRC;
 }
 
-- 
2.19.0

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] ovsdb: Clarify that a server that leaves a cluster may never rejoin.

[Ben Pfaff]

I found and fixed some bugs in the Raft implementation.  The patch
series is currently waiting for review:
https://patchwork.ozlabs.org/project/openvswitch/list/?series=76115

On Fri, Nov 09, 2018 at 04:22:51PM +, Paul Greenberg wrote:
> Hi Ben,
> 
> The issues are sporadic. I got prometheus ovn_exporter running to capture 
> relevant RAFT metrics. Once I see them reappearing, I will post log entries 
> around the time when a cluster is in Leader, Candidate, Follower states. 
> (During normal operation, it is Leader, and 2 Followers).
> 
> Best Regards,
> Paul Greenberg
> 
> 
> From: Ben Pfaff 
> Sent: Monday, November 5, 2018 4:21 PM
> To: Paul Greenberg
> Cc: Yifeng Sun; ovs dev
> Subject: Re: [ovs-dev] [PATCH] ovsdb: Clarify that a server that leaves a 
> cluster may never rejoin.
> 
> On Fri, Nov 02, 2018 at 07:08:34PM +, Paul Greenberg wrote:
> > Let me clarify. Based on my observation, once a server loses touch
> > with the rest of the cluster you have to rejoin it.
> > At the same time it is not readily apparent that you have to do the
> > clean up (removal) yourself. For example, you had a cluster of 3
> > nodes, then after some time one node is out. You go to that node and
> > do a cluster join. My understanding is that a new server id gets
> > generated.
> >
> > Now, if you did not do a cleanup, you end up with 4 node cluster. When 3 
> > out of 4 are working, there is no issue. It is almost mandatory to do a 
> > cleanup after join.
> 
> The design intent is that, if a server goes out of contact with the rest
> of the cluster, and later comes back into contact, then it gracefully
> catches up and becomes a productive member of the cluster.
> 
> It seems like you're encountering bugs that I don't understand yet. Can
> you help me to reproduce them?
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 1/2] ovn: Avoid tunneling for VLAN packets redirected to a gateway chassis

[Guru Shetty]

On Fri, 5 Oct 2018 at 10:15,  wrote:

> From: Numan Siddique 
>
> An OVN deployment can have multiple logical switches each with a
> localnet port connected to a distributed logical router with one
> logical router port providing external connectivity (provider network)
> and others used as tenant networks with VLAN tagging.
>
> As reported in [1], external traffic from these VLAN tenant networks
> are tunnelled to the gateway chassis (chassis hosting a distributed
> gateway port which applies NAT rules). As part of the discussion in
> [1], there were few possible solutions proposed by Russell [2]. This
> patch implements the first option in [2].
>
> With this patch, a new option 'reside-on-redirect-chassis' in 'options'
> column of Logical_Router_Port table is added. If the value of this
> option is set to 'true' and if the logical router also have a
> distributed gateway port, then routing for this logical router port
> is centralized in the chassis hosting the distributed gateway port.
>
> If a logical switch 'sw0' is connected to a router 'lr0' with the
> router port - 'lr0-sw0' with the address - "00:00:00:00:af:12 192.168.1.1"
> , and it has a distributed logical port - 'lr0-public', then the
> below logical flow is added in the logical switch pipeline
> of 'sw0' if the 'reside-on-redirect-chassis' option is set on 'lr-sw0' -
>
> table=16(ls_in_l2_lkup), priority=50,
> match=(eth.dst == 00:00:00:00:af:12 &&
> is_chassis_resident("cr-lr0-public")),
> action=(outport = "sw0-lr0"; output;)
>

Where does "cr" come from.

>
> With the above flow, the packet doesn't enter the router pipeline in
> the source chassis. Instead the packet is sent out via the localnet
> port of 'sw0'. The gateway chassis upon receiving this packet, runs
> the logical router pipeline applying NAT rules and sends the traffic
> out via the localnet port of the provider network. The gateway
> chassis will also reply to the ARP requests for the router port IPs.
>
> With this approach, we avoid redirecting the external traffic to the
> gateway chassis via the tunnel port. There are a couple of drawbacks
> with this approach:
>
>   - East - West routing is no more distributed for the VLAN tenant
> networks if 'reside-on-redirect-chassis' option is defined
>
>   - 'dnat_and_snat' NAT rules with 'logical_mac' and 'logical_port'
> columns defined will not work for the VLAN tenant networks.
>
> This approach is taken for now as it is simple. If there is a requirement
> to support distributed routing for these VLAN tenant networks, we
> can explore other possible solutions.
>
> [1] -
> https://mail.openvswitch.org/pipermail/ovs-discuss/2018-April/046543.html
> [2] -
> https://mail.openvswitch.org/pipermail/ovs-discuss/2018-April/046557.html
>
> Reported-at:
> https://mail.openvswitch.org/pipermail/ovs-discuss/2018-April/046543.html
> Reported-by: venkata anil 
> Co-authored-by: venkata anil 
> Signed-off-by: Numan Siddique 
> Signed-off-by: venkata anil 
>

Acked-by: Gurucharan Shetty 

A few comments below.

> ---
>  ovn/northd/ovn-northd.8.xml |  30 
>  ovn/northd/ovn-northd.c |  71 +++---
>  ovn/ovn-architecture.7.xml  | 160 +
>  ovn/ovn-nb.xml  |  43 ++
>  tests/ovn.at| 273 
>  5 files changed, 561 insertions(+), 16 deletions(-)
>
> diff --git a/ovn/northd/ovn-northd.8.xml b/ovn/northd/ovn-northd.8.xml
> index 7352c6764..f52699bd3 100644
> --- a/ovn/northd/ovn-northd.8.xml
> +++ b/ovn/northd/ovn-northd.8.xml
> @@ -874,6 +874,25 @@ output;
>  resident.
>
>  
> +
> +
> +  For the Ethernet address on a logical switch port of type
> +  router, when that logical switch port's
> +   +  db="OVN_Northbound"/> column is set to router and
> +  the connected logical router port specifies a
> +  reside-on-redirect-chassis and the logical router
> +  to which the connected logical router port belongs to has a
> +  redirect-chassis distributed gateway logical router
> +  port:
> +
> +
> +
> +  
> +The flow for the connected logical router port's Ethernet
> +address is only programmed on the
> redirect-chassis.
> +  
> +
>
>
>
> @@ -1179,6 +1198,17 @@ output;
>upstream MAC learning to point to the
>redirect-chassis.
>  
> +
> +
> +  For the logical router port with the option
> +  reside-on-redirect-chassis set (which is
> centralized),
> +  the above flows are only programmed on the gateway port
> instance on
> +  the redirect-chassis (if the logical router has a
> +  distributed gateway port). This behavior avoids generation
> +  of multiple ARP responses from different chassis, and allows
> +  upstream MAC learning to point to the
> +  

Re: [ovs-dev] [RFC dpdk-latest 2/2] netdev-dpdk: Replace rte_eth_dev_attach/detach.

[Stokes, Ian]

> On 11/15/2018 04:38 PM, Ophir Munk wrote:
> > Hi Kevin,
> > Thanks for this RFC. Please find comments inline.
> >
> >> -Original Message-
> >> From: Kevin Traynor [mailto:ktray...@redhat.com]
> >> Sent: Thursday, November 08, 2018 8:37 PM
> >> To: d...@openvswitch.org; Ophir Munk ;
> >> ian.sto...@intel.com; i.maxim...@samsung.com
> >> Cc: Kevin Traynor 
> >> Subject: [RFC dpdk-latest 2/2] netdev-dpdk: Replace
> >> rte_eth_dev_attach/detach.
> >>
> >> rte_eth_dev_attach/detach have been removed from DPDK 18.11. Replace
> >> them with rte_dev_probe/remove.
> >>
> >
> > I have submitted a patch on the same issue, see [1].
> > Please suggest how to unify our patches.
> >
> 
> Hi Ophir,
> 
> I looked through your patch and it is trying to do two things:
> 1. update OVS to use DPDK 18.11
> 2. enable additional functionality/representors etc in OVS based on using
> DPDK 18.11
> 
> I don't think that needs to be all in one patch and there isn't really any
> throw away work in doing 1. on it's own. My suggestion is that we proceed
> with 1. through the patches I sent, and then (or in parallel) you can send
> patches to cover 2.
> 
> What do people think?

+1, the RFC submitted by Kevin to move to 18.11 isn't too complicated and 
allows for the same functionality we had when using DPDK 17.11. My preference 
is to upstream this work first. This provides a stable base to work from when 
adding the new functionality enabled by 18.11.

Upstreaming this work first will enable the travis build for dpdk-latest and 
dpdk-hwol to pass again which is also welcome.

Ian

> 
> thanks,
> Kevin.
> 
> >> Signed-off-by: Kevin Traynor 
> >> ---
> >>  lib/netdev-dpdk.c | 29 +
> >>  1 file changed, 17 insertions(+), 12 deletions(-)
> >>
> >> diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c index
> >> 10c4879a1..190d50007 100644
> >> --- a/lib/netdev-dpdk.c
> >> +++ b/lib/netdev-dpdk.c
> >> @@ -1351,5 +1351,5 @@ netdev_dpdk_destruct(struct netdev *netdev)  {
> >>  struct netdev_dpdk *dev = netdev_dpdk_cast(netdev);
> >> -char devname[RTE_ETH_NAME_MAX_LEN];
> >> +struct rte_eth_dev_info dev_info;
> >>
> >>  ovs_mutex_lock(_mutex);
> >> @@ -1360,8 +1360,9 @@ netdev_dpdk_destruct(struct netdev *netdev)
> >>  if (dev->attached) {
> >>  rte_eth_dev_close(dev->port_id);
> >> -if (rte_eth_dev_detach(dev->port_id, devname) < 0) {
> >> +rte_eth_dev_info_get(dev->port_id, _info);
> >
> > I suggest having a direct access to the device (rather than accessing
> dev_info).
> > rte_eth_devices[dev->port_id].device;
> >
> >> +if (dev_info.device && !rte_dev_remove(dev_info.device)) {
> >
> > With dpdk 18.11 an rte device can be used by multiple eth devices (one
> to many relationship).
> > Remark: in OVS terms an eth device is a dpdk port_id.
> > When calling rte_dev_remove() all the eth devices are closed and the PCI
> device is detached.
> > We need to count the number of eth devices used by the rte device.
> > Only when closing the last eth device shoud we call rte_dev_remove (it
> is like a reference count algorithm).
> > For example: if we add to OVS 2 ports belonging the same rte device
> (e.g. the same PCI bus address) then after deleting one of the ports we
> should not implicitly delete the other port.
> > This case is handled in [1]
> >
> >> +VLOG_INFO("Device '%s' has been detached", dev->devargs);
> >> +} else {
> >>  VLOG_ERR("Device '%s' can not be detached", dev->devargs);
> >> -} else {
> >> -VLOG_INFO("Device '%s' has been detached", devname);
> >>  }
> >>  }
> >> @@ -1645,5 +1646,5 @@ netdev_dpdk_process_devargs(struct
> >> netdev_dpdk *dev,
> >>  char *name;
> >>  dpdk_port_t new_port_id = DPDK_ETH_PORT_ID_INVALID;
> >> -
> >> +struct rte_dev_iterator iterator;
> >>  if (strncmp(devargs, "class=eth,mac=", 14) == 0) {
> >>  new_port_id = netdev_dpdk_get_port_by_mac([14]);
> >> @@ -1653,8 +1654,12 @@ netdev_dpdk_process_devargs(struct
> >> netdev_dpdk *dev,
> >>  || !rte_eth_dev_is_valid_port(new_port_id)) {
> >>  /* Device not found in DPDK, attempt to attach it */
> >> -if (!rte_eth_dev_attach(devargs, _port_id)) {
> >> +if (!rte_dev_probe(devargs)) {
> >>  /* Attach successful */
> >>  dev->attached = true;
> >>  VLOG_INFO("Device '%s' attached to DPDK", devargs);
> >> +RTE_ETH_FOREACH_MATCHING_DEV(new_port_id, devargs,
> >> ) {
> >> +rte_eth_iterator_cleanup();
> >
> > +1
> > Good point which I missed!
> > Indeed we should free resources by calling the
> rte_eth_iterator_cleanup().
> >
> >> +break;
> >> +}
> >>  } else {
> >
> > It seems with this patch the code still has the call:
> rte_eth_dev_get_port_by_name().
> > This call is no more relevant when using 

Re: [ovs-dev] [RFC dpdk-latest 2/2] netdev-dpdk: Replace rte_eth_dev_attach/detach.

[Kevin Traynor]

On 11/15/2018 04:38 PM, Ophir Munk wrote:
> Hi Kevin,
> Thanks for this RFC. Please find comments inline.
> 
>> -Original Message-
>> From: Kevin Traynor [mailto:ktray...@redhat.com]
>> Sent: Thursday, November 08, 2018 8:37 PM
>> To: d...@openvswitch.org; Ophir Munk ;
>> ian.sto...@intel.com; i.maxim...@samsung.com
>> Cc: Kevin Traynor 
>> Subject: [RFC dpdk-latest 2/2] netdev-dpdk: Replace
>> rte_eth_dev_attach/detach.
>>
>> rte_eth_dev_attach/detach have been removed from DPDK 18.11. Replace
>> them with rte_dev_probe/remove.
>>
> 
> I have submitted a patch on the same issue, see [1]. 
> Please suggest how to unify our patches.
> 

Hi Ophir,

I looked through your patch and it is trying to do two things:
1. update OVS to use DPDK 18.11
2. enable additional functionality/representors etc in OVS based on
using DPDK 18.11

I don't think that needs to be all in one patch and there isn't really
any throw away work in doing 1. on it's own. My suggestion is that we
proceed with 1. through the patches I sent, and then (or in parallel)
you can send patches to cover 2.

What do people think?

thanks,
Kevin.

>> Signed-off-by: Kevin Traynor 
>> ---
>>  lib/netdev-dpdk.c | 29 +
>>  1 file changed, 17 insertions(+), 12 deletions(-)
>>
>> diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c index
>> 10c4879a1..190d50007 100644
>> --- a/lib/netdev-dpdk.c
>> +++ b/lib/netdev-dpdk.c
>> @@ -1351,5 +1351,5 @@ netdev_dpdk_destruct(struct netdev *netdev)  {
>>  struct netdev_dpdk *dev = netdev_dpdk_cast(netdev);
>> -char devname[RTE_ETH_NAME_MAX_LEN];
>> +struct rte_eth_dev_info dev_info;
>>
>>  ovs_mutex_lock(_mutex);
>> @@ -1360,8 +1360,9 @@ netdev_dpdk_destruct(struct netdev *netdev)
>>  if (dev->attached) {
>>  rte_eth_dev_close(dev->port_id);
>> -if (rte_eth_dev_detach(dev->port_id, devname) < 0) {
>> +rte_eth_dev_info_get(dev->port_id, _info);
> 
> I suggest having a direct access to the device (rather than accessing 
> dev_info).
> rte_eth_devices[dev->port_id].device;
> 
>> +if (dev_info.device && !rte_dev_remove(dev_info.device)) {
> 
> With dpdk 18.11 an rte device can be used by multiple eth devices (one to 
> many relationship).
> Remark: in OVS terms an eth device is a dpdk port_id.
> When calling rte_dev_remove() all the eth devices are closed and the PCI 
> device is detached. 
> We need to count the number of eth devices used by the rte device. Only when 
> closing the last eth device 
> shoud we call rte_dev_remove (it is like a reference count algorithm).
> For example: if we add to OVS 2 ports belonging the same rte device (e.g. the 
> same PCI bus address) then after deleting one of the ports we should not 
> implicitly delete the other port. 
> This case is handled in [1]
> 
>> +VLOG_INFO("Device '%s' has been detached", dev->devargs);
>> +} else {
>>  VLOG_ERR("Device '%s' can not be detached", dev->devargs);
>> -} else {
>> -VLOG_INFO("Device '%s' has been detached", devname);
>>  }
>>  }
>> @@ -1645,5 +1646,5 @@ netdev_dpdk_process_devargs(struct
>> netdev_dpdk *dev,
>>  char *name;
>>  dpdk_port_t new_port_id = DPDK_ETH_PORT_ID_INVALID;
>> -
>> +struct rte_dev_iterator iterator;
>>  if (strncmp(devargs, "class=eth,mac=", 14) == 0) {
>>  new_port_id = netdev_dpdk_get_port_by_mac([14]);
>> @@ -1653,8 +1654,12 @@ netdev_dpdk_process_devargs(struct
>> netdev_dpdk *dev,
>>  || !rte_eth_dev_is_valid_port(new_port_id)) {
>>  /* Device not found in DPDK, attempt to attach it */
>> -if (!rte_eth_dev_attach(devargs, _port_id)) {
>> +if (!rte_dev_probe(devargs)) {
>>  /* Attach successful */
>>  dev->attached = true;
>>  VLOG_INFO("Device '%s' attached to DPDK", devargs);
>> +RTE_ETH_FOREACH_MATCHING_DEV(new_port_id, devargs,
>> ) {
>> +rte_eth_iterator_cleanup();
> 
> +1
> Good point which I missed! 
> Indeed we should free resources by calling the rte_eth_iterator_cleanup().
> 
>> +break;
>> +}
>>  } else {
> 
> It seems with this patch the code still has the call: 
> rte_eth_dev_get_port_by_name(). 
> This call is no more relevant when using representors. Previously a PCI 
> address (e.g. :08.00:0) was used in devargs.
> With dpdk 18.11 a device devargs became a regular expression string, (e.g. 
> :08.00:0,representor=[1]) which is different than the device name 
> assigned by the PMD.
> In other words: previously devargs and device name where identical. Starting 
> from dpdk 18.11 they are not.
> This case is handled in [1].
> 

They are all valid comments, but as per above, I was only trying to
cover 1. in these patches.

>>  /* Attach unsuccessful */ @@ -3206,6 +3211,6 @@
>> netdev_dpdk_detach(struct unixctl_conn *conn, int 

Re: [ovs-dev] [PATCH v2] ovn-sb.ovsschema: Avoid duplicated IPs in Encap table.

[Ben Pfaff]

On Tue, Nov 13, 2018 at 11:25:59AM -0800, Han Zhou wrote:
> From: Han Zhou 
> 
> When adding a new chassis, if there is an old chassis with same IP
> existed in Encap table, it is allowed to be added today. However,
> allowing it to be added results in problems:
> 
> 1. The new chassis cannot work because none of the other chassises
>are able to create tunnel to it, because of the IP confliction
>with already existed tunnel to the old chassis.
> 
> 2. All the other chassises will continuously retry creating the tunnel
>and complaining about the error.
> 
> So, instead of hiding the problem, it is better to expose it while
> trying to add the second chassis with duplicated IP. This patch
> ensures it from the ovsdb schema.
> 
> Signed-off-by: Han Zhou 

I'm worried that this will make it hard for users to upgrade: if they
have any duplicate chassis, then they will have to manually delete them
before ovsdb-server will accept the new database.

I think you mentioned that ovn-controller can't delete the duplicates
because of RBAC permissions.  What if ovn-northd deletes them instead?
If it doesn't have a way to know which one is the "correct" one, it
could just delete all of the duplicates, since the ovn-controller that
is actually running will re-create its chassis if it disappears.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] dpif-netlink: Fix error behavior in dpif_netlink_port_add__().

[Ben Pfaff]

Thanks, applied and backported.

On Thu, Nov 15, 2018 at 07:27:11PM +0200, aserd...@ovn.org wrote:
> Acked-by: Alin Gabriel Serdean 
> 
> 
> > -Mesaj original-
> > De la: ovs-dev-boun...@openvswitch.org  > boun...@openvswitch.org> În numele Ben Pfaff
> > Trimis: Thursday, November 15, 2018 7:08 PM
> > Către: d...@openvswitch.org
> > Cc: Ben Pfaff 
> > Subiect: [ovs-dev] [PATCH] dpif-netlink: Fix error behavior in
> > dpif_netlink_port_add__().
> > 
> > Until now, the code here would report an error to its caller as success.
> > This fixes the problem.
> > 
> > Found by inspection.
> > 
> > Signed-off-by: Ben Pfaff 
> > ---
> >  lib/dpif-netlink.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c index
> > f2011f22e548..7f6a6cc59592 100644
> > --- a/lib/dpif-netlink.c
> > +++ b/lib/dpif-netlink.c
> > @@ -716,7 +716,8 @@ dpif_netlink_port_add__(struct dpif_netlink *dpif,
> > const char *name,
> >  int error = 0;
> > 
> >  if (dpif->handlers) {
> > -if (nl_sock_create(NETLINK_GENERIC, )) {
> > +error = nl_sock_create(NETLINK_GENERIC, );
> > +if (error) {
> >  return error;
> >  }
> >  }
> > --
> > 2.16.1
> > 
> > ___
> > dev mailing list
> > d...@openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
> 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [ovs-dev, dpdk-latest, v1] netdev-dpdk: Upgrade to dpdk v18.11

[Kevin Traynor]

On 11/15/2018 07:07 AM, Ilya Maximets wrote:
> Hmm.
> Kevin already has a patch-set with the same purpose:
> https://patchwork.ozlabs.org/project/openvswitch/list/?series=75100
> 
> This patch-set already has some review comments. You can make your
> comments too.
> 
> Anyway, Kevin, Ophir, you need to synchronize somehow in order to stop
> duplicating each other's work and to not force reviewers to notice same
> things twice.
> 
> P.S. Ophir, It'll be nice if you could add involved people to CC list
>  while sending patches.
> 
> Best regards, Ilya Maximets.
> 

Hi Ilya, I made a suggestion for how to proceed in the other thread:
https://mail.openvswitch.org/pipermail/ovs-dev/2018-November/353955.html

thanks,
Kevin.

> On 15.11.2018 1:08, Ophir Munk wrote:
>> 1. Enable compilation and linkage with dpdk 18.11.x
>>
>> 2. Update references to DPDK version 18.11 in Documentation and in
>> travis linux-build script
>>
>> 3. Replace deprecated functions calls
>> - rte_eth_dev_attach
>> - rte_eth_dev_detach
>> with their respective new calls
>> - rte_dev_probe
>> - rte_dev_remove
>>
>> 4. Dpdk port representors were introduced in dpdk 18.xx.
>> Commits examples are listed in [1]. dpdk representors
>> documentation appears in [2]. A sample configuration which uses two
>> representors ports (the output of "ovs-vsctl show" command) is
>> shown in [3].
>>
>> OVS remains backward compatible in supporting dpdk legacy PCI
>> ports which do not include representors.
>>
>> 5. Starting from dpdk 18.xx there is no more one to one relationship
>> between an rte device (e.g. PCI bus) and an eth device (seen as dpdk
>> port ids by OVS).
>> The relationship became one (rte device) to many (eth devices).
>> For example in [3] there are two devices (representors) using
>> the same PCI address :08:00.0.
>> This commit handles the new one to many relationship. For example,
>> when one of the devices representors is closed - the PCI bus cannot
>> be detached until the other device is closed as well.
>>
>> 6. HW offload capability DEV_RX_OFFLOAD_CRC_STRIP was replaced with
>> DEV_RX_OFFLOAD_KEEP_CRC.
>>
>> [1]
>> e0cb96204b71 ("net/i40e: add support for representor ports")
>> cf80ba6e2038 ("net/ixgbe: add support for representor ports")
>> 26c08b979d26 ("net/mlx5: add port representor awareness")
>>
>> [2]
>> doc/guides/prog_guide/switch_representation.rst
>>
>> [3]
>> Bridge "ovs_br0"
>> Port "ovs_br0"
>> Interface "ovs_br0"
>> type: internal
>> Port "port-rep3"
>> Interface "port-rep3"
>> type: dpdk
>> options: {dpdk-devargs=":08:00.0,representor=[3]"}
>> Port "port-rep5"
>> Interface "port-rep5"
>> type: dpdk
>> options: {dpdk-devargs=":08:00.0,representor=[5]"}
>> ovs_version: "2.10.90"
>>
>> Signed-off-by: Ophir Munk 
>> ---
>> v1:
>> Initial version (resent with [dpdk-latest PATCH v1])
>>
>>  .travis/linux-build.sh   |   2 +-
>>  Documentation/intro/install/dpdk.rst |  12 ++--
>>  Documentation/topics/dpdk/vhost-user.rst |   6 +-
>>  lib/netdev-dpdk.c| 111 
>> ++-
>>  4 files changed, 91 insertions(+), 40 deletions(-)
>>

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] Windows: Fix broken kernel userspace communication

[Alin Serdean]

> -Mesaj original-
> De la: ovs-dev-boun...@openvswitch.org  boun...@openvswitch.org> În numele Ben Pfaff
> Trimis: Thursday, November 15, 2018 7:12 PM
> Către: Alin Gabriel Serdean 
> Cc: d...@openvswitch.org
> Subiect: Re: [ovs-dev] [PATCH] Windows: Fix broken kernel userspace
> communication
> 
> On Thu, Nov 15, 2018 at 06:42:38PM +0200, Alin Gabriel Serdean wrote:
> > Patch:
> >
> https://github.com/openvswitch/ovs/commit/69c51582ff786a68fc325c1c506
> 2
> > 4715482bc460 broke Windows userpace - kernel communication.
> >
> > On windows we create netlink sockets when the handlers are initiated
> > and reuse them.
> > This patch remaps the usage of the netlink socket pool.
> >
> > Fixes:
> > https://github.com/openvswitch/ovs-issues/issues/164
> >
> > Signed-off-by: Alin Gabriel Serdean 
> > Acked-by: Shashank Ram 
> > Tested-by: Shashank Ram 
> 
> Sorry we broke Windows.  I apologize.
[Alin Serdean] No worries. Maybe this increases the awareness about the
need of a CI.
> 
> Usually I prefer to put all the #ifdefs in a single place when I can.
> In this case, I think that means putting them inside
> create_socksp_windows() and del_socksp_windows().  It's easy enough.
> 
> But del_socksp_windows() is a really weird function.  It does nothing:
> it sets one of its parameters to NULL, which is not visible outside the
> function, and it ignores its other parameter.  That would make sense if there
> were multiple implementations, or if it were referred to via function pointer,
> etc., but I don't understand it here.  Why call it at all?
[Alin Serdean] No reason, I forgot to remove when I sent the v1.
> 
> Anyhow, here is one variation that I suggest.  I built it on Linux but not on
> Windows, so maybe I screwed some things up.
> 
> Actually, looking at it again, I think that the first change in
> dpif_netlink_port_add__() fixes a bug: it looks like, previously, an error
> return from nl_sock_create() was passed up to the caller as a success.  I
> guess that should be fixed in a separate patch, first:
[Alin Serdean] Yup I folded it in my patch when I should've sent a different
patch.
I acked your patch.
> https://mail.openvswitch.org/pipermail/ovs-dev/2018-
> November/353952.html
[Alin Serdean] Thanks a lot for the review and incremental patch!
> 
> --8<--cut here-->8--
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] Windows: Fix broken kernel userspace communication

[Ben Pfaff]

On Thu, Nov 15, 2018 at 06:42:38PM +0200, Alin Gabriel Serdean wrote:
> Patch: 
> https://github.com/openvswitch/ovs/commit/69c51582ff786a68fc325c1c50624715482bc460
> broke Windows userpace - kernel communication.
> 
> On windows we create netlink sockets when the handlers are initiated and
> reuse them.
> This patch remaps the usage of the netlink socket pool.
> 
> Fixes:
> https://github.com/openvswitch/ovs-issues/issues/164
> 
> Signed-off-by: Alin Gabriel Serdean 
> Acked-by: Shashank Ram 
> Tested-by: Shashank Ram 

Sorry we broke Windows.  I apologize.

Usually I prefer to put all the #ifdefs in a single place when I can.
In this case, I think that means putting them inside
create_socksp_windows() and del_socksp_windows().  It's easy enough.

But del_socksp_windows() is a really weird function.  It does nothing:
it sets one of its parameters to NULL, which is not visible outside the
function, and it ignores its other parameter.  That would make sense if
there were multiple implementations, or if it were referred to via
function pointer, etc., but I don't understand it here.  Why call it at
all?

Anyhow, here is one variation that I suggest.  I built it on Linux but
not on Windows, so maybe I screwed some things up.

Actually, looking at it again, I think that the first change in
dpif_netlink_port_add__() fixes a bug: it looks like, previously, an
error return from nl_sock_create() was passed up to the caller as a
success.  I guess that should be fixed in a separate patch, first:
https://mail.openvswitch.org/pipermail/ovs-dev/2018-November/353952.html

--8<--cut here-->8--


From: Alin Gabriel Serdean 
Date: Thu, 15 Nov 2018 18:42:38 +0200
Subject: [PATCH] Windows: Fix broken kernel userspace communication

Patch: 
https://github.com/openvswitch/ovs/commit/69c51582ff786a68fc325c1c50624715482bc460
broke Windows userpace - kernel communication.

On windows we create netlink sockets when the handlers are initiated and
reuse them.
This patch remaps the usage of the netlink socket pool.

Fixes:
https://github.com/openvswitch/ovs-issues/issues/164

Signed-off-by: Alin Gabriel Serdean 
Acked-by: Shashank Ram 
Tested-by: Shashank Ram 
Signed-off-by: Ben Pfaff 
---
 lib/dpif-netlink.c | 52 
 1 file changed, 48 insertions(+), 4 deletions(-)

diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c
index f2011f22e548..3fed5e97b5ec 100644
--- a/lib/dpif-netlink.c
+++ b/lib/dpif-netlink.c
@@ -246,6 +246,42 @@ static int dpif_netlink_port_query__(const struct 
dpif_netlink *dpif,
  odp_port_t port_no, const char *port_name,
  struct dpif_port *dpif_port);
 
+static int
+create_nl_sock(struct dpif_netlink *dpif OVS_UNUSED, struct nl_sock **socksp)
+OVS_REQ_WRLOCK(dpif->upcall_lock)
+{
+#ifndef _WIN32
+return nl_sock_create(NETLINK_GENERIC, socksp);
+#else
+/* Pick netlink sockets to use in a round-robin fashion from each
+ * handler's pool of sockets. */
+struct dpif_handler *handler = >handlers[0];
+struct dpif_windows_vport_sock *sock_pool = handler->vport_sock_pool;
+size_t index = handler->last_used_pool_idx;
+
+/* A pool of sockets is allocated when the handler is initialized. */
+if (sock_pool == NULL) {
+*socksp = NULL;
+return EINVAL;
+}
+
+ovs_assert(index < VPORT_SOCK_POOL_SIZE);
+*socksp = sock_pool[index].nl_sock;
+ovs_assert(*socksp);
+index = (index == VPORT_SOCK_POOL_SIZE - 1) ? 0 : index + 1;
+handler->last_used_pool_idx = index;
+return 0;
+#endif
+}
+
+static void
+close_nl_sock(struct nl_sock *socksp)
+{
+#ifndef _WIN32
+nl_sock_destroy(socksp);
+#endif
+}
+
 static struct dpif_netlink *
 dpif_netlink_cast(const struct dpif *dpif)
 {
@@ -716,7 +752,8 @@ dpif_netlink_port_add__(struct dpif_netlink *dpif, const 
char *name,
 int error = 0;
 
 if (dpif->handlers) {
-if (nl_sock_create(NETLINK_GENERIC, )) {
+error = create_nl_sock(dpif, );
+if (error) {
 return error;
 }
 }
@@ -748,7 +785,7 @@ dpif_netlink_port_add__(struct dpif_netlink *dpif, const 
char *name,
   dpif_name(>dpif), *port_nop);
 }
 
-nl_sock_destroy(socksp);
+close_nl_sock(socksp);
 goto exit;
 }
 
@@ -763,7 +800,7 @@ dpif_netlink_port_add__(struct dpif_netlink *dpif, const 
char *name,
 request.dp_ifindex = dpif->dp_ifindex;
 request.port_no = *port_nop;
 dpif_netlink_vport_transact(, NULL, NULL);
-nl_sock_destroy(socksp);
+close_nl_sock(socksp);
 goto exit;
 }
 
@@ -2280,15 +2317,22 @@ dpif_netlink_refresh_channels(struct dpif_netlink 
*dpif, uint32_t n_handlers)
 || !vport_get_pid(dpif, port_no, _pid)) {
 struct nl_sock *socksp;
 
+#ifdef _WIN32
+socksp = 

[ovs-dev] [PATCH] dpif-netlink: Fix error behavior in dpif_netlink_port_add__().

[Ben Pfaff]

Until now, the code here would report an error to its caller as success.
This fixes the problem.

Found by inspection.

Signed-off-by: Ben Pfaff 
---
 lib/dpif-netlink.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c
index f2011f22e548..7f6a6cc59592 100644
--- a/lib/dpif-netlink.c
+++ b/lib/dpif-netlink.c
@@ -716,7 +716,8 @@ dpif_netlink_port_add__(struct dpif_netlink *dpif, const 
char *name,
 int error = 0;
 
 if (dpif->handlers) {
-if (nl_sock_create(NETLINK_GENERIC, )) {
+error = nl_sock_create(NETLINK_GENERIC, );
+if (error) {
 return error;
 }
 }
-- 
2.16.1

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [RFC v2 dpdk-latest 1/2] netdev-dpdk: Update for DPDK CRC strip flags change.

[Kevin Traynor]

On 11/15/2018 04:40 PM, Ophir Munk wrote:
> 
> 
>> -Original Message-
>> From: Stokes, Ian [mailto:ian.sto...@intel.com]
>> Sent: Wednesday, November 14, 2018 3:16 PM
>> To: Kevin Traynor ; d...@openvswitch.org; Ophir
>> Munk ; i.maxim...@samsung.com
>> Cc: Christian Ehrhardt 
>> Subject: RE: [RFC v2 dpdk-latest 1/2] netdev-dpdk: Update for DPDK CRC
>> strip flags change.
>>
>>> -if (dev->hw_ol_features & NETDEV_RX_HW_CRC_STRIP) {
>>> -conf.rxmode.offloads |= DEV_RX_OFFLOAD_CRC_STRIP;
>>> +if (!(dev->hw_ol_features & NETDEV_RX_HW_CRC_STRIP)) {
>>> +conf.rxmode.offloads |= DEV_RX_OFFLOAD_KEEP_CRC;
>>>  }
>>
>> Hi Kevin,
>>
>> Thanks for this series. Technically the behavior from OVS does change here
>> as previously if NETDEV_RX_HW_CRC_STRIP wasn't supported we wouldn't
>> set DEV_RX_OFFLOAD_KEEP_CRC. For vdevs it could be the case that this
>> isn't supported.
>>

Hi Ian, previously there was no check to see if STRIP/KEEP was supported
but DPDK wasn't strict about it, so it worked. Now DPDK cares, so the
check must be added. Will send v3 with check.

>> I spotted this testing the net_null pmd, it now fails to init. It's a corner 
>> case
>> for sure but probably should be checked that support is there before
>> explicitly setting it.
>>
> 
> This case is handled in https://patchwork.ozlabs.org/patch/997879/
> 

yep, a check needed to be added against device capability, as for
example net_null reports not supporting offloads.

thanks,
Kevin.

>> Thanks
>> Ian
> 

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] Windows: Fix broken kernel userspace communication

[Alin Gabriel Serdean]

Patch: 
https://github.com/openvswitch/ovs/commit/69c51582ff786a68fc325c1c50624715482bc460
broke Windows userpace - kernel communication.

On windows we create netlink sockets when the handlers are initiated and
reuse them.
This patch remaps the usage of the netlink socket pool.

Fixes:
https://github.com/openvswitch/ovs-issues/issues/164

Signed-off-by: Alin Gabriel Serdean 
Acked-by: Shashank Ram 
Tested-by: Shashank Ram 
---
RFC -> v1: Improve wording, change function name and add ifdef guard for them
---
 lib/dpif-netlink.c | 57 +-
 1 file changed, 56 insertions(+), 1 deletion(-)

diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c
index 69c145cc3..d2adb8b60 100644
--- a/lib/dpif-netlink.c
+++ b/lib/dpif-netlink.c
@@ -246,6 +246,37 @@ static int dpif_netlink_port_query__(const struct 
dpif_netlink *dpif,
  odp_port_t port_no, const char *port_name,
  struct dpif_port *dpif_port);
 
+#ifdef _WIN32
+static struct nl_sock *
+create_socksp_windows(struct dpif_netlink *dpif, int *error)
+OVS_REQ_WRLOCK(dpif->upcall_lock)
+{
+struct nl_sock *socksp;
+/* Pick netlink sockets to use in a round-robin fashion from each
+ * handler's pool of sockets. */
+struct dpif_handler *handler = >handlers[0];
+struct dpif_windows_vport_sock *sock_pool = handler->vport_sock_pool;
+size_t index = handler->last_used_pool_idx;
+/* A pool of sockets is allocated when the handler is initialized. */
+if (sock_pool == NULL) {
+*error = EINVAL;
+return NULL;
+}
+ovs_assert(index < VPORT_SOCK_POOL_SIZE);
+socksp = sock_pool[index].nl_sock;
+ovs_assert(socksp);
+index = (index == VPORT_SOCK_POOL_SIZE - 1) ? 0 : index + 1;
+handler->last_used_pool_idx = index;
+*error = 0;
+return socksp;
+}
+static void
+del_socksp_windows(struct dpif_netlink *dpif, struct nl_sock *socksp)
+{
+socksp = NULL;
+}
+#endif
+
 static struct dpif_netlink *
 dpif_netlink_cast(const struct dpif *dpif)
 {
@@ -716,7 +747,12 @@ dpif_netlink_port_add__(struct dpif_netlink *dpif, const 
char *name,
 int error = 0;
 
 if (dpif->handlers) {
-if (nl_sock_create(NETLINK_GENERIC, )) {
+#ifdef _WIN32
+socksp = create_socksp_windows(dpif, );
+#else
+error = nl_sock_create(NETLINK_GENERIC, );
+#endif
+if (!socksp) {
 return error;
 }
 }
@@ -748,7 +784,11 @@ dpif_netlink_port_add__(struct dpif_netlink *dpif, const 
char *name,
   dpif_name(>dpif), *port_nop);
 }
 
+#ifdef _WIN32
+del_socksp_windows(dpif, socksp);
+#else
 nl_sock_destroy(socksp);
+#endif
 goto exit;
 }
 
@@ -763,7 +803,11 @@ dpif_netlink_port_add__(struct dpif_netlink *dpif, const 
char *name,
 request.dp_ifindex = dpif->dp_ifindex;
 request.port_no = *port_nop;
 dpif_netlink_vport_transact(, NULL, NULL);
+#ifdef _WIN32
+del_socksp_windows(dpif, socksp);
+#else
 nl_sock_destroy(socksp);
+#endif
 goto exit;
 }
 
@@ -2249,15 +2293,26 @@ dpif_netlink_refresh_channels(struct dpif_netlink 
*dpif, uint32_t n_handlers)
 || !vport_get_pid(dpif, port_no, _pid)) {
 struct nl_sock *socksp;
 
+#ifdef _WIN32
+socksp = create_socksp_windows(dpif, );
+if (!socksp) {
+goto error;
+}
+#else
 if (nl_sock_create(NETLINK_GENERIC, )) {
 goto error;
 }
+#endif
 
 error = vport_add_channel(dpif, vport.port_no, socksp);
 if (error) {
 VLOG_INFO("%s: could not add channels for port %s",
   dpif_name(>dpif), vport.name);
+#ifdef _WIN32
+del_socksp_windows(dpif, socksp);
+#else
 nl_sock_destroy(socksp);
+#endif
 retval = error;
 goto error;
 }
-- 
2.16.1.windows.1

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [RFC dpdk-latest 2/2] netdev-dpdk: Replace rte_eth_dev_attach/detach.

[Ophir Munk]

Hi Kevin,
Thanks for this RFC. Please find comments inline.

> -Original Message-
> From: Kevin Traynor [mailto:ktray...@redhat.com]
> Sent: Thursday, November 08, 2018 8:37 PM
> To: d...@openvswitch.org; Ophir Munk ;
> ian.sto...@intel.com; i.maxim...@samsung.com
> Cc: Kevin Traynor 
> Subject: [RFC dpdk-latest 2/2] netdev-dpdk: Replace
> rte_eth_dev_attach/detach.
> 
> rte_eth_dev_attach/detach have been removed from DPDK 18.11. Replace
> them with rte_dev_probe/remove.
> 

I have submitted a patch on the same issue, see [1]. 
Please suggest how to unify our patches.

> Signed-off-by: Kevin Traynor 
> ---
>  lib/netdev-dpdk.c | 29 +
>  1 file changed, 17 insertions(+), 12 deletions(-)
> 
> diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c index
> 10c4879a1..190d50007 100644
> --- a/lib/netdev-dpdk.c
> +++ b/lib/netdev-dpdk.c
> @@ -1351,5 +1351,5 @@ netdev_dpdk_destruct(struct netdev *netdev)  {
>  struct netdev_dpdk *dev = netdev_dpdk_cast(netdev);
> -char devname[RTE_ETH_NAME_MAX_LEN];
> +struct rte_eth_dev_info dev_info;
> 
>  ovs_mutex_lock(_mutex);
> @@ -1360,8 +1360,9 @@ netdev_dpdk_destruct(struct netdev *netdev)
>  if (dev->attached) {
>  rte_eth_dev_close(dev->port_id);
> -if (rte_eth_dev_detach(dev->port_id, devname) < 0) {
> +rte_eth_dev_info_get(dev->port_id, _info);

I suggest having a direct access to the device (rather than accessing dev_info).
rte_eth_devices[dev->port_id].device;

> +if (dev_info.device && !rte_dev_remove(dev_info.device)) {

With dpdk 18.11 an rte device can be used by multiple eth devices (one to many 
relationship).
Remark: in OVS terms an eth device is a dpdk port_id.
When calling rte_dev_remove() all the eth devices are closed and the PCI device 
is detached. 
We need to count the number of eth devices used by the rte device. Only when 
closing the last eth device 
shoud we call rte_dev_remove (it is like a reference count algorithm).
For example: if we add to OVS 2 ports belonging the same rte device (e.g. the 
same PCI bus address) then after deleting one of the ports we should not 
implicitly delete the other port. 
This case is handled in [1]

> +VLOG_INFO("Device '%s' has been detached", dev->devargs);
> +} else {
>  VLOG_ERR("Device '%s' can not be detached", dev->devargs);
> -} else {
> -VLOG_INFO("Device '%s' has been detached", devname);
>  }
>  }
> @@ -1645,5 +1646,5 @@ netdev_dpdk_process_devargs(struct
> netdev_dpdk *dev,
>  char *name;
>  dpdk_port_t new_port_id = DPDK_ETH_PORT_ID_INVALID;
> -
> +struct rte_dev_iterator iterator;
>  if (strncmp(devargs, "class=eth,mac=", 14) == 0) {
>  new_port_id = netdev_dpdk_get_port_by_mac([14]);
> @@ -1653,8 +1654,12 @@ netdev_dpdk_process_devargs(struct
> netdev_dpdk *dev,
>  || !rte_eth_dev_is_valid_port(new_port_id)) {
>  /* Device not found in DPDK, attempt to attach it */
> -if (!rte_eth_dev_attach(devargs, _port_id)) {
> +if (!rte_dev_probe(devargs)) {
>  /* Attach successful */
>  dev->attached = true;
>  VLOG_INFO("Device '%s' attached to DPDK", devargs);
> +RTE_ETH_FOREACH_MATCHING_DEV(new_port_id, devargs,
> ) {
> +rte_eth_iterator_cleanup();

+1
Good point which I missed! 
Indeed we should free resources by calling the rte_eth_iterator_cleanup().

> +break;
> +}
>  } else {

It seems with this patch the code still has the call: 
rte_eth_dev_get_port_by_name(). 
This call is no more relevant when using representors. Previously a PCI address 
(e.g. :08.00:0) was used in devargs.
With dpdk 18.11 a device devargs became a regular expression string, (e.g. 
:08.00:0,representor=[1]) which is different than the device name assigned 
by the PMD.
In other words: previously devargs and device name where identical. Starting 
from dpdk 18.11 they are not.
This case is handled in [1].

>  /* Attach unsuccessful */ @@ -3206,6 +3211,6 @@
> netdev_dpdk_detach(struct unixctl_conn *conn, int argc OVS_UNUSED,
>  char *response;
>  dpdk_port_t port_id;
> -char devname[RTE_ETH_NAME_MAX_LEN];
>  struct netdev_dpdk *dev;
> +struct rte_eth_dev_info dev_info;
> 
>  ovs_mutex_lock(_mutex);
> @@ -3226,9 +3231,9 @@ netdev_dpdk_detach(struct unixctl_conn *conn,
> int argc OVS_UNUSED,
>  rte_eth_dev_close(port_id);
> 
> -ret = rte_eth_dev_detach(port_id, devname);
> -if (ret < 0) {
> -response = xasprintf("Device '%s' can not be detached", argv[1]);
> -goto error;
> -}
> +rte_eth_dev_info_get(port_id, _info);
> +if (!dev_info.device || rte_dev_remove(dev_info.device)) {
> +response = xasprintf("Device '%s' can not be detached", argv[1]);
> +goto error;
> +}
> 

Re: [ovs-dev] [PATCH] Tests: Fix testing bridge - add port after stopping controller on Windows

[Ben Pfaff]

That makes sense.  I wish Unix had a delete-on-close flag, it would save
a lot of trouble sometimes.

On Thu, Nov 15, 2018 at 04:22:59PM +, Alin Serdean wrote:
> Thanks for the suggestion Ben.
> 
> I was thinking about changing the regular open to a CreateFile on
> Windows with the flag:
> `
> FILE_FLAG_DELETE_ON_CLOSE
> 0x0400
> 
> The file is to be deleted immediately after all of its handles are closed,
> which includes the specified handle and any other open or
> duplicated handles.
> 
> If there are existing open handles to a file, the call fails unless
> they were all opened with the FILE_SHARE_DELETE share mode.
> 
> Subsequent open requests for the file fail, unless the
> FILE_SHARE_DELETE share mode is specified.`
> 
> https://docs.microsoft.com/en-us/windows/desktop/api/FileAPI/nf-fileapi-createfilea
> 
> But both can work.
> 
> > -Mesaj original-
> > De la: ovs-dev-boun...@openvswitch.org  > boun...@openvswitch.org> În numele Ben Pfaff
> > Trimis: Thursday, November 15, 2018 6:11 PM
> > Către: aserd...@ovn.org
> > Cc: d...@openvswitch.org
> > Subiect: Re: [ovs-dev] [PATCH] Tests: Fix testing bridge - add port after
> > stopping controller on Windows
> > 
> > On Thu, Nov 15, 2018 at 03:23:28PM +0200, aserd...@ovn.org wrote:
> > > I have opened an issue for it:
> > > https://github.com/openvswitch/ovs-issues/issues/165
> > >
> > > It's not test specific unfortunately. The file is put up for unlink on
> > > exit, but I'm guessing someone still has an opened handle at that point.
> > >
> > > I'm applying this patch for the moment and following up with the
> > > actual fix for the userspace.
> > 
> > Unix has similar-sounding issues with dangling Unix domain sockets.  On
> > Unix, the customary way to solve it is to delete an existing socket before
> > trying to create one with the same name.  You can see that in
> > make_unix_socket() in socket-util-unix.c:
> > 
> > if (bind_path) {
> > char linkname[MAX_UN_LEN + 1];
> > struct sockaddr_un un;
> > socklen_t un_len;
> > int dirfd;
> > 
> > if (unlink(bind_path) && errno != ENOENT) {
> > VLOG_WARN("unlinking \"%s\": %s\n",
> >   bind_path, ovs_strerror(errno));
> > }
> > fatal_signal_add_file_to_unlink(bind_path);
> > 
> > If that approach is appropriate under Windows as well, it might be
> > implemented something like this:
> > diff --git a/lib/stream-windows.c b/lib/stream-windows.c index
> > 34bc610b6f49..b027e48b4f8d 100644
> > --- a/lib/stream-windows.c
> > +++ b/lib/stream-windows.c
> > @@ -616,6 +616,11 @@ pwindows_open(const char *name OVS_UNUSED,
> > char *suffix,
> >  path = xstrdup(suffix);
> >  }
> > 
> > +/* Remove any existing named pipe. */
> > +if (remove(bind_path) && errno != ENOENT) {
> > +VLOG_WARN("removing \"%s\": %s\n", bind_path,
> > ovs_strerror(errno));
> > +}
> > +
> >  /* Try to create a file under the path location. */
> >  FILE *file = fopen(path, "w");
> >  if (!file) {
> > ___
> > dev mailing list
> > d...@openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [RFC v2 dpdk-latest 1/2] netdev-dpdk: Update for DPDK CRC strip flags change.

[Ophir Munk]

> -Original Message-
> From: Stokes, Ian [mailto:ian.sto...@intel.com]
> Sent: Wednesday, November 14, 2018 3:16 PM
> To: Kevin Traynor ; d...@openvswitch.org; Ophir
> Munk ; i.maxim...@samsung.com
> Cc: Christian Ehrhardt 
> Subject: RE: [RFC v2 dpdk-latest 1/2] netdev-dpdk: Update for DPDK CRC
> strip flags change.
> 
> > -if (dev->hw_ol_features & NETDEV_RX_HW_CRC_STRIP) {
> > -conf.rxmode.offloads |= DEV_RX_OFFLOAD_CRC_STRIP;
> > +if (!(dev->hw_ol_features & NETDEV_RX_HW_CRC_STRIP)) {
> > +conf.rxmode.offloads |= DEV_RX_OFFLOAD_KEEP_CRC;
> >  }
> 
> Hi Kevin,
> 
> Thanks for this series. Technically the behavior from OVS does change here
> as previously if NETDEV_RX_HW_CRC_STRIP wasn't supported we wouldn't
> set DEV_RX_OFFLOAD_KEEP_CRC. For vdevs it could be the case that this
> isn't supported.
> 
> I spotted this testing the net_null pmd, it now fails to init. It's a corner 
> case
> for sure but probably should be checked that support is there before
> explicitly setting it.
> 

This case is handled in https://patchwork.ozlabs.org/patch/997879/

> Thanks
> Ian

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] odp-util: Add checking to prevent buffer overflow when parsing push_nsh

[Ben Pfaff]

On Tue, Nov 13, 2018 at 11:25:24AM -0800, Yifeng Sun wrote:
> Previously, the buffer size of 'struct ofpbuf b' is less than the
> size of 'char buf[512]', this could cause memory overflow of ofpbuf
> when calling ofpbuf_put_hex. This patch fixes it.
> 
> Reported-at: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10865
> Signed-off-by: Yifeng Sun 

Thanks, applied and backported.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] oss-fuzz: Fix memory leak in ofctl_parse_flow

[Ben Pfaff]

On Wed, Nov 14, 2018 at 03:14:05PM -0800, Yifeng Sun wrote:
> If parse_ofp_flow_mod_str returns no error, ofputil_flow_mod.match
> contains allocated memory that should be free. This patch fixes it.
> 
> Reported-at: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11343
> Signed-off-by: Yifeng Sun 

Thanks, applied to master.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] configure: Check for more specific function to pull in pthread library.

[Ben Pfaff]

On my laptop, pthread_create() is always available without -lpthread, but
when I use -fsanitize=address, -lpthread is required to pull in other
threading functions such as pthread_rwlock_tryrdlock().  Thus, with
-fsanitize=address I have to manually add -lpthread to link commands one
way or another.  This commit avoids that problem by checking for a
function that is sometimes only available in -lpthread.

Signed-off-by: Ben Pfaff 
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index bb726f89e251..3e97a750c812 100644
--- a/configure.ac
+++ b/configure.ac
@@ -77,7 +77,7 @@ AC_SUBST([LT_AGE])
 AC_SEARCH_LIBS([pow], [m])
 AC_SEARCH_LIBS([clock_gettime], [rt])
 AC_SEARCH_LIBS([timer_create], [rt])
-AC_SEARCH_LIBS([pthread_create], [pthread])
+AC_SEARCH_LIBS([pthread_rwlock_tryrdlock], [pthread])
 AC_FUNC_STRERROR_R
 
 OVS_CHECK_ESX
-- 
2.16.1

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] pcap-file: Add support for Linux SLL formatted PCAP files.

[Ben Pfaff]

Thanks, applied to master.

On Mon, Nov 12, 2018 at 11:09:37AM -0800, Yifeng Sun wrote:
> Looks good to me, thanks.
> 
> Reviewed-by: Yifeng Sun 
> 
> On Sun, Nov 11, 2018 at 3:41 PM Ben Pfaff  wrote:
> 
> > Someone sent me one of these and OVS couldn't read it.  This fixes the
> > problem.
> >
> > Signed-off-by: Ben Pfaff 
> > ---
> >  lib/pcap-file.c | 54
> > ++
> >  1 file changed, 54 insertions(+)
> >
> > diff --git a/lib/pcap-file.c b/lib/pcap-file.c
> > index 81a094c2a01f..0f34c5e83cda 100644
> > --- a/lib/pcap-file.c
> > +++ b/lib/pcap-file.c
> > @@ -39,9 +39,15 @@ enum ts_resolution {
> >  PCAP_NSEC,
> >  };
> >
> > +enum network_type {
> > +PCAP_ETHERNET = 0,
> > +PCAP_LINUX_SLL = 0x71
> > +};
> > +
> >  struct pcap_file {
> >  FILE *file;
> >  enum ts_resolution resolution;
> > +enum network_type network;
> >  };
> >
> >  struct pcap_hdr {
> > @@ -130,10 +136,13 @@ ovs_pcap_read_header(struct pcap_file *p_file)
> >  VLOG_WARN("failed to read pcap header: %s",
> > ovs_retval_to_string(error));
> >  return error;
> >  }
> > +bool byte_swap;
> >  if (ph.magic_number == 0xa1b2c3d4 || ph.magic_number == 0xd4c3b2a1) {
> > +byte_swap = ph.magic_number == 0xd4c3b2a1;
> >  p_file->resolution = PCAP_USEC;
> >  } else if (ph.magic_number == 0xa1b23c4d ||
> > ph.magic_number == 0x4d3cb2a1) {
> > +byte_swap = ph.magic_number == 0x4d3cb2a1;
> >  p_file->resolution = PCAP_NSEC;
> >  } else {
> >  VLOG_WARN("bad magic 0x%08"PRIx32" reading pcap file "
> > @@ -141,6 +150,13 @@ ovs_pcap_read_header(struct pcap_file *p_file)
> >"or 0x4d3cb2a1)", ph.magic_number);
> >  return EPROTO;
> >  }
> > +p_file->network = byte_swap ? uint32_byteswap(ph.network) :
> > ph.network;
> > +if (p_file->network != PCAP_ETHERNET &&
> > +p_file->network != PCAP_LINUX_SLL) {
> > +VLOG_WARN("unknown network type %"PRIu16" reading pcap file",
> > +  p_file->network);
> > +return EPROTO;
> > +}
> >  return 0;
> >  }
> >
> > @@ -218,6 +234,44 @@ ovs_pcap_read(struct pcap_file *p_file, struct
> > dp_packet **bufp,
> >  dp_packet_delete(buf);
> >  return error;
> >  }
> > +
> > +if (p_file->network == PCAP_LINUX_SLL) {
> > +/* This format doesn't include the destination Ethernet address,
> > which
> > + * is weird. */
> > +
> > +struct sll_header {
> > +ovs_be16 packet_type;
> > +ovs_be16 arp_hrd;
> > +ovs_be16 lla_len;
> > +struct eth_addr dl_src;
> > +ovs_be16 reserved;
> > +ovs_be16 protocol;
> > +};
> > +const struct sll_header *sll;
> > +if (len < sizeof *sll) {
> > +VLOG_WARN("pcap packet too short for SLL header");
> > +dp_packet_delete(buf);
> > +return EPROTO;
> > +}
> > +
> > +/* Pull Linux SLL header. */
> > +sll = dp_packet_pull(buf, sizeof *sll);
> > +if (sll->lla_len != htons(6)) {
> > +ovs_hex_dump(stdout, sll, sizeof *sll, 0, false);
> > +VLOG_WARN("bad SLL header");
> > +dp_packet_delete(buf);
> > +return EPROTO;
> > +}
> > +
> > +/* Push Ethernet header. */
> > +struct eth_header eth = {
> > +/* eth_dst is all zeros because the format doesn't include
> > it. */
> > +.eth_src = sll->dl_src,
> > +.eth_type = sll->protocol,
> > +};
> > +dp_packet_push(buf, , sizeof eth);
> > +}
> > +
> >  *bufp = buf;
> >  return 0;
> >  }
> > --
> > 2.16.1
> >
> > ___
> > dev mailing list
> > d...@openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
> >
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] docs: Fix cross-references that referred to discussions that have moved.

[Ben Pfaff]

Thanks, applied to master.

On Mon, Nov 12, 2018 at 09:58:19AM -0800, Yifeng Sun wrote:
> Looks good to me, thanks.
> 
> Reviewed-by: Yifeng Sun 
> 
> On Thu, Nov 8, 2018 at 9:39 PM Ben Pfaff  wrote:
> 
> > Signed-off-by: Ben Pfaff 
> > ---
> >  include/openvswitch/meta-flow.h |  4 ++--
> >  ovn/utilities/ovn-sbctl.8.in|  2 +-
> >  ovn/utilities/ovn-trace.8.xml   |  2 +-
> >  vswitchd/vswitch.xml| 10 +-
> >  4 files changed, 9 insertions(+), 9 deletions(-)
> >
> > diff --git a/include/openvswitch/meta-flow.h
> > b/include/openvswitch/meta-flow.h
> > index 152f512db3e8..ffd89452c36c 100644
> > --- a/include/openvswitch/meta-flow.h
> > +++ b/include/openvswitch/meta-flow.h
> > @@ -136,7 +136,7 @@ struct ofputil_tlv_table_mod;
> >   *   tunnel flags: Any number of the strings "df", "csum", "key", or
> >   * "oam" separated by "|".
> >   *
> > - *   TCP flags: See the description of tcp_flags in ovs-ofctl(8).
> > + *   TCP flags: See the description of tcp_flags in ovs-fields(7).
> >   *
> >   *   packet type: A pair of packet type namespace NS and NS_TYPE
> > within
> >   *   that namespace "(NS,NS_TYPE)". NS and NS_TYPE are formatted in
> > @@ -274,7 +274,7 @@ enum OVS_PACKED_ENUM mf_field_id {
> >
> >  /* "conj_id".
> >   *
> > - * ID for "conjunction" actions.  Please refer to ovs-ofctl(8)
> > + * ID for "conjunction" actions.  Please refer to ovs-fields(7)
> >   * documentation of "conjunction" for details.
> >   *
> >   * Type: be32.
> > diff --git a/ovn/utilities/ovn-sbctl.8.in b/ovn/utilities/ovn-sbctl.8.in
> > index 659b44d70be4..2aaa457e826b 100644
> > --- a/ovn/utilities/ovn-sbctl.8.in
> > +++ b/ovn/utilities/ovn-sbctl.8.in
> > @@ -182,7 +182,7 @@ display the OpenFlow flows that correspond to each OVN
> > logical flow.
> >  To do so, \fBovn\-sbctl\fR connects to \fIremote\fR (by default,
> >  \fBunix:@RUNDIR@/br-int.mgmt\fR) over OpenFlow and retrieves the
> >  flows.  If \fIremote\fR is specified, it must be an active OpenFlow
> > -connection method described in \fBovs\-ofctl\fR(8).  Please see the
> > +connection method described in \fBovsdb\fR(7).  Please see the
> >  discussion of the similar \fB\-\-ovs\fR option in \fBovn-trace\fR(8)
> >  for more information about the OpenFlow flow output.
> >  .IP
> > diff --git a/ovn/utilities/ovn-trace.8.xml b/ovn/utilities/ovn-trace.8.xml
> > index d5e493e0eaed..01e74111901b 100644
> > --- a/ovn/utilities/ovn-trace.8.xml
> > +++ b/ovn/utilities/ovn-trace.8.xml
> > @@ -330,7 +330,7 @@
> >  ovn-trace connects to remote (by default,
> >  unix:@RUNDIR@/br-int.mgmt) over OpenFlow and
> > retrieves the
> >  flows.  If remote is specified, it must be an active
> > -OpenFlow connection method described in ovs-ofctl(8).
> > +OpenFlow connection method described in ovsdb(7).
> >
> >
> >
> > diff --git a/vswitchd/vswitch.xml b/vswitchd/vswitch.xml
> > index efa1ef85e65e..170e843f1280 100644
> > --- a/vswitchd/vswitch.xml
> > +++ b/vswitchd/vswitch.xml
> > @@ -2519,9 +2519,9 @@
> >
> >  The word flow.  The tunnel accepts packets with
> > any
> >  key.  The key will be placed in the tun_id field
> > for
> > -matching in the flow table.  The ovs-ofctl
> > manual page
> > -contains additional information about matching fields in
> > OpenFlow
> > -flows.
> > +matching in the flow table.  The ovs-fields(7)
> > manual
> > +page contains additional information about matching fields in
> > +OpenFlow flows.
> >
> >  
> >
> > @@ -2547,8 +2547,8 @@
> >  The word flow.  Packets sent through the tunnel
> > will
> >  have the key set using the set_tunnel Nicira
> > OpenFlow
> >  vendor extension (0 is used in the absence of an action).  The
> > -ovs-ofctl manual page contains additional
> > information
> > -about the Nicira OpenFlow vendor extensions.
> > +ovs-fields(7) manual page contains additional
> > +information about the Nicira OpenFlow vendor extensions.
> >
> >  
> >
> > --
> > 2.16.1
> >
> > ___
> > dev mailing list
> > d...@openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
> >
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] Tests: Fix testing bridge - add port after stopping controller on Windows

[Alin Serdean]

Thanks for the suggestion Ben.

I was thinking about changing the regular open to a CreateFile on
Windows with the flag:
`
FILE_FLAG_DELETE_ON_CLOSE
0x0400

The file is to be deleted immediately after all of its handles are closed,
which includes the specified handle and any other open or
duplicated handles.

If there are existing open handles to a file, the call fails unless
they were all opened with the FILE_SHARE_DELETE share mode.

Subsequent open requests for the file fail, unless the
FILE_SHARE_DELETE share mode is specified.`

https://docs.microsoft.com/en-us/windows/desktop/api/FileAPI/nf-fileapi-createfilea

But both can work.

> -Mesaj original-
> De la: ovs-dev-boun...@openvswitch.org  boun...@openvswitch.org> În numele Ben Pfaff
> Trimis: Thursday, November 15, 2018 6:11 PM
> Către: aserd...@ovn.org
> Cc: d...@openvswitch.org
> Subiect: Re: [ovs-dev] [PATCH] Tests: Fix testing bridge - add port after
> stopping controller on Windows
> 
> On Thu, Nov 15, 2018 at 03:23:28PM +0200, aserd...@ovn.org wrote:
> > I have opened an issue for it:
> > https://github.com/openvswitch/ovs-issues/issues/165
> >
> > It's not test specific unfortunately. The file is put up for unlink on
> > exit, but I'm guessing someone still has an opened handle at that point.
> >
> > I'm applying this patch for the moment and following up with the
> > actual fix for the userspace.
> 
> Unix has similar-sounding issues with dangling Unix domain sockets.  On
> Unix, the customary way to solve it is to delete an existing socket before
> trying to create one with the same name.  You can see that in
> make_unix_socket() in socket-util-unix.c:
> 
> if (bind_path) {
> char linkname[MAX_UN_LEN + 1];
> struct sockaddr_un un;
> socklen_t un_len;
> int dirfd;
> 
> if (unlink(bind_path) && errno != ENOENT) {
> VLOG_WARN("unlinking \"%s\": %s\n",
>   bind_path, ovs_strerror(errno));
> }
> fatal_signal_add_file_to_unlink(bind_path);
> 
> If that approach is appropriate under Windows as well, it might be
> implemented something like this:
> diff --git a/lib/stream-windows.c b/lib/stream-windows.c index
> 34bc610b6f49..b027e48b4f8d 100644
> --- a/lib/stream-windows.c
> +++ b/lib/stream-windows.c
> @@ -616,6 +616,11 @@ pwindows_open(const char *name OVS_UNUSED,
> char *suffix,
>  path = xstrdup(suffix);
>  }
> 
> +/* Remove any existing named pipe. */
> +if (remove(bind_path) && errno != ENOENT) {
> +VLOG_WARN("removing \"%s\": %s\n", bind_path,
> ovs_strerror(errno));
> +}
> +
>  /* Try to create a file under the path location. */
>  FILE *file = fopen(path, "w");
>  if (!file) {
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] Tests: Fix testing bridge - add port after stopping controller on Windows

[Ben Pfaff]

On Thu, Nov 15, 2018 at 03:23:28PM +0200, aserd...@ovn.org wrote:
> I have opened an issue for it: 
> https://github.com/openvswitch/ovs-issues/issues/165
> 
> It's not test specific unfortunately. The file is put up for unlink on exit, 
> but I'm guessing
> someone still has an opened handle at that point.
> 
> I'm applying this patch for the moment and following up with the actual fix 
> for the
> userspace.

Unix has similar-sounding issues with dangling Unix domain sockets.  On
Unix, the customary way to solve it is to delete an existing socket
before trying to create one with the same name.  You can see that in
make_unix_socket() in socket-util-unix.c:

if (bind_path) {
char linkname[MAX_UN_LEN + 1];
struct sockaddr_un un;
socklen_t un_len;
int dirfd;

if (unlink(bind_path) && errno != ENOENT) {
VLOG_WARN("unlinking \"%s\": %s\n",
  bind_path, ovs_strerror(errno));
}
fatal_signal_add_file_to_unlink(bind_path);

If that approach is appropriate under Windows as well, it might be
implemented something like this:
diff --git a/lib/stream-windows.c b/lib/stream-windows.c
index 34bc610b6f49..b027e48b4f8d 100644
--- a/lib/stream-windows.c
+++ b/lib/stream-windows.c
@@ -616,6 +616,11 @@ pwindows_open(const char *name OVS_UNUSED, char *suffix,
 path = xstrdup(suffix);
 }
 
+/* Remove any existing named pipe. */
+if (remove(bind_path) && errno != ENOENT) {
+VLOG_WARN("removing \"%s\": %s\n", bind_path, ovs_strerror(errno));
+}
+
 /* Try to create a file under the path location. */
 FILE *file = fopen(path, "w");
 if (!file) {
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] datapath-windows: Fix invalid reference in Buffermgmt.c

[aserdean]

Thanks for the fix!

Acked-by: Alin Gabriel Serdean 

> -Mesaj original-
> De la: ovs-dev-boun...@openvswitch.org  boun...@openvswitch.org> În numele Sairam Venugopal
> Trimis: Wednesday, November 14, 2018 10:07 PM
> Către: d...@openvswitch.org
> Subiect: [ovs-dev] [PATCH] datapath-windows: Fix invalid reference in
> Buffermgmt.c
> 
> OVS_BUFFER_CONTEXT gets cleared as part of
> NdisFreeNetBufferListContext function call. This causes an invalid
reference
> error.
> 
> Found while testing with driver verifier enabled.
> 
> Signed-off-by: Sairam Venugopal 
> ---
>  datapath-windows/ovsext/BufferMgmt.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/datapath-windows/ovsext/BufferMgmt.c b/datapath-
> windows/ovsext/BufferMgmt.c
> index 448cd76..da5c04a 100644
> --- a/datapath-windows/ovsext/BufferMgmt.c
> +++ b/datapath-windows/ovsext/BufferMgmt.c

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] datapath-windows: Fix invalid reference in Buffermgmt.c

[Alin Serdean]

I applied the patch on master and as far as it goes without conflicts.

--
Alin.

> -Mesaj original-
> De la: ovs-dev-boun...@openvswitch.org  boun...@openvswitch.org> În numele aserd...@ovn.org
> Trimis: Thursday, November 15, 2018 4:52 PM
> Către: 'Sairam Venugopal' ; d...@openvswitch.org
> Subiect: Re: [ovs-dev] [PATCH] datapath-windows: Fix invalid reference in
> Buffermgmt.c
> 
> Thanks for the fix!
> 
> Acked-by: Alin Gabriel Serdean 
> 
> > -Mesaj original-
> > De la: ovs-dev-boun...@openvswitch.org  > boun...@openvswitch.org> În numele Sairam Venugopal
> > Trimis: Wednesday, November 14, 2018 10:07 PM
> > Către: d...@openvswitch.org
> > Subiect: [ovs-dev] [PATCH] datapath-windows: Fix invalid reference in
> > Buffermgmt.c
> >
> > OVS_BUFFER_CONTEXT gets cleared as part of
> > NdisFreeNetBufferListContext function call. This causes an invalid
> reference
> > error.
> >
> > Found while testing with driver verifier enabled.
> >
> > Signed-off-by: Sairam Venugopal 
> > ---
> >  datapath-windows/ovsext/BufferMgmt.c | 6 --
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/datapath-windows/ovsext/BufferMgmt.c b/datapath-
> > windows/ovsext/BufferMgmt.c index 448cd76..da5c04a 100644
> > --- a/datapath-windows/ovsext/BufferMgmt.c
> > +++ b/datapath-windows/ovsext/BufferMgmt.c
> 
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] OVS-DPDK public meeting

[Eelco Chaudron]

On 15 Nov 2018, at 15:18, Kevin Traynor wrote:


Next meeting 12th December
(May cancel if no agenda items as DPDK/OVS confs the previous week)

Minutes for 14th November.
Attendees: Pieter, Asaf, Timothy, Ophir, Ian, Thomas, David, Matteo,
Johann, Aaron, Tiago, Kevin.

===
GENERAL
===
- Ian is one of the core committers :-)
-- He will still use his private branch for validation
-- Patches will be applied directly into main tree
-- i.e. no more pull requests


PERFORMANCE/FEATURES

- DPDK 18.08/18.11 update (Kevin)
-- sent patches for update to 18.11
-- Ian found an issue with CRC strip, to be fixed
-- Ophir also sent a patch prior to meeting
-- Thomas M, explained some of the new features of hotplug
-- Discussed integration of changes and if it should be broken up 
into:

-- 1. Minimal update to use 18.11
-- 2. Extend OVS to take advantage of new features in 18.11
-- Discussion to be continued on ML

- CI lab (Ophir/Aaron/Ian)
-- Not much changed
-- Testing done in VM
-- Mlx to check about Hw for Aaron

- 17.11.4 (Eelco/Aaron)
-- Slow start up issue reported because of some patches in 17.11.4
-- Alejandro sent patch for DPDK 17.11 branch
-- https://mails.dpdk.org/archives/dev/2018-November/118770.html
-- Eelco will add some more details


This issue got introduced due to commit 293c0c4b9. This change will try 
to map the huge page memory we need starting at 0x1. If it fails 
the hint, it will retry increasing the address, until it gets the 
mapping at the requested address. This to minimise the chance to map it 
outside the HWs DMA address space.


However just before doing this DPDK also mmaps each individual huge page 
in the system. It starts low, but it will collide with the 0x1 
address.


When this happens there a quite some retries until we find the mmaps we 
want. So the more memory in huge pages, the more time it takes. It 
depends on the number of huge pages in the system, not the memory 
configured for OVS.


FYI this mapping on a 32G huge page system:
4000-8000 rw-s  00:23 206083 
/dev/hugepages/rtemap_1
8000-c000 rw-s  00:23 206084 
/dev/hugepages/rtemap_2
c000-1 rw-s  00:23 206085
/dev/hugepages/rtemap_3
1-14000 rw-s  00:23 206086   
/dev/hugepages/rtemap_4
14000-18000 rw-s  00:23 206087   
/dev/hugepages/rtemap_5
18000-1c000 rw-s  00:23 206088   
/dev/hugepages/rtemap_6
1c000-2 rw-s  00:23 206089   
/dev/hugepages/rtemap_7
2-24000 rw-s  00:23 206090   
/dev/hugepages/rtemap_8
24000-28000 rw-s  00:23 206091   
/dev/hugepages/rtemap_9
28000-2c000 rw-s  00:23 206092   
/dev/hugepages/rtemap_10
2c000-3 rw-s  00:23 206093   
/dev/hugepages/rtemap_11
3-34000 rw-s  00:23 206094   
/dev/hugepages/rtemap_12
34000-38000 rw-s  00:23 206095   
/dev/hugepages/rtemap_13
38000-3c000 rw-s  00:23 206096   
/dev/hugepages/rtemap_14
3c000-4 rw-s  00:23 206097   
/dev/hugepages/rtemap_15
4-44000 rw-s  00:23 206098   
/dev/hugepages/rtemap_16
44000-48000 rw-s  00:23 206099   
/dev/hugepages/rtemap_17
48000-4c000 rw-s  00:23 206100   
/dev/hugepages/rtemap_18
4c000-5 rw-s  00:23 206101   
/dev/hugepages/rtemap_19
5-54000 rw-s  00:23 206102   
/dev/hugepages/rtemap_20
54000-58000 rw-s  00:23 206103   
/dev/hugepages/rtemap_21
58000-5c000 rw-s  00:23 206104   
/dev/hugepages/rtemap_22
5c000-6 rw-s  00:23 206105   
/dev/hugepages/rtemap_23
6-64000 rw-s  00:23 206106   
/dev/hugepages/rtemap_24
64000-68000 rw-s  00:23 206107   
/dev/hugepages/rtemap_25
68000-6c000 rw-s  00:23 206108   
/dev/hugepages/rtemap_26
6c000-7 rw-s  00:23 206109   
/dev/hugepages/rtemap_27
7-74000 rw-s  00:23 206110   
/dev/hugepages/rtemap_28
74000-78000 rw-s  00:23 206111   
/dev/hugepages/rtemap_29
78000-7c000 rw-s  00:23 206112

Re: [ovs-dev] OVS-DPDK public meeting

[Kevin Traynor]

Next meeting 12th December
(May cancel if no agenda items as DPDK/OVS confs the previous week)

Minutes for 14th November.
Attendees: Pieter, Asaf, Timothy, Ophir, Ian, Thomas, David, Matteo,
Johann, Aaron, Tiago, Kevin.

===
GENERAL
===
- Ian is one of the core committers :-)
-- He will still use his private branch for validation
-- Patches will be applied directly into main tree
-- i.e. no more pull requests


PERFORMANCE/FEATURES

- DPDK 18.08/18.11 update (Kevin)
-- sent patches for update to 18.11
-- Ian found an issue with CRC strip, to be fixed
-- Ophir also sent a patch prior to meeting
-- Thomas M, explained some of the new features of hotplug
-- Discussed integration of changes and if it should be broken up into:
-- 1. Minimal update to use 18.11
-- 2. Extend OVS to take advantage of new features in 18.11
-- Discussion to be continued on ML

- CI lab (Ophir/Aaron/Ian)
-- Not much changed
-- Testing done in VM
-- Mlx to check about Hw for Aaron

- 17.11.4 (Eelco/Aaron)
-- Slow start up issue reported because of some patches in 17.11.4
-- Alejandro sent patch for DPDK 17.11 branch
-- https://mails.dpdk.org/archives/dev/2018-November/118770.html
-- Eelco will add some more details

On 07/25/2017 02:25 PM, Kevin Traynor wrote:
> Hi All,
> 
> The OVS-DPDK public meetings have moved to Wednesday's at the same time.
> Everyone is welcome, it's a chance to share status/plans etc.
> 
> It's scheduled for every 2 weeks starting 26th July. Meeting time is
> currently @ 4pm UTC.
> 
> You can connect through Bluejeans or through dial in:
> 
> https://bluejeans.com/139318596
> 
> US: +1.408.740.7256 
> UK: +44.203.608.5256 
> Germany: +49.32.221.091256 
> Ireland: +353.1.697.1256 
> Other numbers at https://www.bluejeans.com/numbers
> Meeting ID: 139318596
> 
> thanks,
> Kevin.
> 

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] coding-style: Remove redundant symbols from the examples.

[Ben Pfaff]

On Thu, Nov 15, 2018 at 02:55:35PM +0300, Ilya Maximets wrote:
> Some backslashes was added while converting from .md to .rst.
> These symbols are printable in both pdf and html docs and
> should be removed.
> 
> CC: Stephen Finucane 
> Fixes: d124a408a4bc ("doc: Convert CodingStyle to rST")
> Signed-off-by: Ilya Maximets 

Thanks, applied to master.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] ofp-actions: Make all actions a multiple of OFPACT_ALIGNTO bytes.

[Ben Pfaff]

On Thu, Nov 15, 2018 at 02:10:23AM -0500, 0-day Robot wrote:
> Bleep bloop.  Greetings Ben Pfaff, I am a robot and I have tried out your 
> patch.
> Thanks for your contribution.
> 
> I encountered some error that I wasn't expecting.  See the details below.
> 
> 
> build:
>  BUILD_ASSERT_DECL(offsetof(struct STRUCT, MEMBER)   \
>  ^
> ./include/openvswitch/ofp-actions.h:69:5: note: in expansion of macro 'OFPACT'
>  OFPACT(BUNDLE,  ofpact_bundle,  slaves, "bundle")   \
>  ^
> ./include/openvswitch/ofp-actions.h:1279:1: note: in expansion of macro 
> 'OFPACTS'
>  OFPACTS
>  ^
> ./include/openvswitch/compiler.h:255:33: error: static assertion failed: 
> "!offsetof(struct ofpact_bundle, slaves) || (offsetof(struct ofpact_bundle, 
> slaves) == sizeof(struct ofpact_bundle))"
>  #define BUILD_ASSERT_DECL(EXPR) _Static_assert(EXPR, #EXPR)

Oops, here's an incremental fix for 64-bit architectures:

diff --git a/include/openvswitch/ofp-actions.h 
b/include/openvswitch/ofp-actions.h
index bdd3b28de886..4daf5ad071da 100644
--- a/include/openvswitch/ofp-actions.h
+++ b/include/openvswitch/ofp-actions.h
@@ -395,8 +395,8 @@ struct ofpact_bundle {
 
 /* Slaves for output. */
 unsigned int n_slaves;
-ofp_port_t slaves[];
 );
+ofp_port_t slaves[];
 };
 
 /* OFPACT_SET_VLAN_VID.

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] Tests: Fix testing bridge - add port after stopping controller on Windows

[aserdean]

Applied on master, branch-2.10, branch-2.9.

--
Alin.

> -Mesaj original-
> De la: ovs-dev-boun...@openvswitch.org  boun...@openvswitch.org> În numele aserd...@ovn.org
> Trimis: Thursday, November 15, 2018 3:23 PM
> Către: 'Sairam Venugopal' ; 'Alin Gabriel Serdean'
> ; d...@openvswitch.org
> Subiect: Re: [ovs-dev] [PATCH] Tests: Fix testing bridge - add port after
> stopping controller on Windows
> 
> I have opened an issue for it: https://github.com/openvswitch/ovs-
> issues/issues/165
> 
> It's not test specific unfortunately. The file is put up for unlink on exit, 
> but I'm
> guessing someone still has an opened handle at that point.
> 
> I'm applying this patch for the moment and following up with the actual fix
> for the userspace.
> 
> Thanks for the ack.
> 
> Alin.
> 
> > -Mesaj original-
> > De la: ovs-dev-boun...@openvswitch.org  > boun...@openvswitch.org> În numele Sairam Venugopal
> > Trimis: Wednesday, November 14, 2018 10:19 PM
> > Către: Alin Gabriel Serdean ; d...@openvswitch.org
> > Subiect: Re: [ovs-dev] [PATCH] Tests: Fix testing bridge - add port
> > after stopping controller on Windows
> >
> > Thanks for fixing this. The files normally get deleted when the agent
> > closes. Is this a regression or just test related? Ack'ing the fix.
> >
> > Acked-by: Sairam Venugopal 
> >
> > On 11/14/18, 7:31 AM, "ovs-dev-boun...@openvswitch.org on behalf of
> > Alin Gabriel Serdean"  > aserd...@ovn.org> wrote:
> >
> > On Windows the file which is used for the named pipe connection
> > (`punix:file`)
> > is not deleted when the process is closed.
> >
> > Try to delete the `controller` file and fail if we can't (on Windows you
> can't
> > delete a file if there still an opened handle to it).
> >
> > Also add a check to see if the `ovs-testcontroller` was successfully
> started.
> >
> > Signed-off-by: Alin Gabriel Serdean 
> > ---
> >  tests/bridge.at | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/tests/bridge.at b/tests/bridge.at
> > index ee398bdb1..b94afc194 100644
> > --- a/tests/bridge.at
> > +++ b/tests/bridge.at
> > @@ -84,7 +84,7 @@ AT_SETUP([bridge - add port after stopping
> > controller])
> >  OVS_VSWITCHD_START
> >
> >  dnl Start ovs-testcontroller
> > -ovs-testcontroller --detach punix:controller --pidfile=ovs-
> > testcontroller.pid
> > +AT_CHECK([ovs-testcontroller --detach punix:controller
> > --pidfile], [0],
> > [ignore])
> >  OVS_WAIT_UNTIL([test -e controller])
> >
> >  AT_CHECK([ovs-vsctl set-controller br0 unix:controller])
> > @@ -93,6 +93,9 @@ AT_CHECK([ovs-appctl -t ovs-vswitchd version],
> > [0],
> > [ignore])
> >
> >  # Now kill the ovs-testcontroller
> >  kill `cat ovs-testcontroller.pid`
> > +if test "$IS_WIN32" = "yes"; then
> > +AT_CHECK([rm controller], [0], [ignore])
> > +fi
> >  OVS_WAIT_UNTIL([! test -e controller])
> >  AT_CHECK([ovs-vsctl --no-wait add-port br0 p2 -- set Interface p2
> > type=internal], [0], [ignore])
> >  AT_CHECK([ovs-appctl -t ovs-vswitchd version], [0], [ignore])
> > --
> > 2.16.1.windows.1
> >
> > ___
> > dev mailing list
> > d...@openvswitch.org
> >
> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.
> > o
> > penvswitch.org%2Fmailman%2Flistinfo%2Fovs-
> >
> devdata=02%7C01%7Cvsairam%40vmware.com%7C074d45f6e70d4431
> >
> f7a708d64a4639a6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C6
> >
> 36778062866824077sdata=EPht5myv2MmYwaY49hSYegAfewIVjkbvNC
> > Tf5YBsYJM%3Dreserved=0
> >
> >
> > ___
> > dev mailing list
> > d...@openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
> 
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 1/2] ovn: Avoid tunneling for VLAN packets redirected to a gateway chassis

[Guru Shetty]

On Fri, 5 Oct 2018 at 10:15,  wrote:

> From: Numan Siddique 
>
> An OVN deployment can have multiple logical switches each with a
> localnet port connected to a distributed logical router with one
> logical router port providing external connectivity (provider network)
> and others used as tenant networks with VLAN tagging.
>
> As reported in [1], external traffic from these VLAN tenant networks
> are tunnelled to the gateway chassis (chassis hosting a distributed
> gateway port which applies NAT rules). As part of the discussion in
> [1], there were few possible solutions proposed by Russell [2]. This
> patch implements the first option in [2].
>
> With this patch, a new option 'reside-on-redirect-chassis' in 'options'
> column of Logical_Router_Port table is added. If the value of this
> option is set to 'true' and if the logical router also have a
> distributed gateway port, then routing for this logical router port
> is centralized in the chassis hosting the distributed gateway port.
>
> If a logical switch 'sw0' is connected to a router 'lr0' with the
> router port - 'lr0-sw0' with the address - "00:00:00:00:af:12 192.168.1.1"
> , and it has a distributed logical port - 'lr0-public', then the
> below logical flow is added in the logical switch pipeline
> of 'sw0' if the 'reside-on-redirect-chassis' option is set on 'lr-sw0' -
>
> table=16(ls_in_l2_lkup), priority=50,
> match=(eth.dst == 00:00:00:00:af:12 &&
> is_chassis_resident("cr-lr0-public")),
> action=(outport = "sw0-lr0"; output;)
>

Where does the "cr" come above?

>
> With the above flow, the packet doesn't enter the router pipeline in
> the source chassis. Instead the packet is sent out via the localnet
> port of 'sw0'. The gateway chassis upon receiving this packet, runs
> the logical router pipeline applying NAT rules and sends the traffic
> out via the localnet port of the provider network. The gateway
> chassis will also reply to the ARP requests for the router port IPs.
>
> With this approach, we avoid redirecting the external traffic to the
> gateway chassis via the tunnel port. There are a couple of drawbacks
> with this approach:
>
>   - East - West routing is no more distributed for the VLAN tenant
> networks if 'reside-on-redirect-chassis' option is defined
>
>   - 'dnat_and_snat' NAT rules with 'logical_mac' and 'logical_port'
> columns defined will not work for the VLAN tenant networks.
>
> This approach is taken for now as it is simple. If there is a requirement
> to support distributed routing for these VLAN tenant networks, we
> can explore other possible solutions.
>
> [1] -
> https://mail.openvswitch.org/pipermail/ovs-discuss/2018-April/046543.html
> [2] -
> https://mail.openvswitch.org/pipermail/ovs-discuss/2018-April/046557.html
>
> Reported-at:
> https://mail.openvswitch.org/pipermail/ovs-discuss/2018-April/046543.html
> Reported-by: venkata anil 
> Co-authored-by: venkata anil 
> Signed-off-by: Numan Siddique 
> Signed-off-by: venkata anil 
>

Acked-by: Gurucharan Shetty 

Thank you for the extensive documentation. Though many of it feels obvious
now when I read it. For non-users of localnet, the memory had faded enough
to not understand the context well before.

Couple of comments for documentation below.


> ---
>  ovn/northd/ovn-northd.8.xml |  30 
>  ovn/northd/ovn-northd.c |  71 +++---
>  ovn/ovn-architecture.7.xml  | 160 +
>  ovn/ovn-nb.xml  |  43 ++
>  tests/ovn.at| 273 
>  5 files changed, 561 insertions(+), 16 deletions(-)
>
> diff --git a/ovn/northd/ovn-northd.8.xml b/ovn/northd/ovn-northd.8.xml
> index 7352c6764..f52699bd3 100644
> --- a/ovn/northd/ovn-northd.8.xml
> +++ b/ovn/northd/ovn-northd.8.xml
> @@ -874,6 +874,25 @@ output;
>  resident.
>
>  
> +
> +
> +  For the Ethernet address on a logical switch port of type
> +  router, when that logical switch port's
> +   +  db="OVN_Northbound"/> column is set to router and
> +  the connected logical router port specifies a
> +  reside-on-redirect-chassis and the logical router
> +  to which the connected logical router port belongs to has a
> +  redirect-chassis distributed gateway logical router
> +  port:
> +
> +
> +
> +  
> +The flow for the connected logical router port's Ethernet
> +address is only programmed on the
> redirect-chassis.
> +  
> +
>
>
>
> @@ -1179,6 +1198,17 @@ output;
>upstream MAC learning to point to the
>redirect-chassis.
>  
> +
> +
> +  For the logical router port with the option
> +  reside-on-redirect-chassis set (which is
> centralized),
> +  the above flows are only programmed on the gateway port
> instance on
> +  the redirect-chassis (if the logical router has a
> 

[ovs-dev] Regalos empresariales

[Maderpak via dev]

ENVASES DE MADERA PARA TUS PRODUCTOS
 
( https://maderpak.com/ )
Maderpak SA aporta envases en la actualidad para los requerimientos de 
packaging, envoltorio, conservación, transporte o guardado de áreas muy 
amplias y diversificadas.

¿Buscas bajar costos en el packaging
de tus productos?

VER CATALOGO DE PRODUCTOS ONLINE - ACA 
( https://maderpak.com/nuestros-productos.html )

.
( https://maderpak.com/ )
.
Entre nuestros principales clientes se encuentran los provenientes de la 
industria alimenticia, textil, marroquinerías, farmacéutica, metalúrgica, 
electrónica, vitivinícola y todos los segmentos que operan con regalos 
empresariales y muestras personalizadas para exposiciones o semejantes .

Teléfono:(54 11) 4255 4483

WEB. www.maderpak.com ( https://maderpak.com/ )
EMAIL. i...@maderpak.com 
( 
mailto:i...@maderpak.com?Subject=Consulta=Por%20favor%20complete%20los%20siguientes%20datos:%0ANombre%20y%20Apellido:%0ATelefono/s:%0AConsulta:
 )

SOLICITAR ASESORAMIENTO POR CORREO - CLICK ACA ( mailto:i...@maderpak.com )
Av. San Martín 921 - Florencio Varela (1888)
Prov. Buenos Aires - Argentina

Aceptamos tarjetas de crédito y débito
( https://maderpak.com/ )


 
 
 

Este es un e-mail legal y contiene informacion de servicios y productos que 
consideramos pueden ser de su interes.
De acuerdo con la nueva Ley argentina Nro. 26.032, la libre distribucion de 
este e-mail esta
autorizada por tratarse de propositos de informacion, sin embargo, si le 
hemos causado alguna molestia por el mismo, le rogamos acepte nuestras 
disculpas.

Si lo desea puede ser quitado de nuestra lista de correos solicitandolo a 
baj...@yopmail.com
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] VLAN tenant network patches

[Ankur Sharma]

Hi Miguel,
Thanks a lot for the clarification, sounds good to me.

Hi Guru,
Yes, Implementation will be generic (not specific to a particular use case) and 
should be seen as enhancement.

Regards,
Ankur


From: Miguel Angel Ajo Pelayo 
Sent: Thursday, November 15, 2018 1:06:34 AM
To: Gurucharan Shetty; Numan Siddique
Cc: Ankur Sharma; ovs dev
Subject: Re: [ovs-dev] VLAN tenant network patches

Thanks for looking at this and keeping it moving forward.

I'm also fine with both ways of implementing the feature, and of course, having 
distributed
E/W for VLAN is great, It'd be amazing, based on not duplicating interfaces, 
that the
implementations don't interfere each other, and that numan's patches are 
reasonably small,
to have numans implementation merged, and then Ankur's when it's ready, let me 
explain why:

1) For Openstack with OVN VLAN support is blocked at the moment, because of the
 MTU missmatch issue, so it'd be great to have that available as soon as 
possible.

2)  Numan's implementation would also allow the gateway chassis handling the
 VLAN E/W traffic to be used by SR-IOV[1] instances on an OVN managed 
network
 (something common in the openstack world).

 But this is a secondary bonus, 1** is the important part from my POV.

[1] SR-IOV is a network card technology that partitions a physical network card 
into severals, and then
 those partitions are memory mapped into VMs, along with an IRQ. The 
network card has a
 simple switch inside for the partitionet network cards, and can assign a 
VLAN to each of them.


Thank you very much @Gurucharan Shetty , 
@ankur.sha...@nutanix.com and @Numan 
Siddique

On Wed, Nov 14, 2018 at 6:04 PM Guru Shetty mailto:g...@ovn.org>> 
wrote:
Okay. I want to make sure that we don't end up with 3 gateway
implementations. We currently have 2. So when you are adding this new
feature, please do NOT make it an independent feature which only works for
your use case. It will be a maintenance headache otherwise. Instead, it has
to be looked at as enhancements for existing OVN features. I hope that is
clear.

On Wed, 14 Nov 2018 at 05:18, Ankur Sharma 
mailto:ankur.sha...@nutanix.com>> wrote:

> Hi Guru,
>
> Sure, providing more explanation.
>
> Q. What are we trying to solve?
> Ans. Getting distributed routing to work for vlan backed networks through
> OVN.
>
> Q. Disconnect wrt OVN capabilities for above task?
>
> Ans. OVN lacks in certain areas wrt how to forward the packets
> "correctly/efficiently" in the absence of encapsulation (VXLAN, STT or
> GENEVE).
>
> Following are the known gaps:
>
> L3 E-W
>
> ==
> a. Since a router port is distributed, hence in the absence of
> encapsulation, we should not be using router port mac as source mac. Our
> proposal is to replace router port mac with a chassis specific unique mac,
> when an unencapsulated packet originating from router port goes on wire.
> This was explained in following email:
> https://mail.openvswitch.org/pipermail/ovs-dev/2018-October/353179.html 
> [mail.openvswitch.org]
>
>
> b. Sending ARP reply on wire.
>
> As of now, OVN consumes ARP reply from VM which are destined to router
> port (because router port is present locally on vm's chassis as well).
> Because ARP reply is NOT seen on the wire, hence a physical switch will
> never learn VM's mac (unless VM is involved in a L2 communication as well).
>
> As a result, a DVR routed traffic, will always be flooded by TOR (top of
> the rack switch), as dest mac is that of the VM, which TOR never learnt.
>
>
> L3 N-S
>
> ==
>
> a. For vlan backed networks, NATing is NOT a must to talk to "outside"
> physical network (for overlay it is). Hence, OVN requires some changes in
> this area as well.
>
> b. DO NOT respond to ARP request for any ROUTER PORT from uplink, unless
> it is on gateway chassis.
>
> c. When gateway chassis failover happens, then advertise router port mac
> as well.
>
>
>
> L3 N-S NAT
>
> =
>
> a. Current OVN implementation uses geneve encap (geneve options) to
> provide metadata to the gateway chassis (where SNAT happens).
>
> b. In the absence of encapsulation, OVN should be enhanced to still
> support NAT on gateway chassis.
>
>
> ===
>
>
> Our initial proposal has details as well:
>
> https://mail.openvswitch.org/pipermail/ovs-dev/2018-October/353066.html 
> 

[ovs-dev] [PATCH] coding-style: Remove redundant symbols from the examples.

[Ilya Maximets]

Some backslashes was added while converting from .md to .rst.
These symbols are printable in both pdf and html docs and
should be removed.

CC: Stephen Finucane 
Fixes: d124a408a4bc ("doc: Convert CodingStyle to rST")
Signed-off-by: Ilya Maximets 
---
 Documentation/internals/contributing/coding-style.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/internals/contributing/coding-style.rst 
b/Documentation/internals/contributing/coding-style.rst
index 3ce104994..28cbec28b 100644
--- a/Documentation/internals/contributing/coding-style.rst
+++ b/Documentation/internals/contributing/coding-style.rst
@@ -530,7 +530,7 @@ Do not put any white space around postfix, prefix, or 
grouping operators:
 Exception 1: Put a space after (but not before) the "sizeof" keyword.
 
 Exception 2: Put a space between the () used in a cast and the expression whose
-type is cast: ``(void \*) 0``.
+type is cast: ``(void *) 0``.
 
 Break long lines before the ternary operators ? and :, rather than after
 them, e.g.
@@ -585,7 +585,7 @@ Try to avoid casts. Don't cast the return value of malloc().
 
 The "sizeof" operator is unique among C operators in that it accepts two very
 different kinds of operands: an expression or a type. In general, prefer to
-specify an expression, e.g. ``int *x = xmalloc(sizeof *\ x);``. When the
+specify an expression, e.g. ``int *x = xmalloc(sizeof *x);``. When the
 operand of sizeof is an expression, there is no need to parenthesize that
 operand, and please don't.
 
-- 
2.17.1

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] VLAN tenant network patches

[Miguel Angel Ajo Pelayo]

Thanks for looking at this and keeping it moving forward.

I'm also fine with both ways of implementing the feature, and of course,
having distributed
E/W for VLAN is great, It'd be amazing, based on not duplicating
interfaces, that the
implementations don't interfere each other, and that numan's patches are
reasonably small,
to have numans implementation merged, and then Ankur's when it's ready, let
me explain why:

1) For Openstack with OVN VLAN support is blocked at the moment, because of
the
 MTU missmatch issue, so it'd be great to have that available as soon
as possible.

2)  Numan's implementation would also allow the gateway chassis handling the
 VLAN E/W traffic to be used by SR-IOV[1] instances on an OVN managed
network
 (something common in the openstack world).

 But this is a secondary bonus, 1** is the important part from my POV.

[1] SR-IOV is a network card technology that partitions a physical network
card into severals, and then
 those partitions are memory mapped into VMs, along with an IRQ. The
network card has a
 simple switch inside for the partitionet network cards, and can assign
a VLAN to each of them.


Thank you very much @Gurucharan Shetty  ,
@ankur.sha...@nutanix.com  and @Numan Siddique


On Wed, Nov 14, 2018 at 6:04 PM Guru Shetty  wrote:

> Okay. I want to make sure that we don't end up with 3 gateway
> implementations. We currently have 2. So when you are adding this new
> feature, please do NOT make it an independent feature which only works for
> your use case. It will be a maintenance headache otherwise. Instead, it has
> to be looked at as enhancements for existing OVN features. I hope that is
> clear.
>
> On Wed, 14 Nov 2018 at 05:18, Ankur Sharma 
> wrote:
>
> > Hi Guru,
> >
> > Sure, providing more explanation.
> >
> > Q. What are we trying to solve?
> > Ans. Getting distributed routing to work for vlan backed networks through
> > OVN.
> >
> > Q. Disconnect wrt OVN capabilities for above task?
> >
> > Ans. OVN lacks in certain areas wrt how to forward the packets
> > "correctly/efficiently" in the absence of encapsulation (VXLAN, STT or
> > GENEVE).
> >
> > Following are the known gaps:
> >
> > L3 E-W
> >
> > ==
> > a. Since a router port is distributed, hence in the absence of
> > encapsulation, we should not be using router port mac as source mac. Our
> > proposal is to replace router port mac with a chassis specific unique
> mac,
> > when an unencapsulated packet originating from router port goes on wire.
> > This was explained in following email:
> > https://mail.openvswitch.org/pipermail/ovs-dev/2018-October/353179.html
> >
> >
> > b. Sending ARP reply on wire.
> >
> > As of now, OVN consumes ARP reply from VM which are destined to router
> > port (because router port is present locally on vm's chassis as well).
> > Because ARP reply is NOT seen on the wire, hence a physical switch will
> > never learn VM's mac (unless VM is involved in a L2 communication as
> well).
> >
> > As a result, a DVR routed traffic, will always be flooded by TOR (top of
> > the rack switch), as dest mac is that of the VM, which TOR never learnt.
> >
> >
> > L3 N-S
> >
> > ==
> >
> > a. For vlan backed networks, NATing is NOT a must to talk to "outside"
> > physical network (for overlay it is). Hence, OVN requires some changes in
> > this area as well.
> >
> > b. DO NOT respond to ARP request for any ROUTER PORT from uplink, unless
> > it is on gateway chassis.
> >
> > c. When gateway chassis failover happens, then advertise router port mac
> > as well.
> >
> >
> >
> > L3 N-S NAT
> >
> > =
> >
> > a. Current OVN implementation uses geneve encap (geneve options) to
> > provide metadata to the gateway chassis (where SNAT happens).
> >
> > b. In the absence of encapsulation, OVN should be enhanced to still
> > support NAT on gateway chassis.
> >
> >
> > ===
> >
> >
> > Our initial proposal has details as well:
> >
> > https://mail.openvswitch.org/pipermail/ovs-dev/2018-October/353066.html
> >
> >
> > Like i mentioned, problem statement we are trying to solve is
> "Distributed
> > Virtual Routing For VLAN Backed Networks".
> > As a part of above, we have identified some gaps, which we intend to fix.
> >
> >
> > As we progress further, we will have to add some features as well.
> > But, as of now we are focused on getting basic functionality to work
> > correctly first.
> >
> >
> >
> > Please feel free to put forth more queries/concerns you have, i will be
> > happy to explain.
> >
> > Thanks again for review.
> >
> > Regards,
> > Ankur
> >
> >
> > --
> > *From:* Guru Shetty 
> > *Sent:* Monday, November 12, 2018 9:58:07 AM
> > *To:* Ankur Sharma
> > *Cc:* ovs dev; Numan Siddique; Ben Pfaff
> > *Subject:* Re: VLAN tenant network patches
> >
> >
> >
> > On Sun, 11 Nov 2018 at 21:02, Ankur Sharma 
> > wrote:
> >
> > Hi Guru,
> >
> > Thanks for spending time in