Re: [ovs-dev] OVN based distributed virtual routing for VLAN backed networks

[Ankur Sharma]

Hi Han,

Appreciate your feedback.
Please find the reply inline.

Thanks

Regards,
Ankur

From: Han Zhou 
Sent: Friday, October 19, 2018 5:17 PM
To: Ankur Sharma 
Cc: Mark Michelson ; ovs-dev@openvswitch.org
Subject: Re: [ovs-dev] OVN based distributed virtual routing for VLAN backed 
networks



On Fri, Oct 19, 2018 at 3:09 PM Ankur Sharma 
mailto:ankur.sha...@nutanix.com>> wrote:
>
> Hi Han,
>
> Thanks a lot for review.
> Please find my replies inline.
>
> Please  feel free to put forth more points for discussion.
>
> Thanks
>
> Regards,
> Ankur
>
>
>
> From: Han Zhou mailto:zhou...@gmail.com>>
> Sent: Thursday, October 18, 2018 11:55 PM
> To: Ankur Sharma mailto:ankur.sha...@nutanix.com>>
> Cc: Mark Michelson mailto:mmich...@redhat.com>>; 
> ovs-dev@openvswitch.org
> Subject: Re: [ovs-dev] OVN based distributed virtual routing for VLAN backed 
> networks
>
>
>
> Hi Ankur, Mark,
>
>
>
> Please find my comments inline below.
>
>
>
> (I will spend more time to understand the change for the NAT case. )
>
>
>
> Thanks,
>
> Han
>
>
>
>
> On Thu, Oct 18, 2018 at 4:40 PM Ankur Sharma 
> mailto:ankur.sha...@nutanix.com>> wrote:
> >
> > Hi,
> >
> > As per our discussion in the IRC meeting  today, i have added all the 
> > diagrams in following google doc.
> > https://docs.google.com/document/d/1uoQH478wM1OZ16HrxzbOUvk5LvFnfNEWbkPT6Zmm9OU/edit?usp=sharing
> >  
> > [docs.google.com]
> >  [docs.google.com 
> > [docs.google.com]]
> >
> > Please take a look.
> >
> > Appreciate the feedback so far, looking forward to more discussions.
> >
> > Thanks
> >
> > Regards,
> > Ankur
> >
> >
> > -Original Message-
> > From: Ankur Sharma
> > Sent: Wednesday, October 17, 2018 3:37 PM
> > To: 'Mark Michelson' mailto:mmich...@redhat.com>>; 
> > ovs-dev@openvswitch.org
> > Subject: RE: [ovs-dev] OVN based distributed virtual routing for VLAN 
> > backed networks
> >
> > Hi Mark,
> >
> > Thanks a lot for the feedback.
> > Regarding the figures, i attached the PNGs (shows in my sent items), but 
> > looks like they got filtered.
> > My bad on that, is there a location, where OVS community uploads images for 
> > references.
> > Please bear with us, hopefully, we will be able to avoid some of these 
> > glitches in our next conversations.
> >
> > Appreciate your comments on the proposal, please find my replies inline.
> >
> > Thanks
> >
> > Regards,
> > Ankur
> >
> > -Original Message-
> > From: Mark Michelson mailto:mmich...@redhat.com>>
> > Sent: Wednesday, October 17, 2018 2:50 PM
> > To: Ankur Sharma 
> > mailto:ankur.sha...@nutanix.com>>; 
> > ovs-dev@openvswitch.org
> > Subject: Re: [ovs-dev] OVN based distributed virtual routing for VLAN 
> > backed networks
> >
> > Hi Ankur,
> >
> > Thanks for the detailed document! I always appreciate it when things are 
> > planned out in great detail so we know exactly what to expect.
> >
> > A general comment: there are places below where things like "figure 1"
> > and "figure OVN bridge deployment" are referenced, but we can't see them. 
> > Is there a link to another document you can share that has these figures 
> > present?
> >
> > Other comments of mine are inline below.
> >
> > On 10/16/2018 06:43 PM, Ankur Sharma wrote:
> > > Hi,
> > >
> > > We have done some effort in evaluating usage of OVN for Distributed
>
> > > Virtual Routing (DVR) for vlan backed networks.
>
>
>
> So the proposal should work only when all the HVs are physically L2 connected 
> (no L3 hops in between), correct? OVN doesn't have this assumption, but I 
> think it should be ok if it is documented well so that users will understand 
> this limitation when using this feature.
>
>
>
> > >
> > > We would like to take it forward with the community.
> > >
> > > We understand that some of the work could be overlapping with existing
> > > patches in review.
> > >
> > > We would appreciate the feedback and would be happy to update our
> > > patches to avoid known overlaps.
> > >
> > > This email explains the proposal. We will be following it up with patches.
> > > Each "CODE CHANGES" section summarizes the change that corresponding
> > > patch would have.
> > >
> > >
> > > DISTRIBUTED VIRTUAL ROUTING FOR VLAN BACKED NETWORKS
> > > ==
> > >
> > >
> > > 1. OVN Bridge Deployment
> > > 
> > >
> 

Re: [ovs-dev] OVN based distributed virtual routing for VLAN backed networks

[Han Zhou]

On Fri, Oct 19, 2018 at 3:09 PM Ankur Sharma 
wrote:
>
> Hi Han,
>
> Thanks a lot for review.
> Please find my replies inline.
>
> Please  feel free to put forth more points for discussion.
>
> Thanks
>
> Regards,
> Ankur
>
>
>
> From: Han Zhou 
> Sent: Thursday, October 18, 2018 11:55 PM
> To: Ankur Sharma 
> Cc: Mark Michelson ; ovs-dev@openvswitch.org
> Subject: Re: [ovs-dev] OVN based distributed virtual routing for VLAN
backed networks
>
>
>
> Hi Ankur, Mark,
>
>
>
> Please find my comments inline below.
>
>
>
> (I will spend more time to understand the change for the NAT case. )
>
>
>
> Thanks,
>
> Han
>
>
>
>
> On Thu, Oct 18, 2018 at 4:40 PM Ankur Sharma 
wrote:
> >
> > Hi,
> >
> > As per our discussion in the IRC meeting  today, i have added all the
diagrams in following google doc.
> >
https://docs.google.com/document/d/1uoQH478wM1OZ16HrxzbOUvk5LvFnfNEWbkPT6Zmm9OU/edit?usp=sharing
[docs.google.com]
> >
> > Please take a look.
> >
> > Appreciate the feedback so far, looking forward to more discussions.
> >
> > Thanks
> >
> > Regards,
> > Ankur
> >
> >
> > -Original Message-
> > From: Ankur Sharma
> > Sent: Wednesday, October 17, 2018 3:37 PM
> > To: 'Mark Michelson' ; ovs-dev@openvswitch.org
> > Subject: RE: [ovs-dev] OVN based distributed virtual routing for VLAN
backed networks
> >
> > Hi Mark,
> >
> > Thanks a lot for the feedback.
> > Regarding the figures, i attached the PNGs (shows in my sent items),
but looks like they got filtered.
> > My bad on that, is there a location, where OVS community uploads images
for references.
> > Please bear with us, hopefully, we will be able to avoid some of these
glitches in our next conversations.
> >
> > Appreciate your comments on the proposal, please find my replies inline.
> >
> > Thanks
> >
> > Regards,
> > Ankur
> >
> > -Original Message-
> > From: Mark Michelson 
> > Sent: Wednesday, October 17, 2018 2:50 PM
> > To: Ankur Sharma ; ovs-dev@openvswitch.org
> > Subject: Re: [ovs-dev] OVN based distributed virtual routing for VLAN
backed networks
> >
> > Hi Ankur,
> >
> > Thanks for the detailed document! I always appreciate it when things
are planned out in great detail so we know exactly what to expect.
> >
> > A general comment: there are places below where things like "figure 1"
> > and "figure OVN bridge deployment" are referenced, but we can't see
them. Is there a link to another document you can share that has these
figures present?
> >
> > Other comments of mine are inline below.
> >
> > On 10/16/2018 06:43 PM, Ankur Sharma wrote:
> > > Hi,
> > >
> > > We have done some effort in evaluating usage of OVN for Distributed
>
> > > Virtual Routing (DVR) for vlan backed networks.
>
>
>
> So the proposal should work only when all the HVs are physically L2
connected (no L3 hops in between), correct? OVN doesn't have this
assumption, but I think it should be ok if it is documented well so that
users will understand this limitation when using this feature.
>
>
>
> > >
> > > We would like to take it forward with the community.
> > >
> > > We understand that some of the work could be overlapping with existing
> > > patches in review.
> > >
> > > We would appreciate the feedback and would be happy to update our
> > > patches to avoid known overlaps.
> > >
> > > This email explains the proposal. We will be following it up with
patches.
> > > Each "CODE CHANGES" section summarizes the change that corresponding
> > > patch would have.
> > >
> > >
> > > DISTRIBUTED VIRTUAL ROUTING FOR VLAN BACKED NETWORKS
> > > ==
> > >
> > >
> > > 1. OVN Bridge Deployment
> > > 
> > >
> > > Our design follows following ovn-bridge deployment model (please refer
> > > to figure OVN Bridge deployment).
> > >  i. br-int ==> OVN managed bridge.
> > > br-pif ==> Learning Bridge, where physical NICs will be
connected.
> > >
> > > ii. Any packet that should be on physical network, will travel
from BR-INT
> > > to BR-PIF, via patch ports (localnet ports).
> > >
> > > 2. Layer 2
> > > -
> > >
> > > DESIGN:
> > > ~~~
> > > a. Leverage on localnet logical port type as path port between
br-int and
> > > br-pif.
> > > b. Each VLAN backed logical switch will have a localnet port
connected
> > > to it.
> > > c. Tagging and untagging of vlan headers happens at localnet port
boundary.
> > >
> > > PIPELINE EXECUTION:
> > > ~~~
> > > a. Unlike geneve encap based solution, where we execute ingress
pipeline on
> > > source chassis and egress pipeline on destination chassis,
for vlan
> > > backed logical switches, packet will go through ingress
pipeline
> > > on destination chassis as well.
> > >
> > > PACKET FLOW (Figure 1. shows topology and Figure 2. shows the
packet flow):
> > >
~~~
> > > 

Re: [ovs-dev] OVN based distributed virtual routing for VLAN backed networks

[Ankur Sharma]

Hi Guru,

Thanks for taking a look.
Please find the detailed explanation of problem statement inline.

Thanks

Regards,
Ankur

From: Guru Shetty 
Sent: Friday, October 19, 2018 9:35 AM
To: Ankur Sharma 
Cc: ovs-dev 
Subject: Re: [ovs-dev] OVN based distributed virtual routing for VLAN backed 
networks


On Tue, 16 Oct 2018 at 15:43, Ankur Sharma 
mailto:ankur.sha...@nutanix.com>> wrote:
Hi,

We have done some effort in evaluating usage of OVN for
Distributed Virtual Routing (DVR) for vlan backed networks.

Would you mind explaining the above statement with a lot of details? I would 
like to understand the problem well before looking at the proposed solution.

[ANKUR]:
a. OVN provides logical routing and switching, but was designed for scenario 
where logical switch is of type “overlay”.
 i.e Packets going on the wire are always encapsulated (exception would be 
communication with external network, via NAT).

b. Our proposal is to enhance OVN to support cases where logical switch is of 
type “vlan”,
 i.e there is no encapsulation and “inner” packet goes on the wire “as is”.

c. We evaluated current OVN implementation for both logical-switches and 
logical-routers.

d. Our proposal is meant to highlight the gaps (as of now) and how we plan to 
fix them.


We would like to take it forward with the community.

We understand that some of the work could be overlapping with existing
patches in review.

We would appreciate the feedback and would be happy to update our patches
to avoid known overlaps.

This email explains the proposal. We will be following it up with patches.
Each "CODE CHANGES" section summarizes the change that corresponding patch
would have.


DISTRIBUTED VIRTUAL ROUTING FOR VLAN BACKED NETWORKS
==


1. OVN Bridge Deployment


Our design follows following ovn-bridge deployment model
(please refer to figure OVN Bridge deployment).
i. br-int ==> OVN managed bridge.
   br-pif ==> Learning Bridge, where physical NICs will be connected.

   ii. Any packet that should be on physical network, will travel from BR-INT
   to BR-PIF, via patch ports (localnet ports).

2. Layer 2
-

   DESIGN:
   ~~~
   a. Leverage on localnet logical port type as path port between br-int and
   br-pif.
   b. Each VLAN backed logical switch will have a localnet port connected
   to it.
   c. Tagging and untagging of vlan headers happens at localnet port boundary.

   PIPELINE EXECUTION:
   ~~~
   a. Unlike geneve encap based solution, where we execute ingress pipeline on
   source chassis and egress pipeline on destination chassis, for vlan
   backed logical switches, packet will go through ingress pipeline
   on destination chassis as well.

   PACKET FLOW (Figure 1. shows topology and Figure 2. shows the packet flow):
   ~~~
   a. VM sends unicast traffic (destined to VM2_MAC) to br-int.
   b. For br-int, destination mac is not local, hence it will forward it to
   localnet port (by design), which is attached to br-pif. This is
   the stage at which vlan tag is added. Br-pif forwards the packet
   to physical interface.
   c. br-pif on destination chassis sends the received traffic to patch-ports
   on br-int (as unicast or unknown unicast).
   d. br-int does vlan tag check, strips the vlan header and sends
   the packet to ingress pipeline of the corresponding datapath.


   KEY DIFFERENCES AS COMPARED TO OVERLAY:
   ~~~
   a. No encapsulation.
   b. Both ingress and egress pipelines of logical switch are executed on
   both source and destination hypervisor (unlike overlay where ingress
   pipeline is executed on source hypervisor and egress on destination).

   CODE CHANGES:
   ~
   a. ovn-nb.ovsschema:
1. Add a new column to table Logical_Switch.
2. Column name would be "type".
3. Values would be either "vlan" or "overlay", with "overlay"
being default.

   b. ovn-sbctl:
1. Add a new cli which sets the "type" of logical-switch.
ovn-nbctl ls-set-network-type SWITCH TYPE

   c. ovn-northd:
1. Add a new enum to ovn_datapath struct, which will indicate
if logical_switch datapath type is overlay or vlan.
2. Populate a new key value pair in southbound database for Datapath
Bindings of Logical_Switch.
3. Key value pair: , default
will be overlay.


3. Layer 3 East West


   DESIGN:
   ~~~
   a. Since the router port is distributed and there is no encapsulation,
   hence packets with router port mac as source mac cannot go on wire.
   b. We propose replacing router port mac with a chassis specific mac,
   whenever packet goes on wire.
   c. Number of chassis_mac per chassis 

Re: [ovs-dev] OVN based distributed virtual routing for VLAN backed networks

[Ankur Sharma]

Hi Han,

Thanks a lot for review.
Please find my replies inline.

Please  feel free to put forth more points for discussion.

Thanks

Regards,
Ankur

From: Han Zhou 
Sent: Thursday, October 18, 2018 11:55 PM
To: Ankur Sharma 
Cc: Mark Michelson ; ovs-dev@openvswitch.org
Subject: Re: [ovs-dev] OVN based distributed virtual routing for VLAN backed 
networks

Hi Ankur, Mark,

Please find my comments inline below.

(I will spend more time to understand the change for the NAT case. )

Thanks,
Han


On Thu, Oct 18, 2018 at 4:40 PM Ankur Sharma 
mailto:ankur.sha...@nutanix.com>> wrote:
>
> Hi,
>
> As per our discussion in the IRC meeting  today, i have added all the 
> diagrams in following google doc.
> https://docs.google.com/document/d/1uoQH478wM1OZ16HrxzbOUvk5LvFnfNEWbkPT6Zmm9OU/edit?usp=sharing
>  
> [docs.google.com]
>
> Please take a look.
>
> Appreciate the feedback so far, looking forward to more discussions.
>
> Thanks
>
> Regards,
> Ankur
>
>
> -Original Message-
> From: Ankur Sharma
> Sent: Wednesday, October 17, 2018 3:37 PM
> To: 'Mark Michelson' mailto:mmich...@redhat.com>>; 
> ovs-dev@openvswitch.org
> Subject: RE: [ovs-dev] OVN based distributed virtual routing for VLAN backed 
> networks
>
> Hi Mark,
>
> Thanks a lot for the feedback.
> Regarding the figures, i attached the PNGs (shows in my sent items), but 
> looks like they got filtered.
> My bad on that, is there a location, where OVS community uploads images for 
> references.
> Please bear with us, hopefully, we will be able to avoid some of these 
> glitches in our next conversations.
>
> Appreciate your comments on the proposal, please find my replies inline.
>
> Thanks
>
> Regards,
> Ankur
>
> -Original Message-
> From: Mark Michelson mailto:mmich...@redhat.com>>
> Sent: Wednesday, October 17, 2018 2:50 PM
> To: Ankur Sharma mailto:ankur.sha...@nutanix.com>>; 
> ovs-dev@openvswitch.org
> Subject: Re: [ovs-dev] OVN based distributed virtual routing for VLAN backed 
> networks
>
> Hi Ankur,
>
> Thanks for the detailed document! I always appreciate it when things are 
> planned out in great detail so we know exactly what to expect.
>
> A general comment: there are places below where things like "figure 1"
> and "figure OVN bridge deployment" are referenced, but we can't see them. Is 
> there a link to another document you can share that has these figures present?
>
> Other comments of mine are inline below.
>
> On 10/16/2018 06:43 PM, Ankur Sharma wrote:
> > Hi,
> >
> > We have done some effort in evaluating usage of OVN for Distributed
> > Virtual Routing (DVR) for vlan backed networks.

So the proposal should work only when all the HVs are physically L2 connected 
(no L3 hops in between), correct? OVN doesn't have this assumption, but I think 
it should be ok if it is documented well so that users will understand this 
limitation when using this feature.

> >
> > We would like to take it forward with the community.
> >
> > We understand that some of the work could be overlapping with existing
> > patches in review.
> >
> > We would appreciate the feedback and would be happy to update our
> > patches to avoid known overlaps.
> >
> > This email explains the proposal. We will be following it up with patches.
> > Each "CODE CHANGES" section summarizes the change that corresponding
> > patch would have.
> >
> >
> > DISTRIBUTED VIRTUAL ROUTING FOR VLAN BACKED NETWORKS
> > ==
> >
> >
> > 1. OVN Bridge Deployment
> > 
> >
> > Our design follows following ovn-bridge deployment model (please refer
> > to figure OVN Bridge deployment).
> >  i. br-int ==> OVN managed bridge.
> > br-pif ==> Learning Bridge, where physical NICs will be connected.
> >
> > ii. Any packet that should be on physical network, will travel from 
> > BR-INT
> > to BR-PIF, via patch ports (localnet ports).
> >
> > 2. Layer 2
> > -
> >
> > DESIGN:
> > ~~~
> > a. Leverage on localnet logical port type as path port between br-int 
> > and
> > br-pif.
> > b. Each VLAN backed logical switch will have a localnet port connected
> > to it.
> > c. Tagging and untagging of vlan headers happens at localnet port 
> > boundary.
> >
> > PIPELINE EXECUTION:
> > ~~~
> > a. Unlike geneve encap based solution, where we execute ingress 
> > pipeline on
> > source chassis and egress pipeline on destination chassis, for vlan
> > backed logical switches, packet will go through ingress pipeline
> > on 

Re: [ovs-dev] Happy to work with you.

[Mr. Kofi Adomakoh.]

 - This mail is in HTML. Some elements may be ommited in plain text. -

Good day,
Firstly, I apologize for sending you this sensitive information via e-mail 
instead of a Certified/Post-mail. It is understandable that you might be a 
little bit apprehensive because you do not know me, But I have a lucrative 
business offer of mutual interest i sent you before, Hope you got my last email.
Mr. Kofi Adomakoh.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [RFC PATCH v1 3/3] windows: Allow add/delete ports via HNS API

[Sairam Venugopal]

Can't you use CreateProcess or _popen to trigger the script/function directly?

Thanks,
Sairam

On 10/8/18, 4:28 PM, "ovs-dev-boun...@openvswitch.org on behalf of Alin 
Gabriel Serdean"  wrote:

On Windows 2016 LTSC(RTM) the Container feature and Hyper-V feature both had
DCOM API to add and delete internal (management) ports on the Hyper-V 
switch.

Starting from the 1703 release and above, enabling only the Container 
feature
does not fulfil this requirement anymore.

We need new ways to interact with the host API without the Hyper-V 
integration.

Unfortunately, there is no C API for it, only golang and .net:

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoft%2Fhcsshimdata=02%7C01%7Cvsairam%40vmware.com%7C1601769abfd64a60b41708d62d75af52%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636746380831225713sdata=pvCJPIt%2FOhVeth4fC22%2BlawFM0jvFPOQBFL6xMdvV6o%3Dreserved=0
 (golang)

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fdotnet-computevirtualizationdata=02%7C01%7Cvsairam%40vmware.com%7C1601769abfd64a60b41708d62d75af52%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636746380831225713sdata=hVO%2B6%2BwjL8ZpklKGb6Ti2WA4dS2p20%2Bwy%2BfqS%2BPPCC0%3Dreserved=0
 (.net)
It is also poorly documented and reserved.

Although not pretty and less performant, this will provide a way to
add/delete and query the new APIs across different versions of Windows,
until new API's or documentation are available.

Signed-off-by: Alin Gabriel Serdean 
---
 lib/wmi.c | 95 
---
 1 file changed, 91 insertions(+), 4 deletions(-)

diff --git a/lib/wmi.c b/lib/wmi.c
index e6dc63cde..14451d591 100644
--- a/lib/wmi.c
+++ b/lib/wmi.c
@@ -203,6 +203,93 @@ wait_for_job(IWbemServices *psvc, wchar_t *job_path)
 return retval;
 }
 
+static boolean
+hns_delete(char *name)
+{
+VLOG_DBG("Trying to delete port via HNS API");
+char buffer[1];
+int count;
+count = snprintf(buffer, 1, "-NoLogo -NoProfile -NonInteractive"
+ "-Command \"try {Delete-OVSHNSInternalPort '%s'}"
+ "catch { exit 1 }; exit 0; \"", name);
+if (count < 0 || count > 1) {
+VLOG_WARN("Could not allocate memory for powershell delete 
command");
+return false;
+}
+VLOG_DBG("command = %s", buffer);
+DWORD res = 0;
+SHELLEXECUTEINFOA ShExecInfo;
+ShExecInfo.cbSize = sizeof(SHELLEXECUTEINFO);
+ShExecInfo.fMask = SEE_MASK_NOCLOSEPROCESS;
+ShExecInfo.hwnd = NULL;
+ShExecInfo.lpVerb = NULL;
+ShExecInfo.lpFile = "powershell.exe";
+ShExecInfo.lpParameters = buffer;
+ShExecInfo.lpDirectory = NULL;
+ShExecInfo.nShow = SW_HIDE;
+ShExecInfo.hInstApp = NULL;
+ShellExecuteExA();
+WaitForSingleObject(ShExecInfo.hProcess, 5);
+if (GetExitCodeProcess(ShExecInfo.hProcess, )) {
+if (res != 0) {
+VLOG_ERR("Powershell delete command failed with exit code: %d",
+ res);
+CloseHandle(ShExecInfo.hProcess);
+return false;
+}
+} else {
+VLOG_ERR("Failed to get exit code for powershell delete command."
+ "Last Error: %s", ovs_lasterror_to_string());
+CloseHandle(ShExecInfo.hProcess);
+return false;
+}
+CloseHandle(ShExecInfo.hProcess);
+return true;
+}
+
+static boolean
+hns_add(char *name)
+{
+VLOG_WARN("Trying to add port via HNS API");
+char buffer[1];
+int count;
+count = snprintf(buffer, 1, "-NoLogo -NoProfile -NonInteractive"
+ "-Command \"try {Add-OVSHNSInternalPort '%s'}"
+ "catch { exit 1 }; exit 0; \"", name);
+if (count < 0 || count > 1) {
+VLOG_WARN("Could not allocate memory for powershell add command");
+return false;
+}
+VLOG_WARN("command = %s", buffer);
+DWORD res = 0;
+SHELLEXECUTEINFOA ShExecInfo;
+ShExecInfo.cbSize = sizeof(SHELLEXECUTEINFO);
+ShExecInfo.fMask = SEE_MASK_NOCLOSEPROCESS;
+ShExecInfo.hwnd = NULL;
+ShExecInfo.lpVerb = NULL;
+ShExecInfo.lpFile = "powershell.exe";
+ShExecInfo.lpParameters = buffer;
+ShExecInfo.lpDirectory = NULL;
+ShExecInfo.nShow = SW_HIDE;
+ShExecInfo.hInstApp = NULL;
+ShellExecuteExA();
+WaitForSingleObject(ShExecInfo.hProcess, 5);
+if (GetExitCodeProcess(ShExecInfo.hProcess, )) {
+if (res != 0) {
+VLOG_ERR("Powershell add command failed with exit code: 

Re: [ovs-dev] [RFC PATCH v1 1/3] datapath-windows: Introduce HNS OVS calls

[Sairam Venugopal]

Hi Alin,

Since the hns.psm1 isn't officially supported by Microsoft, is it safe to use 
the script as part of the OVS repo?  Also, "Invoke-HNSRequest" isn't officially 
documented at this time. I understand that this is an RFC, but do you know if 
Microsoft plans to finalize this api? If not, I would suggest keeping hns.psm1 
out of the OVS repo and instead assume that the end-user has access to it. 
Otherwise, OVS will need to keep parity with the script in Microsoft's project.

Thanks,
Sairam


On 10/8/18, 4:26 PM, "ovs-dev-boun...@openvswitch.org on behalf of Alin 
Gabriel Serdean"  wrote:

We introduce a new powershell module for interacting with HNS (host network 
service):

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoft%2FSDN%2Fblob%2Fmaster%2FKubernetes%2Fwindows%2Fhns.psm1data=02%7C01%7Cvsairam%40vmware.com%7Cd3d913f61b40483be5c808d62d757f34%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636746380042797946sdata=rh%2FrirPPKSOUGvrHUhV36M2f83JUFX%2FkbGSCy%2FBvb%2BM%3Dreserved=0

In our repository this shall be named HNSHelper.psm1.

We also add five new commandlets in our OVS powershell module:
Disable-OVSOnHNSNetwork - disable OVS extension on a given HNS network.
Enable-OVSOnHNSNetwork - enable OVS extension on a given HNS network.
Get-OVSEnabledHNSNetworks - return the HNS network on which OVS is enabled.
Add-OVSHNSInternalPort - will add a new internal port with he name: `name`, 
on
 the HNS network, which has OVS enabled. This port
 shall use the host compartment.
Delete-OVSHNSInternalPort - will delete an internal port with name: `name` 
on a
HNS network which has OVS enabled.

Signed-off-by: Alin Gabriel Serdean 
---
 datapath-windows/automake.mk |   1 +
 datapath-windows/misc/HNSHelper.psm1 | 499 
+++
 datapath-windows/misc/OVS.psm1   |  79 +-
 3 files changed, 578 insertions(+), 1 deletion(-)
 create mode 100644 datapath-windows/misc/HNSHelper.psm1

diff --git a/datapath-windows/automake.mk b/datapath-windows/automake.mk
index 3820041f6..d98ab3c60 100644
--- a/datapath-windows/automake.mk
+++ b/datapath-windows/automake.mk
@@ -3,6 +3,7 @@ EXTRA_DIST += \
datapath-windows/Package/package.VcxProj.user \
datapath-windows/include/OvsDpInterfaceExt.h \
datapath-windows/include/OvsDpInterfaceCtExt.h \
+   datapath-windows/misc/HNSHelper.psm1 \
datapath-windows/misc/OVS.psm1 \
datapath-windows/misc/install.cmd \
datapath-windows/misc/uninstall.cmd \
diff --git a/datapath-windows/misc/HNSHelper.psm1 
b/datapath-windows/misc/HNSHelper.psm1
new file mode 100644
index 0..ac99889cf
--- /dev/null
+++ b/datapath-windows/misc/HNSHelper.psm1
@@ -0,0 +1,499 @@
+# SDN Sample Scripts  v.1.0
+#
+# Copyright (c) Microsoft Corporation
+#
+# All rights reserved. 
+#
+# MIT License
+#
+# Permission is hereby granted, free of charge, to any person obtaining a 
copy
+# of this software and associated documentation files (the ""Software""), 
to
+# deal in the Software without restriction, including without limitation 
the
+# rights to use, copy, modify, merge, publish, distribute, sublicense, 
and/or
+# sell copies of the Software, and to permit persons to whom the Software 
is
+# furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice shall be included 
in
+# all copies or substantial portions of the Software.
+#
+# THE SOFTWARE IS PROVIDED *AS IS*, WITHOUT WARRANTY OF ANY KIND, EXPRESS 
OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL 
THE
+# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS 
IN THE
+# SOFTWARE.
+#
+#
+# Global Initialize
+function Get-VmComputeNativeMethods()
+{
+$signature = @'
+ [DllImport("vmcompute.dll")]
+ public static extern void 
HNSCall([MarshalAs(UnmanagedType.LPWStr)] string method, 
[MarshalAs(UnmanagedType.LPWStr)] string path, 
[MarshalAs(UnmanagedType.LPWStr)] string request, 
[MarshalAs(UnmanagedType.LPWStr)] out string response);
+'@
+
+# Compile into runtime type
+try { return [VmCompute.PrivatePInvoke.NativeMethods] }
+catch { return (Add-Type -MemberDefinition $signature -Namespace 
VmCompute.PrivatePInvoke 

Re: [ovs-dev] [RFC PATCH v1 2/3] windows, installer: Add a new module file to the installer

[Sairam Venugopal]

Hi Alin,

Thanks for the patch. Can't we have the HNSHelper.psm1 be part of the OVS.psm1 
directory?

Thanks,
Sairam

On 10/8/18, 4:27 PM, "ovs-dev-boun...@openvswitch.org on behalf of Alin 
Gabriel Serdean"  wrote:

This patch adds the new powershell module HNSHelper.psm1 to the OVS windows
installer.


Signed-off-by: Alin Gabriel Serdean 
---
 windows/automake.mk   | 1 +
 windows/ovs-windows-installer/Product.wxs | 6 ++
 2 files changed, 7 insertions(+)

diff --git a/windows/automake.mk b/windows/automake.mk
index 80dca1467..79ffe4317 100644
--- a/windows/automake.mk
+++ b/windows/automake.mk
@@ -16,6 +16,7 @@ PTHREAD_TEMP_DIR=`echo "$(PTHREAD_LDFLAGS)" | sed 
's|^.\(.*\).$:\1||'`
 windows_installer: all
 #Userspace files needed for the installer
cp -f $(top_srcdir)/datapath-windows/misc/OVS.psm1 
windows/ovs-windows-installer/Services/OVS.psm1
+   cp -f $(top_srcdir)/datapath-windows/misc/HNSHelper.psm1 
windows/ovs-windows-installer/Services/HNSHelper.psm1
cp -f $(top_srcdir)/vswitchd/vswitch.ovsschema 
windows/ovs-windows-installer/Services/vswitch.ovsschema
cp -f $(top_srcdir)/vswitchd/ovs-vswitchd.exe 
windows/ovs-windows-installer/Services/ovs-vswitchd.exe
cp -f $(top_srcdir)/ovsdb/ovsdb-server.exe 
windows/ovs-windows-installer/Services/ovsdb-server.exe
diff --git a/windows/ovs-windows-installer/Product.wxs 
b/windows/ovs-windows-installer/Product.wxs
index ea1bc6896..9742c1773 100644
--- a/windows/ovs-windows-installer/Product.wxs
+++ b/windows/ovs-windows-installer/Product.wxs
@@ -67,6 +67,7 @@
   
   
   
+  
 
 
 
@@ -147,6 +148,7 @@
   
 
   
+  
 
   
 
@@ -156,6 +158,10 @@
 
   
 
+
+
+  
+
   
 
   
-- 
2.16.1.windows.1

___
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%7C31a7ab5d8248475b9ed208d62d75a018%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636746380628667609sdata=uTjgL%2BiwcWziG5eqVMEs0KWQkYAjwBQWlldRQxy2KhY%3Dreserved=0


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

Re: [ovs-dev] Bug open vswitch 2.10.9

[Ben Pfaff]

[adding the list back]

I don't see this error on master:

blp@sigabrt:~/nicira/ovs/_build(0)$ make -j10 check-oftest OFTFLAGS='-T 
actions.ForwardAll'
make  all-recursive
make[1]: Entering directory '/home/blp/nicira/ovs/_build'
Making all in datapath
make[2]: Entering directory '/home/blp/nicira/ovs/_build/datapath'
make[3]: Entering directory '/home/blp/nicira/ovs/_build/datapath'
make[3]: Leaving directory '/home/blp/nicira/ovs/_build/datapath'
make[2]: Leaving directory '/home/blp/nicira/ovs/_build/datapath'
make[2]: Entering directory '/home/blp/nicira/ovs/_build'
make[3]: Entering directory '/home/blp/nicira/ovs/_build/datapath'
make[3]: 'distfiles' is up to date.
make[3]: Leaving directory '/home/blp/nicira/ovs/_build/datapath'
make[2]: Leaving directory '/home/blp/nicira/ovs/_build'
make[1]: Leaving directory '/home/blp/nicira/ovs/_build'
ovsdb-tool create conf.db 
/home/blp/nicira/ovs/_build/../vswitchd/vswitch.ovsschema
ovsdb-server --detach --no-chdir --pidfile -vconsole:off --log-file 
--remote=punix:/home/blp/nicira/ovs/_build/sandbox/db.sock
ovs-vswitchd --detach --no-chdir --pidfile -vconsole:off --log-file 
--enable-dummy --disable-system -vvconn -vnetdev_dummy
ovs-vsctl --no-wait -- add-br br0 -- set bridge br0 datapath-type=dummy 
fail-mode=secure
ovs-vsctl --no-wait -- add-port br0 p1 -- set interface p1 type=dummy 
options:pstream=punix:/home/blp/nicira/ovs/_build/sandbox/p1
ovs-vsctl --no-wait -- add-port br0 p2 -- set interface p2 type=dummy 
options:pstream=punix:/home/blp/nicira/ovs/_build/sandbox/p2
ovs-vsctl --no-wait -- add-port br0 p3 -- set interface p3 type=dummy 
options:pstream=punix:/home/blp/nicira/ovs/_build/sandbox/p3
ovs-vsctl --no-wait -- add-port br0 p4 -- set interface p4 type=dummy 
options:pstream=punix:/home/blp/nicira/ovs/_build/sandbox/p4
ovs-vsctl -- set-controller br0 tcp:127.0.0.1:6653 -- set controller br0 
connection-mode=out-of-band max-backoff=1000
oft -P ovs-dummy -T actions.ForwardAll
WARNING: No route found for IPv6 destination :: (no default route?)
actions.ForwardAll ... ok

--
Ran 1 test in 0.897s

OK

--
Logs may be found under /home/blp/nicira/ovs/_build/sandbox, e.g.:
/home/blp/nicira/ovs/_build/sandbox/oft.log
/home/blp/nicira/ovs/_build/sandbox/ovs-vswitchd.log
/home/blp/nicira/ovs/_build/sandbox/ovsdb-server.log
--
blp@sigabrt:~/nicira/ovs/_build(0)$ 


On Fri, Oct 19, 2018 at 11:51:44AM +0200, asma berriri wrote:
> Hey,
> This is the error
> FAIL: actions.ForwardAll
> --
> Traceback (most recent call last):
>   File "/home/asmab/oftest/tests/actions.py", line 166, in runTest
> verify_packets(self, pkt, yes_ports)
>   File "/home/asmab/oftest/src/python/oftest/testutils.py", line 1770, in
> verify_packets
> verify_packet(test, pkt, ofport)
>   File "/home/asmab/oftest/src/python/oftest/testutils.py", line 1728, in
> verify_packet
> test.assertTrue(rcv_pkt != None, "Did not receive pkt on %r" % ofport)
>   File "/home/asmab/oftest/src/python/oftest/base_tests.py", line 97, in
> assertTrue
> unittest.TestCase.assertTrue(self, cond, msg)
> AssertionError: Did not receive pkt on 2
> 
> 
> On Thu, Oct 18, 2018 at 11:14 PM Ben Pfaff  wrote:
> 
> > On Thu, Oct 18, 2018 at 03:03:08PM +0200, asma berriri wrote:
> > > I tried to run the testing tool "oftest" to ovs (2.10.90) and I got an
> > > error message for the forwardAll actions.
> > > Is it a bug?
> >
> > Can you provide the full oftest output?
> >
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v8 0/3] Support dynamic rebalancing of offloaded flows

[Sriharsha Basavapatna via dev]

Hi Eelco,

Thanks for your review comments. Please see my response below. The
patch-set got merged earlier today.  We will address your comments in
subsequent bug-fix patches.

On Fri, Oct 19, 2018 at 1:27 AM Eelco Chaudron  wrote:
>
>
>
> On 18 Oct 2018, at 18:13, Sriharsha Basavapatna via dev wrote:
>
> > With the current OVS offload design, when an offload-device fails to
> > add a
> > flow rule and returns an error, OVS adds the rule to the kernel
> > datapath.
> > The flow gets processed by the kernel datapath for the entire life of
> > that
> > flow. This is fine when an error is returned by the device due to lack
> > of
> > support for certain keys or actions.
> >
> > But when an error is returned due to temporary conditions such as lack
> > of
> > resources to add a flow rule, the flow continues to be processed by
> > kernel
> > even when resources become available later. That is, those flows never
> > get
> > offloaded again. This problem becomes more pronounced when a flow that
> > has
> > been initially offloaded may have a smaller packet rate than a later
> > flow
> > that could not be offloaded due to lack of resources. This leads to
> > inefficient use of HW resources and wastage of host CPU cycles.
> >
> > This patch-set addresses this issue by providing a way to detect
> > temporary
> > offload resource constraints (Out-Of-Resource or OOR condition) and to
> > selectively and dynamically offload flows with a higher
> > packets-per-second
> > (pps) rate. This dynamic rebalancing is done periodically on netdevs
> > that
> > are in OOR state until resources become available to offload all
> > pending
> > flows.
> >
> > The patch-set involves the following changes at a high level:
> >
> > 1. Detection of Out-Of-Resources (OOR) condition on an offload-capable
> >netdev.
> > 2. Gathering flow offload selection criteria for all flows on an OOR
> > netdev;
> >i.e, packets-per-second (pps) rate of flows for offloaded and
> >non-offloaded (pending) flows.
> > 3. Dynamically replacing offloaded flows with a lower pps-rate, with
> >non-offloaded flows with a higher pps-rate, on an OOR netdev. A new
> >OpenvSwitch configuration option - "offload-rebalance" to enable
> >this policy.
> >
> > Cost/benefits data points:
> >
> > 1. Rough cost of the new rebalancing, in terms of CPU time:
> >
> >Ran a test that replaced 256 low pps-rate flows(pings) with 256
> > high
> >pps-rate flows(iperf), in a system with 4 cpus (Intel Xeon E5 @
> > 2.40GHz;
> >2 cores with hw threads enabled, rest disabled). The data showed
> > that cpu
> >utilization increased by about ~20%. This increase occurs during
> > the
> >specific second in which rebalancing is done. And subsequently
> > (from the
> >next second), cpu utilization decreases significantly due to
> > offloading
> >of higher pps-rate flows. So effectively there's a bump in cpu
> > utilization
> >at the time of rebalancing, that is more than compensated by
> > reduced cpu
> >utilization once the right flows get offloaded.
> >
> > 2. Rough benefits to the user in terms of offload performance:
> >
> >The benefits to the user is reduced cpu utilization in the host,
> > since
> >higher pps-rate flows get offloaded, replacing lower pps-rate
> > flows.
> >Replacing a single offloaded flood ping flow with an iperf flow
> > (multiple
> >connections), shows that the cpu %used that was originally 100% on
> > a
> >single cpu (rebalancing disabled) goes down to 35% (rebalancing
> > enabled).
> >That is, cpu utilization decreased 65% after rebalancing.
> >
> > 3. Circumstances under which the benefits would show up:
> >
> >The rebalancing benefits would show up once offload resources are
> >exhausted and new flows with higher pps-rate are initiated, that
> > would
> >otherwise be handled by kernel datapath costing host cpu cycles.
> >
> >This can be observed using 'ovs appctl dpctl/ dump-flows' command.
> > Prior
> >to rebalancing, any high pps-rate flows that couldn't be offloaded
> > due to
> >resource crunch would show up in the output of 'dump-flows
> > type=ovs' and
> >after rebalancing such flows would appear in the output of
> >'dump-flows type=offloaded'.
> >
>
> Before I review the individual patches, hope to do this tomorrow, I have
> some general concerns/comments.
>
> Once committed will this feature be marked double experimental? Just
> want to clarify if it goes in as part of HW offload the experimental tag
> for this is not removed once HW offload becomes mainstream.

I'm not sure if it will be marked experimental. But if it does get
marked, then depending on how this feature evolves by the time HW
offload becomes mainstream, the tag could be removed ? Ben, Simon, any
suggestions on this ?

>
> Currently, in OOR state both phases (insert, and rebalance) are ran.
> Rather than have offload-rebalance true, or false. Maybe we can have,
> disable, retry, 

Re: [ovs-dev] OVS DPDK: dpdk_merge pull request for branch-2.10

[Ben Pfaff]

On Fri, Oct 19, 2018 at 04:07:42PM +, Stokes, Ian wrote:
> Hi Ben,
> 
> The following changes since commit 22595b3b763b9eaaf661eec40cc6926557c8696b:
> 
>   Revert "Work around Python/C JSON unicode differences" (2018-10-15 14:44:18 
> -0700)
> 
> are available in the git repository at:
> 
>   https://github.com/istokes/ovs dpdk_merge_2_10
> 
> for you to fetch changes up to 3b2e6400ec58aa4fe8dd453c1c4a255287ef35f3:
> 
>   dpdk: Use DPDK 17.11.4 release. (2018-10-19 11:59:42 +0100)

Thanks for the pull requests.  I merged all of them for 2.6 to 2.10.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] OVS DPDK: dpdk_merge pull request for master

[Ben Pfaff]

On Fri, Oct 19, 2018 at 04:07:28PM +, Stokes, Ian wrote:
> Hi Ben,
> 
> The following changes since commit 57924fc91c899ee955e30b36fed92a27a73b2ac1:
> 
>   revalidator: Rebalance offloaded flows based on the pps rate (2018-10-19 
> 11:27:52 +0200)
> 
> are available in the git repository at:
> 
>   https://github.com/istokes/ovs dpdk_merge
> 
> for you to fetch changes up to bafb398bf6df8d5542fa41762ef68fe0df618b84:
> 
>   dpdk: Use DPDK 17.11.4 release. (2018-10-19 11:59:08 +0100)

Merged, thank you!
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] OVN based distributed virtual routing for VLAN backed networks

[Guru Shetty]

On Tue, 16 Oct 2018 at 15:43, Ankur Sharma  wrote:

> Hi,
>
> We have done some effort in evaluating usage of OVN for
> Distributed Virtual Routing (DVR) for vlan backed networks.
>

Would you mind explaining the above statement with a lot of details? I
would like to understand the problem well before looking at the proposed
solution.


>
> We would like to take it forward with the community.
>
> We understand that some of the work could be overlapping with existing
> patches in review.
>
> We would appreciate the feedback and would be happy to update our patches
> to avoid known overlaps.
>
> This email explains the proposal. We will be following it up with patches.
> Each "CODE CHANGES" section summarizes the change that corresponding patch
> would have.
>
>
> DISTRIBUTED VIRTUAL ROUTING FOR VLAN BACKED NETWORKS
> ==
>
>
> 1. OVN Bridge Deployment
> 
>
> Our design follows following ovn-bridge deployment model
> (please refer to figure OVN Bridge deployment).
> i. br-int ==> OVN managed bridge.
>br-pif ==> Learning Bridge, where physical NICs will be connected.
>
>ii. Any packet that should be on physical network, will travel from
> BR-INT
>to BR-PIF, via patch ports (localnet ports).
>
> 2. Layer 2
> -
>
>DESIGN:
>~~~
>a. Leverage on localnet logical port type as path port between br-int
> and
>br-pif.
>b. Each VLAN backed logical switch will have a localnet port connected
>to it.
>c. Tagging and untagging of vlan headers happens at localnet port
> boundary.
>
>PIPELINE EXECUTION:
>~~~
>a. Unlike geneve encap based solution, where we execute ingress
> pipeline on
>source chassis and egress pipeline on destination chassis, for vlan
>backed logical switches, packet will go through ingress pipeline
>on destination chassis as well.
>
>PACKET FLOW (Figure 1. shows topology and Figure 2. shows the packet
> flow):
>
>  ~~~
>a. VM sends unicast traffic (destined to VM2_MAC) to br-int.
>b. For br-int, destination mac is not local, hence it will forward it to
>localnet port (by design), which is attached to br-pif. This is
>the stage at which vlan tag is added. Br-pif forwards the packet
>to physical interface.
>c. br-pif on destination chassis sends the received traffic to
> patch-ports
>on br-int (as unicast or unknown unicast).
>d. br-int does vlan tag check, strips the vlan header and sends
>the packet to ingress pipeline of the corresponding datapath.
>
>
>KEY DIFFERENCES AS COMPARED TO OVERLAY:
>~~~
>a. No encapsulation.
>b. Both ingress and egress pipelines of logical switch are executed on
>both source and destination hypervisor (unlike overlay where ingress
>pipeline is executed on source hypervisor and egress on
> destination).
>
>CODE CHANGES:
>~
>a. ovn-nb.ovsschema:
> 1. Add a new column to table Logical_Switch.
> 2. Column name would be "type".
> 3. Values would be either "vlan" or "overlay", with "overlay"
> being default.
>
>b. ovn-sbctl:
> 1. Add a new cli which sets the "type" of logical-switch.
> ovn-nbctl ls-set-network-type SWITCH TYPE
>
>c. ovn-northd:
> 1. Add a new enum to ovn_datapath struct, which will indicate
> if logical_switch datapath type is overlay or vlan.
> 2. Populate a new key value pair in southbound database for
> Datapath
> Bindings of Logical_Switch.
> 3. Key value pair: ,
> default
> will be overlay.
>
>
> 3. Layer 3 East West
> 
>
>DESIGN:
>~~~
>a. Since the router port is distributed and there is no encapsulation,
>hence packets with router port mac as source mac cannot go on wire.
>b. We propose replacing router port mac with a chassis specific mac,
>whenever packet goes on wire.
>c. Number of chassis_mac per chassis could be dependent on number of
>physical nics and corresponding bond policy  on br-pif.
>
>   As of now, we propose only one chassis_mac per chassis
>   (shared by all resident logical routers). However, we are analyzing
>   if br-pif's bond policy would require more macs per chassis.
>
>PIPELINE EXECUTION:
>~~~
>a. For a DVR E-W flow, both ingress and egress pipelines for
> logical_router
>will execute on source chassis only.
>
>PACKET FLOW (Figure 3. shows topology and Figure 4. shows the packet
> flow):
>
>  ~~~
>a. VM1 sends packet (destined to IP2), to br-int.
>b. On Source hypervisor, packet goes 

[ovs-dev] OVS DPDK: dpdk_merge pull request for branch-2.6

[Stokes, Ian]

Hi Ben,

The following changes since commit 1dea6844708fb4b14024ff7dbdf78c9aa090db80:

  test-hash: Fix unaligned pointer value error. (2018-10-16 15:21:06 -0700)

are available in the git repository at:

  https://github.com/istokes/ovs dpdk_merge_2_6

for you to fetch changes up to 55162e59c1fba058e221a3ba79f6c87fdcd9d207:

  dpif-netdev.at: Add missing backslash. (2018-10-19 11:30:15 +0100)


Ilya Maximets (1):
  dpif-netdev.at: Add missing backslash.

Xu Binbin (1):
  netdev-dpdk: Support the link speed of XL710

 lib/netdev-dpdk.c|  3 +++
 tests/dpif-netdev.at | 12 
 2 files changed, 11 insertions(+), 4 deletions(-)

Thanks
Ian

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

[ovs-dev] OVS DPDK: dpdk_merge pull request for branch-2.7

[Stokes, Ian]

Hi Ben,

The following changes since commit da5fe1070e8083bf98f688cf0368540e592bed1d:

  test-hash: Fix unaligned pointer value error. (2018-10-16 15:21:38 -0700)

are available in the git repository at:

  https://github.com/istokes/ovs dpdk_merge_2_7

for you to fetch changes up to b173255ce7984474a310c32ba6e8763438656505:

  dpdk: Use DPDK 16.11.8 release. (2018-10-19 12:01:18 +0100)


Ian Stokes (1):
  dpdk: Use DPDK 16.11.8 release.

Ilya Maximets (1):
  dpif-netdev.at: Add missing backslash.

 .travis/linux-build.sh   |  2 +-
 Documentation/faq/releases.rst   |  2 +-
 Documentation/intro/install/dpdk.rst |  6 +++---
 Documentation/topics/dpdk/vhost-user.rst |  6 +++---
 tests/dpif-netdev.at | 12 
 5 files changed, 16 insertions(+), 12 deletions(-)

Thanks
Ian

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

[ovs-dev] OVS DPDK: dpdk_merge pull request for branch-2.8

[Stokes, Ian]

Hi Ben,

The following changes since commit 597df6459f3b114905773c4f4dcf7e5f511cb808:

  tests: Fix conntrack tests expected results. (2018-10-15 15:25:31 -0700)

are available in the git repository at:

  https://github.com/istokes/ovs dpdk_merge_2_8

for you to fetch changes up to 9b00fbfb30bb60db3776cae87a2edaebef83bbd5:

  dpif-netdev.at: Add missing backslash. (2018-10-19 11:31:52 +0100)


Ilya Maximets (1):
  dpif-netdev.at: Add missing backslash.

 tests/dpif-netdev.at | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

Thanks
Ian

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

[ovs-dev] OVS DPDK: dpdk_merge pull request for branch-2.9

[Stokes, Ian]

Hi Ben,

The following changes since commit bcd2fa997da2173fa4075af50474d1278e7d4396:

  Revert "Work around Python/C JSON unicode differences" (2018-10-15 14:44:37 
-0700)

are available in the git repository at:

  https://github.com/istokes/ovs dpdk_merge_2_9

for you to fetch changes up to fb9ab88a8d6869f762f9cf7dfc3bdfddabe33f78:

  dpdk: Use DPDK 17.11.4 release. (2018-10-19 14:43:04 +0100)


Ian Stokes (1):
  dpdk: Use DPDK 17.11.4 release.

Ilya Maximets (1):
  dpif-netdev.at: Add missing backslash.

 .travis/linux-build.sh   |  2 +-
 Documentation/faq/releases.rst   |  4 ++--
 Documentation/intro/install/dpdk.rst |  8 
 Documentation/topics/dpdk/vhost-user.rst |  6 +++---
 tests/dpif-netdev.at | 12 
 5 files changed, 18 insertions(+), 14 deletions(-)

Thanks
Ian

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

[ovs-dev] OVS DPDK: dpdk_merge pull request for branch-2.10

[Stokes, Ian]

Hi Ben,

The following changes since commit 22595b3b763b9eaaf661eec40cc6926557c8696b:

  Revert "Work around Python/C JSON unicode differences" (2018-10-15 14:44:18 
-0700)

are available in the git repository at:

  https://github.com/istokes/ovs dpdk_merge_2_10

for you to fetch changes up to 3b2e6400ec58aa4fe8dd453c1c4a255287ef35f3:

  dpdk: Use DPDK 17.11.4 release. (2018-10-19 11:59:42 +0100)


Ian Stokes (1):
  dpdk: Use DPDK 17.11.4 release.

Ilya Maximets (1):
  dpif-netdev.at: Add missing backslash.

 .travis/linux-build.sh   |  2 +-
 Documentation/faq/releases.rst   |  6 +++---
 Documentation/intro/install/dpdk.rst |  8 
 Documentation/topics/dpdk/vhost-user.rst |  6 +++---
 tests/dpif-netdev.at | 12 
 5 files changed, 19 insertions(+), 15 deletions(-)

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

[ovs-dev] OVS DPDK: dpdk_merge pull request for master

[Stokes, Ian]

Hi Ben,

The following changes since commit 57924fc91c899ee955e30b36fed92a27a73b2ac1:

  revalidator: Rebalance offloaded flows based on the pps rate (2018-10-19 
11:27:52 +0200)

are available in the git repository at:

  https://github.com/istokes/ovs dpdk_merge

for you to fetch changes up to bafb398bf6df8d5542fa41762ef68fe0df618b84:

  dpdk: Use DPDK 17.11.4 release. (2018-10-19 11:59:08 +0100)


Ian Stokes (1):
  dpdk: Use DPDK 17.11.4 release.

Ilya Maximets (2):
  dpif-netdev.at: Add missing backslash.
  dpif-netdev.at: Add datapath flow modification test.

 .travis/linux-build.sh   |  2 +-
 Documentation/faq/releases.rst   |  6 +++---
 Documentation/intro/install/dpdk.rst |  8 
 Documentation/topics/dpdk/vhost-user.rst |  6 +++---
 tests/dpif-netdev.at | 66 
++
 5 files changed, 73 insertions(+), 15 deletions(-)

Thanks
Ian

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

Re: [ovs-dev] [PATCH v8 0/3] Support dynamic rebalancing of offloaded flows

[Eelco Chaudron]

Hi Simon,

You might have missed my general comments email before you committed the 
patchset to master.


Just now I also sent my full review, and it looks like there is one 
nasty memory trashing one in 3/3 which need fixing. It’s the 
x2nrealloc() always allocating 1 entry, but we write to other offsets.


//Eelco


On 19 Oct 2018, at 11:28, Simon Horman wrote:

On Thu, Oct 18, 2018 at 09:43:11PM +0530, Sriharsha Basavapatna via 
dev wrote:
With the current OVS offload design, when an offload-device fails to 
add a
flow rule and returns an error, OVS adds the rule to the kernel 
datapath.
The flow gets processed by the kernel datapath for the entire life of 
that
flow. This is fine when an error is returned by the device due to 
lack of

support for certain keys or actions.

But when an error is returned due to temporary conditions such as 
lack of
resources to add a flow rule, the flow continues to be processed by 
kernel
even when resources become available later. That is, those flows 
never get
offloaded again. This problem becomes more pronounced when a flow 
that has
been initially offloaded may have a smaller packet rate than a later 
flow

that could not be offloaded due to lack of resources. This leads to
inefficient use of HW resources and wastage of host CPU cycles.

This patch-set addresses this issue by providing a way to detect 
temporary
offload resource constraints (Out-Of-Resource or OOR condition) and 
to
selectively and dynamically offload flows with a higher 
packets-per-second
(pps) rate. This dynamic rebalancing is done periodically on netdevs 
that
are in OOR state until resources become available to offload all 
pending

flows.

The patch-set involves the following changes at a high level:

1. Detection of Out-Of-Resources (OOR) condition on an 
offload-capable

   netdev.
2. Gathering flow offload selection criteria for all flows on an OOR 
netdev;

   i.e, packets-per-second (pps) rate of flows for offloaded and
   non-offloaded (pending) flows.
3. Dynamically replacing offloaded flows with a lower pps-rate, with
   non-offloaded flows with a higher pps-rate, on an OOR netdev. A 
new

   OpenvSwitch configuration option - "offload-rebalance" to enable
   this policy.

Cost/benefits data points:

1. Rough cost of the new rebalancing, in terms of CPU time:

   Ran a test that replaced 256 low pps-rate flows(pings) with 256 
high
   pps-rate flows(iperf), in a system with 4 cpus (Intel Xeon E5 @ 
2.40GHz;
   2 cores with hw threads enabled, rest disabled). The data showed 
that cpu
   utilization increased by about ~20%. This increase occurs during 
the
   specific second in which rebalancing is done. And subsequently 
(from the
   next second), cpu utilization decreases significantly due to 
offloading
   of higher pps-rate flows. So effectively there's a bump in cpu 
utilization
   at the time of rebalancing, that is more than compensated by 
reduced cpu

   utilization once the right flows get offloaded.

2. Rough benefits to the user in terms of offload performance:

   The benefits to the user is reduced cpu utilization in the host, 
since
   higher pps-rate flows get offloaded, replacing lower pps-rate 
flows.
   Replacing a single offloaded flood ping flow with an iperf flow 
(multiple
   connections), shows that the cpu %used that was originally 100% on 
a
   single cpu (rebalancing disabled) goes down to 35% (rebalancing 
enabled).

   That is, cpu utilization decreased 65% after rebalancing.

3. Circumstances under which the benefits would show up:

   The rebalancing benefits would show up once offload resources are
   exhausted and new flows with higher pps-rate are initiated, that 
would

   otherwise be handled by kernel datapath costing host cpu cycles.

   This can be observed using 'ovs appctl dpctl/ dump-flows' command. 
Prior
   to rebalancing, any high pps-rate flows that couldn't be offloaded 
due to
   resource crunch would show up in the output of 'dump-flows 
type=ovs' and

   after rebalancing such flows would appear in the output of
   'dump-flows type=offloaded'.


Thanks, applied to master.
___
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 v8 3/3] revalidator: Rebalance offloaded flows based on the pps rate

[Eelco Chaudron]

On 18 Oct 2018, at 18:13, Sriharsha Basavapatna via dev wrote:

This is the third patch in the patch-set to support dynamic 
rebalancing

of offloaded flows.

The dynamic rebalancing functionality is implemented in this patch. 
The
ukeys that are not scheduled for deletion are obtained and passed as 
input

to the rebalancing routine. The rebalancing is done in the context of
revalidation leader thread, after all other revalidator threads are
done with gathering rebalancing data for flows.

For each netdev that is in OOR state, a list of flows - both offloaded
and non-offloaded (pending) - is obtained using the ukeys. For each 
netdev
that is in OOR state, the flows are grouped and sorted into offloaded 
and

pending flows.  The offloaded flows are sorted in descending order of
pps-rate, while pending flows are sorted in ascending order of 
pps-rate.


The rebalancing is done in two phases. In the first phase, we try to
offload all pending flows and if that succeeds, the OOR state on the 
device
is cleared. If some (or none) of the pending flows could not be 
offloaded,
then we start replacing an offloaded flow that has a lower pps-rate 
than
a pending flow, until there are no more pending flows with a higher 
rate
than an offloaded flow. The flows that are replaced from the device 
are

added into kernel datapath.

A new OVS configuration parameter "offload-rebalance", is added to 
ovsdb.

The default value of this is "false". To enable this feature, set the
value of this parameter to "true", which provides packets-per-second
rate based policy to dynamically offload and un-offload flows.

Note: This option can be enabled only when 'hw-offload' policy is 
enabled.

It also requires 'tc-policy' to be set to 'skip_sw'; otherwise, flow
offload errors (specifically ENOSPC error this feature depends on) 
reported

by an offloaded device are supressed by TC-Flower kernel module.

Signed-off-by: Sriharsha Basavapatna 


Co-authored-by: Venkat Duvvuru 
Signed-off-by: Venkat Duvvuru 
Reviewed-by: Sathya Perla 
Reviewed-by: Simon Horman 
Reviewed-by: Ben Pfaff 
---
 NEWS  |   3 +
 lib/dpif-netdev.c |   3 +-
 lib/dpif-netlink.c|  29 ++-
 lib/dpif-provider.h   |   8 +-
 lib/dpif.c|  30 ++-
 lib/dpif.h|  12 +-
 lib/netdev-provider.h |   7 +-
 lib/netdev.c  |  62 -
 lib/netdev.h  |   1 +
 ofproto/ofproto-dpif-upcall.c | 446 
+-

 vswitchd/vswitch.xml  |  21 ++
 11 files changed, 592 insertions(+), 30 deletions(-)

diff --git a/NEWS b/NEWS
index 33b4d8a23..846b46fb5 100644
--- a/NEWS
+++ b/NEWS
@@ -8,6 +8,9 @@ Post-v2.10.0
  as the default timeout for control utilities.
- ovn:
  * ovn-ctl: allow passing user:group ids to the OVN daemons.
+   - ovs-vswitchd:
+ * New configuration option "offload-rebalance", that enables 
dynamic

+   rebalancing of offloaded flows.


 v2.10.0 - xx xxx 
diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index 7c0300cc5..1c01d2278 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -3689,7 +3689,8 @@ dpif_netdev_execute(struct dpif *dpif, struct 
dpif_execute *execute)

 }

 static void
-dpif_netdev_operate(struct dpif *dpif, struct dpif_op **ops, size_t 
n_ops)
+dpif_netdev_operate(struct dpif *dpif, struct dpif_op **ops, size_t 
n_ops,

+enum dpif_offload_type offload_type OVS_UNUSED)
 {
 size_t i;

diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c
index b9ce9cbe2..2e01f5750 100644
--- a/lib/dpif-netlink.c
+++ b/lib/dpif-netlink.c
@@ -2281,7 +2281,8 @@ dpif_netlink_operate_chunks(struct dpif_netlink 
*dpif, struct dpif_op **ops,

 }

 static void
-dpif_netlink_operate(struct dpif *dpif_, struct dpif_op **ops, size_t 
n_ops)
+dpif_netlink_operate(struct dpif *dpif_, struct dpif_op **ops, size_t 
n_ops,

+ enum dpif_offload_type offload_type)
 {
 struct dpif_netlink *dpif = dpif_netlink_cast(dpif_);
 struct dpif_op *new_ops[OPERATE_MAX_OPS];
@@ -2289,7 +2290,12 @@ dpif_netlink_operate(struct dpif *dpif_, struct 
dpif_op **ops, size_t n_ops)

 int i = 0;
 int err = 0;

-if (netdev_is_flow_api_enabled()) {
+if (offload_type == DPIF_OFFLOAD_ALWAYS && 
!netdev_is_flow_api_enabled()) {

+VLOG_DBG("Invalid offload_type: %d", offload_type);


Here we are not returning any errors just a silent return, should we 
return EINVAL instead?



+return;
+}
+
+if (offload_type != DPIF_OFFLOAD_NEVER && 
netdev_is_flow_api_enabled()) {

 while (n_ops > 0) {
 count = 0;

@@ -2298,6 +2304,23 @@ dpif_netlink_operate(struct dpif *dpif_, struct 
dpif_op **ops, size_t n_ops)


 err = try_send_to_netdev(dpif, op);
 if (err && err != EEXIST) {
+if (offload_type == DPIF_OFFLOAD_ALWAYS) {
+/* We got an error while 

Re: [ovs-dev] [PATCH v8 2/3] revalidator: Gather packets-per-second rate of flows

[Eelco Chaudron]

On 18 Oct 2018, at 18:13, Sriharsha Basavapatna via dev wrote:

This is the second patch in the patch-set to support dynamic 
rebalancing

of offloaded flows.

The packets-per-second (pps) rate for each flow is computed in the 
context
of revalidator threads when the flow stats are retrieved. The pps-rate 
is

computed only after a flow is revalidated and is not scheduled for
deletion. The parameters used to compute pps and the pps itself are 
saved

in udpif_key since they need to be persisted across iterations of
rebalancing.


Was there a specific reason to go with pps and not bytes per second? 
Asking as larger packets might need more copying around vs a lot of 
small packets need more flow processing.


Signed-off-by: Sriharsha Basavapatna 


Co-authored-by: Venkat Duvvuru 
Signed-off-by: Venkat Duvvuru 
Reviewed-by: Sathya Perla 
Reviewed-by: Simon Horman 
Reviewed-by: Ben Pfaff 
---
 lib/dpif-provider.h   |  1 +
 ofproto/ofproto-dpif-upcall.c | 51 
+++

 2 files changed, 52 insertions(+)

diff --git a/lib/dpif-provider.h b/lib/dpif-provider.h
index 873b6e3d4..7a71f5c0a 100644
--- a/lib/dpif-provider.h
+++ b/lib/dpif-provider.h
@@ -39,6 +39,7 @@ struct dpif {
 char *full_name;
 uint8_t netflow_engine_type;
 uint8_t netflow_engine_id;
+long long int current_ms;
 };

 void dpif_init(struct dpif *, const struct dpif_class *, const char 
*name,
diff --git a/ofproto/ofproto-dpif-upcall.c 
b/ofproto/ofproto-dpif-upcall.c

index 6079f..a372d6252 100644
--- a/ofproto/ofproto-dpif-upcall.c
+++ b/ofproto/ofproto-dpif-upcall.c
@@ -42,6 +42,8 @@
 #include "tunnel.h"
 #include "unixctl.h"
 #include "openvswitch/vlog.h"
+#include "lib/dpif-provider.h"
+#include "lib/netdev-provider.h"

 #define MAX_QUEUE_LENGTH 512
 #define UPCALL_MAX_BATCH 64
@@ -304,6 +306,13 @@ struct udpif_key {

 uint32_t key_recirc_id;   /* Non-zero if reference is held by the 
ukey. */
 struct recirc_refs recircs;  /* Action recirc IDs with references 
held. */

+
+#define OFFL_REBAL_INTVL_MSEC  3000	/* dynamic offload rebalance freq 
*/

+bool offloaded;/* True if flow is offloaded */
+uint64_t flow_pps_rate;/* Packets-Per-Second rate */
+long long int flow_time;   /* last pps update time */
+uint64_t flow_packets; /* #pkts seen in interval */
+uint64_t flow_backlog_packets;	/* prev-mode #pkts (offl or 
kernel) */

 };

 /* Datapath operation with optional ukey attached. */
@@ -1667,6 +1676,10 @@ ukey_create__(const struct nlattr *key, size_t 
key_len,

 ukey->stats.used = used;
 ukey->xcache = NULL;

+ukey->offloaded = false;
+ukey->flow_time = 0;
+ukey->flow_packets = ukey->flow_backlog_packets = 0;
+


For clarity I think we need to set the flow_pps_rate to 0 also.


 ukey->key_recirc_id = key_recirc_id;
 recirc_refs_init(>recircs);
 if (xout) {
@@ -2442,6 +2455,39 @@ reval_op_init(struct ukey_op *op, enum 
reval_result result,

 }
 }

+static uint64_t
+udpif_flow_packet_delta(struct udpif_key *ukey, const struct 
dpif_flow *f)

+{
+return f->stats.n_packets + ukey->flow_backlog_packets -
+ukey->flow_packets;


It does not make sense to me why the flow_backlog_packets get added 
here, and also to the flow_packets? See also below.



+}
+
+static long long int
+udpif_flow_time_delta(struct udpif *udpif, struct udpif_key *ukey)
+{
+return (udpif->dpif->current_ms - ukey->flow_time) / 1000;
+}
+
+/* Gather pps-rate for the given dpif_flow and save it in its ukey */
+static void
+udpif_update_flow_pps(struct udpif *udpif, struct udpif_key *ukey,
+  const struct dpif_flow *f)
+{
+uint64_t pps;
+
+/* Update pps-rate only when we are close to rebalance interval 
*/
+if (udpif->dpif->current_ms - ukey->flow_time < 
OFFL_REBAL_INTVL_MSEC) {

+return;
+}
+
+ukey->offloaded = f->attrs.offloaded;
+pps = udpif_flow_packet_delta(ukey, f) /
+udpif_flow_time_delta(udpif, ukey);
+ukey->flow_pps_rate = pps;
+ukey->flow_packets = ukey->flow_backlog_packets + 
f->stats.n_packets;


In the help the flow_packets is described as "#pkts seen in interval" 
why do we need to add flow_backlog_packets? They are from the previous 
mode? See also comment above.



+ukey->flow_time = udpif->dpif->current_ms;
+}
+
 static void
 revalidate(struct revalidator *revalidator)
 {
@@ -2550,6 +2596,11 @@ revalidate(struct revalidator *revalidator)
 }
 ukey->dump_seq = dump_seq;

+if (netdev_is_offload_rebalance_policy_enabled() &&
+result != UKEY_DELETE) {
+udpif_update_flow_pps(udpif, ukey, f);
+}
+
 if (result != UKEY_KEEP) {
 /* Takes ownership of 'recircs'. */
 reval_op_init([n_ops++], result, udpif, ukey, 
,

--
2.18.0.rc1.1.g6f333ff

Re: [ovs-dev] [PATCH v8 1/3] dpif-netlink: Detect Out-Of-Resource condition on a netdev

[Eelco Chaudron]

On 18 Oct 2018, at 18:13, Sriharsha Basavapatna via dev wrote:

This is the first patch in the patch-set to support dynamic 
rebalancing

of offloaded flows.

The patch detects OOR condition on a netdev port when ENOSPC error is
returned by TC-Flower while adding a flow rule. A new structure is 
added
to the netdev called "netdev_hw_info", to store OOR related 
information

required to perform dynamic offload-rebalancing.

Signed-off-by: Sriharsha Basavapatna 


Co-authored-by: Venkat Duvvuru 
Signed-off-by: Venkat Duvvuru 
Reviewed-by: Sathya Perla 
Reviewed-by: Simon Horman 
Reviewed-by: Ben Pfaff 
---
 lib/dpif-netlink.c| 18 +-
 lib/flow.c| 25 +
 lib/flow.h|  1 +
 lib/netdev-provider.h | 11 +++
 lib/netdev.c  | 34 ++
 lib/netdev.h  |  3 +++
 6 files changed, 91 insertions(+), 1 deletion(-)

diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c
index e6d5a6ec5..b9ce9cbe2 100644
--- a/lib/dpif-netlink.c
+++ b/lib/dpif-netlink.c
@@ -2178,7 +2178,23 @@ parse_flow_put(struct dpif_netlink *dpif, 
struct dpif_flow_put *put)


 VLOG_DBG("added flow");
 } else if (err != EEXIST) {
-VLOG_ERR_RL(, "failed to offload flow: %s", 
ovs_strerror(err));

+struct netdev *oor_netdev = NULL;
+if (err == ENOSPC && 
netdev_is_offload_rebalance_policy_enabled()) {

+/*
+ * We need to set OOR on the input netdev (i.e, 'dev') 
for the
+ * flow. But if the flow has a tunnel attribute (i.e, 
decap action,
+ * with a virtual device like a VxLAN interface as its 
in-port),
+ * then lookup and set OOR on the underlying tunnel 
(real) netdev.

+ */
+oor_netdev = flow_get_tunnel_netdev();
+if (!oor_netdev) {
+/* Not a 'tunnel' flow */
+oor_netdev = dev;
+}
+netdev_set_hw_info(oor_netdev, HW_INFO_TYPE_OOR, true);


Why not just oor_netdev->hw_info.oor = true, see also below.

I have a general comment, don't know where to put it, so I put it here. 
Some hardware might have multiple tables. If one type of table is full 
the ENOSPC might be returned, but it does not mean all type of flows can 
no longer be offloaded. This might be a situation to think about.



+}
+VLOG_ERR_RL(, "failed to offload flow: %s: %s", 
ovs_strerror(err),

+(oor_netdev ? oor_netdev->name : dev->name));
 }

 out:
diff --git a/lib/flow.c b/lib/flow.c
index 77ed3d9df..a39807908 100644
--- a/lib/flow.c
+++ b/lib/flow.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -41,6 +42,8 @@
 #include "unaligned.h"
 #include "util.h"
 #include "openvswitch/nsh.h"
+#include "ovs-router.h"
+#include "lib/netdev-provider.h"

 COVERAGE_DEFINE(flow_extract);
 COVERAGE_DEFINE(miniflow_malloc);
@@ -3403,3 +3406,25 @@ flow_limit_vlans(int vlan_limit)
 flow_vlan_limit = MIN(vlan_limit, FLOW_MAX_VLAN_HEADERS);
 }
 }
+
+struct netdev *
+flow_get_tunnel_netdev(struct flow_tnl *tunnel)
+{
+char iface[IFNAMSIZ];
+struct in6_addr ip6;
+struct in6_addr gw;
+
+if (tunnel->ip_src) {
+in6_addr_set_mapped_ipv4(, tunnel->ip_src);
+} else if (ipv6_addr_is_set(>ipv6_src)) {
+ip6 = tunnel->ipv6_src;
+} else {
+return NULL;
+}
+
+if (!ovs_router_lookup(0, , iface, NULL, )) {
+return NULL;
+}
+
+return netdev_from_name(iface);
+}
diff --git a/lib/flow.h b/lib/flow.h
index d03f1ba9c..aca60c41a 100644
--- a/lib/flow.h
+++ b/lib/flow.h
@@ -73,6 +73,7 @@ void flow_extract(struct dp_packet *, struct flow 
*);
 void flow_zero_wildcards(struct flow *, const struct flow_wildcards 
*);
 void flow_unwildcard_tp_ports(const struct flow *, struct 
flow_wildcards *);
 void flow_get_metadata(const struct flow *, struct match 
*flow_metadata);

+struct netdev *flow_get_tunnel_netdev(struct flow_tnl *tunnel);

 const char *ct_state_to_string(uint32_t state);
 uint32_t ct_state_from_string(const char *);
diff --git a/lib/netdev-provider.h b/lib/netdev-provider.h
index 5a7947351..e320dad61 100644
--- a/lib/netdev-provider.h
+++ b/lib/netdev-provider.h
@@ -35,6 +35,15 @@ extern "C" {
 struct netdev_tnl_build_header_params;
 #define NETDEV_NUMA_UNSPEC OVS_NUMA_UNSPEC

+/* Offload-capable (HW) netdev information */
+struct netdev_hw_info {
+bool oor;  /* Out of Offload Resources ? */
+};
+
+enum hw_info_type {
+HW_INFO_TYPE_OOR = 1   /* OOR state */
+};
+
 /* A network device (e.g. an Ethernet device).
  *
  * Network device implementations may read these members but should 
not modify

@@ -80,6 +89,8 @@ struct netdev {
 int n_rxq;
 struct shash_node *node;/* Pointer to element in 
global map. */
 struct ovs_list saved_flags_list; /* Contains "struct 
netdev_saved_flags". */

+
+struct 

[ovs-dev] [PATCH 3/3] netdev-dpdk: Dump flow patterns only if debug enabled.

[Ilya Maximets]

No need to waste time for fields checking in case DBG disabled.
Additionally sequence of prints replaced with single print
to avoid output interrupting by other log messages.

Signed-off-by: Ilya Maximets 
---
 lib/netdev-dpdk.c | 95 ++-
 1 file changed, 60 insertions(+), 35 deletions(-)

diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
index d106a2fbd..3a1b577d0 100644
--- a/lib/netdev-dpdk.c
+++ b/lib/netdev-dpdk.c
@@ -4072,28 +4072,38 @@ struct flow_actions {
 static void
 dump_flow_pattern(struct rte_flow_item *item)
 {
+struct ds s;
+
+if (!VLOG_IS_DBG_ENABLED() || item->type == RTE_FLOW_ITEM_TYPE_END) {
+return;
+}
+
+ds_init();
+
 if (item->type == RTE_FLOW_ITEM_TYPE_ETH) {
 const struct rte_flow_item_eth *eth_spec = item->spec;
 const struct rte_flow_item_eth *eth_mask = item->mask;
 
-VLOG_DBG("rte flow eth pattern:\n");
+ds_put_cstr(, "rte flow eth pattern:\n");
 if (eth_spec) {
-VLOG_DBG("  Spec: src="ETH_ADDR_FMT", dst="ETH_ADDR_FMT", "
+ds_put_format(,
+ "  Spec: src="ETH_ADDR_FMT", dst="ETH_ADDR_FMT", "
  "type=0x%04" PRIx16"\n",
  ETH_ADDR_BYTES_ARGS(eth_spec->src.addr_bytes),
  ETH_ADDR_BYTES_ARGS(eth_spec->dst.addr_bytes),
  ntohs(eth_spec->type));
 } else {
-VLOG_DBG("  Spec = null\n");
+ds_put_cstr(, "  Spec = null\n");
 }
 if (eth_mask) {
-VLOG_DBG("  Mask: src="ETH_ADDR_FMT", dst="ETH_ADDR_FMT", "
+ds_put_format(,
+ "  Mask: src="ETH_ADDR_FMT", dst="ETH_ADDR_FMT", "
  "type=0x%04"PRIx16"\n",
  ETH_ADDR_BYTES_ARGS(eth_mask->src.addr_bytes),
  ETH_ADDR_BYTES_ARGS(eth_mask->dst.addr_bytes),
  eth_mask->type);
 } else {
-VLOG_DBG("  Mask = null\n");
+ds_put_cstr(, "  Mask = null\n");
 }
 }
 
@@ -4101,19 +4111,21 @@ dump_flow_pattern(struct rte_flow_item *item)
 const struct rte_flow_item_vlan *vlan_spec = item->spec;
 const struct rte_flow_item_vlan *vlan_mask = item->mask;
 
-VLOG_DBG("rte flow vlan pattern:\n");
+ds_put_cstr(, "rte flow vlan pattern:\n");
 if (vlan_spec) {
-VLOG_DBG("  Spec: tpid=0x%"PRIx16", tci=0x%"PRIx16"\n",
+ds_put_format(,
+ "  Spec: tpid=0x%"PRIx16", tci=0x%"PRIx16"\n",
  ntohs(vlan_spec->tpid), ntohs(vlan_spec->tci));
 } else {
-VLOG_DBG("  Spec = null\n");
+ds_put_cstr(, "  Spec = null\n");
 }
 
 if (vlan_mask) {
-VLOG_DBG("  Mask: tpid=0x%"PRIx16", tci=0x%"PRIx16"\n",
+ds_put_format(,
+ "  Mask: tpid=0x%"PRIx16", tci=0x%"PRIx16"\n",
  vlan_mask->tpid, vlan_mask->tci);
 } else {
-VLOG_DBG("  Mask = null\n");
+ds_put_cstr(, "  Mask = null\n");
 }
 }
 
@@ -4121,9 +4133,10 @@ dump_flow_pattern(struct rte_flow_item *item)
 const struct rte_flow_item_ipv4 *ipv4_spec = item->spec;
 const struct rte_flow_item_ipv4 *ipv4_mask = item->mask;
 
-VLOG_DBG("rte flow ipv4 pattern:\n");
+ds_put_cstr(, "rte flow ipv4 pattern:\n");
 if (ipv4_spec) {
-VLOG_DBG("  Spec: tos=0x%"PRIx8", ttl=%"PRIx8", proto=0x%"PRIx8
+ds_put_format(,
+ "  Spec: tos=0x%"PRIx8", ttl=%"PRIx8", proto=0x%"PRIx8
  ", src="IP_FMT", dst="IP_FMT"\n",
  ipv4_spec->hdr.type_of_service,
  ipv4_spec->hdr.time_to_live,
@@ -4131,10 +4144,11 @@ dump_flow_pattern(struct rte_flow_item *item)
  IP_ARGS(ipv4_spec->hdr.src_addr),
  IP_ARGS(ipv4_spec->hdr.dst_addr));
 } else {
-VLOG_DBG("  Spec = null\n");
+ds_put_cstr(, "  Spec = null\n");
 }
 if (ipv4_mask) {
-VLOG_DBG("  Mask: tos=0x%"PRIx8", ttl=%"PRIx8", proto=0x%"PRIx8
+ds_put_format(,
+ "  Mask: tos=0x%"PRIx8", ttl=%"PRIx8", proto=0x%"PRIx8
  ", src="IP_FMT", dst="IP_FMT"\n",
  ipv4_mask->hdr.type_of_service,
  ipv4_mask->hdr.time_to_live,
@@ -4142,7 +4156,7 @@ dump_flow_pattern(struct rte_flow_item *item)
  IP_ARGS(ipv4_mask->hdr.src_addr),
  IP_ARGS(ipv4_mask->hdr.dst_addr));
 } else {
-VLOG_DBG("  Mask = null\n");
+ds_put_cstr(, "  Mask = null\n");
 }
 }
 
@@ -4150,20 +4164,22 @@ dump_flow_pattern(struct rte_flow_item *item)
 const struct rte_flow_item_udp *udp_spec = item->spec;
 const struct rte_flow_item_udp *udp_mask = 

[ovs-dev] [PATCH 2/3] netdev-dpdk: Print port name in offload API messages.

[Ilya Maximets]

This is useful for understanding which flows offloaded to
which ports.

Code refactored a bit to reduce number of casts.

Signed-off-by: Ilya Maximets 
---
 lib/netdev-dpdk.c | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
index d2b392f61..d106a2fbd 100644
--- a/lib/netdev-dpdk.c
+++ b/lib/netdev-dpdk.c
@@ -4528,14 +4528,14 @@ end_proto_check:
 
 free(rss);
 if (!flow) {
-VLOG_ERR("rte flow creat error: %u : message : %s\n",
- error.type, error.message);
+VLOG_ERR("%s: rte flow creat error: %u : message : %s\n",
+ netdev_get_name(netdev), error.type, error.message);
 ret = -1;
 goto out;
 }
 ufid_to_rte_flow_associate(ufid, flow);
-VLOG_DBG("installed flow %p by ufid "UUID_FMT"\n",
- flow, UUID_ARGS((struct uuid *)ufid));
+VLOG_DBG("%s: installed flow %p by ufid "UUID_FMT"\n",
+ netdev_get_name(netdev), flow, UUID_ARGS((struct uuid *)ufid));
 
 out:
 free(patterns.items);
@@ -4639,9 +4639,10 @@ err:
 }
 
 static int
-netdev_dpdk_destroy_rte_flow(struct netdev_dpdk *dev,
+netdev_dpdk_destroy_rte_flow(struct netdev *netdev,
  const ovs_u128 *ufid,
  struct rte_flow *rte_flow) {
+struct netdev_dpdk *dev = netdev_dpdk_cast(netdev);
 struct rte_flow_error error;
 int ret;
 
@@ -4650,11 +4651,12 @@ netdev_dpdk_destroy_rte_flow(struct netdev_dpdk *dev,
 ret = rte_flow_destroy(dev->port_id, rte_flow, );
 if (ret == 0) {
 ufid_to_rte_flow_disassociate(ufid);
-VLOG_DBG("removed rte flow %p associated with ufid " UUID_FMT "\n",
- rte_flow, UUID_ARGS((struct uuid *)ufid));
+VLOG_DBG("%s: removed rte flow %p associated with ufid " UUID_FMT "\n",
+ netdev_get_name(netdev), rte_flow,
+ UUID_ARGS((struct uuid *)ufid));
 } else {
-VLOG_ERR("rte flow destroy error: %u : message : %s\n",
- error.type, error.message);
+VLOG_ERR("%s: rte flow destroy error: %u : message : %s\n",
+ netdev_get_name(netdev), error.type, error.message);
 }
 
 ovs_mutex_unlock(>mutex);
@@ -4675,8 +4677,7 @@ netdev_dpdk_flow_put(struct netdev *netdev, struct match 
*match,
  */
 rte_flow = ufid_to_rte_flow_find(ufid);
 if (rte_flow) {
-ret = netdev_dpdk_destroy_rte_flow(netdev_dpdk_cast(netdev),
-   ufid, rte_flow);
+ret = netdev_dpdk_destroy_rte_flow(netdev, ufid, rte_flow);
 if (ret < 0) {
 return ret;
 }
@@ -4701,8 +4702,7 @@ netdev_dpdk_flow_del(struct netdev *netdev, const 
ovs_u128 *ufid,
 return -1;
 }
 
-return netdev_dpdk_destroy_rte_flow(netdev_dpdk_cast(netdev),
-ufid, rte_flow);
+return netdev_dpdk_destroy_rte_flow(netdev, ufid, rte_flow);
 }
 
 #define DPDK_FLOW_OFFLOAD_API   \
-- 
2.17.1

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

[ovs-dev] [PATCH 1/3] dpif-netdev: Fix cmap node use after free on flow disassociation.

[Ilya Maximets]

Data pointed by cmap node must not be freed while iterating.
ovsrcu_postpone should be used instead.

CC: Finn Christensen 
Fixes: e8a2b5bf92bb ("netdev-dpdk: implement flow offload with rte flow")
Signed-off-by: Ilya Maximets 
---
 lib/dpif-netdev.c | 2 +-
 lib/netdev-dpdk.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index c44c417d3..3f7acb5dd 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -2136,7 +2136,7 @@ megaflow_to_mark_disassociate(const ovs_u128 *mega_ufid)
 if (ovs_u128_equals(*mega_ufid, data->mega_ufid)) {
 cmap_remove(_mark.megaflow_to_mark,
 CONST_CAST(struct cmap_node *, >node), hash);
-free(data);
+ovsrcu_postpone(free, data);
 return;
 }
 }
diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
index 78a981d8f..d2b392f61 100644
--- a/lib/netdev-dpdk.c
+++ b/lib/netdev-dpdk.c
@@ -4043,7 +4043,7 @@ ufid_to_rte_flow_disassociate(const ovs_u128 *ufid) {
 if (ovs_u128_equals(*ufid, data->ufid)) {
 cmap_remove(_to_rte_flow,
 CONST_CAST(struct cmap_node *, >node), hash);
-free(data);
+ovsrcu_postpone(free, data);
 return;
 }
 }
-- 
2.17.1

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

[ovs-dev] [PATCH 0/3] Few more fixes/enhancements for rte_flow offloading.

[Ilya Maximets]

Ilya Maximets (3):
  dpif-netdev: Fix cmap node use after free on flow disassociation.
  netdev-dpdk: Print port name in offload API messages.
  netdev-dpdk: Dump flow patterns only if debug enabled.

 lib/dpif-netdev.c |   2 +-
 lib/netdev-dpdk.c | 123 --
 2 files changed, 75 insertions(+), 50 deletions(-)

-- 
2.17.1

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

Re: [ovs-dev] [PATCH branch-2.9] dpdk: Use DPDK 17.11.4 release.

[Stokes, Ian]

> On 10/19/2018 12:40 PM, Ian Stokes wrote:
> > Modify travis linux build script to use the latest DPDK stable release
> > 17.11.4. Update docs for latest DPDK stable releases.
> >
> 
> Acked-by: Kevin Traynor 
> 

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

[ovs-dev] [PATCH v1] Docs: Remove zero-copy QEMU limitation.

[Ian Stokes]

Remove note regarding zero-copy compatibility with QEMU >= 2.7.

When zero-copy was introduced to OVS it was incompatible with QEMU >=
2.7. This issue has since been fixed in DPDK with commit
803aeecef123 ("vhost: fix dequeue zero copy with virtio1") and
backported to DPDK LTS branches. Remove the reference to this
issue in the zero-copy documentation.

Cc: Ciara Loftus 
Signed-off-by: Ian Stokes 
---
 Documentation/topics/dpdk/vhost-user.rst | 6 --
 1 file changed, 6 deletions(-)

diff --git a/Documentation/topics/dpdk/vhost-user.rst 
b/Documentation/topics/dpdk/vhost-user.rst
index 176bf1768..6334590af 100644
--- a/Documentation/topics/dpdk/vhost-user.rst
+++ b/Documentation/topics/dpdk/vhost-user.rst
@@ -500,12 +500,6 @@ QEMU versions v2.10 and greater). This value can be set 
like so::
 
 Because of this limitation, this feature is considered 'experimental'.
 
-The feature currently does not fully work with QEMU >= v2.7 due to a bug in
-DPDK which will be addressed in an upcoming release. The patch to fix this
-issue can be found on
-`Patchwork
-`__
-
 Further information can be found in the
 `DPDK documentation
 `__
-- 
2.13.6

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

Re: [ovs-dev] [PATCH 1/1] dpdk: Use DPDK 17.11.4 release.

[Kevin Traynor]

On 10/19/2018 12:03 PM, Stokes, Ian wrote:
>> On 09/13/2018 01:43 PM, Ian Stokes wrote:
>>> Modify travis linux build script to use the latest DPDK stable release
>>> 17.11.4. Update docs for latest DPDK stable releases.
>>>
>>
>> I didn't see a specific branch-2.9 patch, and it doesn't apply due to
>> the docs having moved. If you are intending it for that branch, you
>> could just move the content. It's ok for branch-2.10/master.
> 
> Yes, the plan was to update 2.9 as well, but just move the changes to the 
> correct docs as part of it. I can submit another patch if people prefer but 
> it's pretty low risk I would think.
> 

I think it would have been fine for copy'n'paste too, but as you've sent
the patch, i've just acked it.

thanks,
Kevin.

>>
>> Acked-by: Kevin Traynor 
>>
> 
> Thanks
> Ian
> 

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

Re: [ovs-dev] [PATCH branch-2.9] dpdk: Use DPDK 17.11.4 release.

[Kevin Traynor]

On 10/19/2018 12:40 PM, Ian Stokes wrote:
> Modify travis linux build script to use the latest
> DPDK stable release 17.11.4. Update docs for latest
> DPDK stable releases.
> 

Acked-by: Kevin Traynor 

> Signed-off-by: Ian Stokes 
> ---
>  .travis/linux-build.sh   | 2 +-
>  Documentation/faq/releases.rst   | 4 ++--
>  Documentation/intro/install/dpdk.rst | 8 
>  Documentation/topics/dpdk/vhost-user.rst | 6 +++---
>  4 files changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/.travis/linux-build.sh b/.travis/linux-build.sh
> index 4dfaad7a5..796c2f8c8 100755
> --- a/.travis/linux-build.sh
> +++ b/.travis/linux-build.sh
> @@ -83,7 +83,7 @@ fi
>  
>  if [ "$DPDK" ]; then
>  if [ -z "$DPDK_VER" ]; then
> -DPDK_VER="17.11.3"
> +DPDK_VER="17.11.4"
>  fi
>  install_dpdk $DPDK_VER
>  if [ "$CC" = "clang" ]; then
> diff --git a/Documentation/faq/releases.rst b/Documentation/faq/releases.rst
> index 31d51d81a..acf4c778f 100644
> --- a/Documentation/faq/releases.rst
> +++ b/Documentation/faq/releases.rst
> @@ -162,9 +162,9 @@ Q: What DPDK version does each Open vSwitch release work 
> with?
>  2.4.x2.0
>  2.5.x2.2
>  2.6.x16.07.2
> -2.7.x16.11.7
> +2.7.x16.11.8
>  2.8.x17.05.2
> -2.9.x17.11.3
> +2.9.x17.11.4
>   ===
>  
>  Q: Are all the DPDK releases that OVS versions work with maintained?
> diff --git a/Documentation/intro/install/dpdk.rst 
> b/Documentation/intro/install/dpdk.rst
> index 074489112 ..1dafaca0a 100644
> --- a/Documentation/intro/install/dpdk.rst
> +++ b/Documentation/intro/install/dpdk.rst
> @@ -40,7 +40,7 @@ Build requirements
>  In addition to the requirements described in :doc:`general`, building Open
>  vSwitch with DPDK will require the following:
>  
> -- DPDK 17.11.3
> +- DPDK 17.11.4
>  
>  - A `DPDK supported NIC`_
>  
> @@ -69,9 +69,9 @@ Install DPDK
>  #. Download the `DPDK sources`_, extract the file and set ``DPDK_DIR``::
>  
> $ cd /usr/src/
> -   $ wget http://fast.dpdk.org/rel/dpdk-17.11.3.tar.xz
> -   $ tar xf dpdk-17.11.3.tar.xz
> -   $ export DPDK_DIR=/usr/src/dpdk-stable-17.11.3
> +   $ wget http://fast.dpdk.org/rel/dpdk-17.11.4.tar.xz
> +   $ tar xf dpdk-17.11.4.tar.xz
> +   $ export DPDK_DIR=/usr/src/dpdk-stable-17.11.4
> $ cd $DPDK_DIR
>  
>  #. (Optional) Configure DPDK as a shared library
> diff --git a/Documentation/topics/dpdk/vhost-user.rst 
> b/Documentation/topics/dpdk/vhost-user.rst
> index 81f3511d6..7b0c9d83c 100644
> --- a/Documentation/topics/dpdk/vhost-user.rst
> +++ b/Documentation/topics/dpdk/vhost-user.rst
> @@ -316,9 +316,9 @@ To begin, instantiate a guest as described in 
> :ref:`dpdk-vhost-user` or
>  DPDK sources to VM and build DPDK::
>  
>  $ cd /root/dpdk/
> -$ wget http://fast.dpdk.org/rel/dpdk-17.11.3.tar.xz
> -$ tar xf dpdk-17.11.3.tar.xz
> -$ export DPDK_DIR=/root/dpdk/dpdk-stable-17.11.3
> +$ wget http://fast.dpdk.org/rel/dpdk-17.11.4.tar.xz
> +$ tar xf dpdk-17.11.4.tar.xz
> +$ export DPDK_DIR=/root/dpdk/dpdk-stable-17.11.4
>  $ export DPDK_TARGET=x86_64-native-linuxapp-gcc
>  $ export DPDK_BUILD=$DPDK_DIR/$DPDK_TARGET
>  $ cd $DPDK_DIR
> 

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

Re: [ovs-dev] Suggestion for 0-day robot.

[Aaron Conole]

Ilya Maximets  writes:

> Hi Aaron.
>
> What do you think about adding BSD build check to 0-day robot?
> It'll be cool to run, for example, FreeBSD VM for checking to
> cover bugs like this:
>   https://patchwork.ozlabs.org/patch/984844/
>
> netdev-bsd and many other BSD related code is not covered at all.
> Travis is not going to have FreeBSD builds in a near future and
> most of developers has Linux/Windows/MacOS.
>
> Thoughts?
>
> Best regards, Ilya Maximets.

I like it.  I'm waiting on some hardware, and Bala and I will put it in
the backlog list. :)

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

Re: [ovs-dev] [PATCH 1/1] dpdk: Use DPDK 17.11.4 release.

[Stokes, Ian]

> > On 09/13/2018 01:43 PM, Ian Stokes wrote:
> > > Modify travis linux build script to use the latest DPDK stable
> > > release 17.11.4. Update docs for latest DPDK stable releases.
> > >
> >
> > I didn't see a specific branch-2.9 patch, and it doesn't apply due to
> > the docs having moved. If you are intending it for that branch, you
> > could just move the content. It's ok for branch-2.10/master.
> 
> Yes, the plan was to update 2.9 as well, but just move the changes to the
> correct docs as part of it. I can submit another patch if people prefer
> but it's pretty low risk I would think.

I've just posted a follow up patch for Branch 2.9 that will apply cleanly.

https://mail.openvswitch.org/pipermail/ovs-dev/2018-October/353148.html

Thanks
Ian

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

[ovs-dev] [PATCH branch-2.9] dpdk: Use DPDK 17.11.4 release.

[Ian Stokes]

Modify travis linux build script to use the latest
DPDK stable release 17.11.4. Update docs for latest
DPDK stable releases.

Signed-off-by: Ian Stokes 
---
 .travis/linux-build.sh   | 2 +-
 Documentation/faq/releases.rst   | 4 ++--
 Documentation/intro/install/dpdk.rst | 8 
 Documentation/topics/dpdk/vhost-user.rst | 6 +++---
 4 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/.travis/linux-build.sh b/.travis/linux-build.sh
index 4dfaad7a5..796c2f8c8 100755
--- a/.travis/linux-build.sh
+++ b/.travis/linux-build.sh
@@ -83,7 +83,7 @@ fi
 
 if [ "$DPDK" ]; then
 if [ -z "$DPDK_VER" ]; then
-DPDK_VER="17.11.3"
+DPDK_VER="17.11.4"
 fi
 install_dpdk $DPDK_VER
 if [ "$CC" = "clang" ]; then
diff --git a/Documentation/faq/releases.rst b/Documentation/faq/releases.rst
index 31d51d81a..acf4c778f 100644
--- a/Documentation/faq/releases.rst
+++ b/Documentation/faq/releases.rst
@@ -162,9 +162,9 @@ Q: What DPDK version does each Open vSwitch release work 
with?
 2.4.x2.0
 2.5.x2.2
 2.6.x16.07.2
-2.7.x16.11.7
+2.7.x16.11.8
 2.8.x17.05.2
-2.9.x17.11.3
+2.9.x17.11.4
  ===
 
 Q: Are all the DPDK releases that OVS versions work with maintained?
diff --git a/Documentation/intro/install/dpdk.rst 
b/Documentation/intro/install/dpdk.rst
index 074489112..1dafaca0a 100644
--- a/Documentation/intro/install/dpdk.rst
+++ b/Documentation/intro/install/dpdk.rst
@@ -40,7 +40,7 @@ Build requirements
 In addition to the requirements described in :doc:`general`, building Open
 vSwitch with DPDK will require the following:
 
-- DPDK 17.11.3
+- DPDK 17.11.4
 
 - A `DPDK supported NIC`_
 
@@ -69,9 +69,9 @@ Install DPDK
 #. Download the `DPDK sources`_, extract the file and set ``DPDK_DIR``::
 
$ cd /usr/src/
-   $ wget http://fast.dpdk.org/rel/dpdk-17.11.3.tar.xz
-   $ tar xf dpdk-17.11.3.tar.xz
-   $ export DPDK_DIR=/usr/src/dpdk-stable-17.11.3
+   $ wget http://fast.dpdk.org/rel/dpdk-17.11.4.tar.xz
+   $ tar xf dpdk-17.11.4.tar.xz
+   $ export DPDK_DIR=/usr/src/dpdk-stable-17.11.4
$ cd $DPDK_DIR
 
 #. (Optional) Configure DPDK as a shared library
diff --git a/Documentation/topics/dpdk/vhost-user.rst 
b/Documentation/topics/dpdk/vhost-user.rst
index 81f3511d6..7b0c9d83c 100644
--- a/Documentation/topics/dpdk/vhost-user.rst
+++ b/Documentation/topics/dpdk/vhost-user.rst
@@ -316,9 +316,9 @@ To begin, instantiate a guest as described in 
:ref:`dpdk-vhost-user` or
 DPDK sources to VM and build DPDK::
 
 $ cd /root/dpdk/
-$ wget http://fast.dpdk.org/rel/dpdk-17.11.3.tar.xz
-$ tar xf dpdk-17.11.3.tar.xz
-$ export DPDK_DIR=/root/dpdk/dpdk-stable-17.11.3
+$ wget http://fast.dpdk.org/rel/dpdk-17.11.4.tar.xz
+$ tar xf dpdk-17.11.4.tar.xz
+$ export DPDK_DIR=/root/dpdk/dpdk-stable-17.11.4
 $ export DPDK_TARGET=x86_64-native-linuxapp-gcc
 $ export DPDK_BUILD=$DPDK_DIR/$DPDK_TARGET
 $ cd $DPDK_DIR
-- 
2.13.6

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

Re: [ovs-dev] [PATCH branch-2.7] dpdk: Use DPDK 16.11.8 release.

[Stokes, Ian]

> On 09/13/2018 02:29 PM, Ian Stokes wrote:
> > Modify travis linux build script to use the latest DPDK stable release
> > 16.11.8. Update docs for latest DPDK stable releases.
> >
> 
> Acked-by: Kevin Traynor 
> 

Thanks Kevin.
Ian

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

Re: [ovs-dev] [PATCH 1/1] dpdk: Use DPDK 17.11.4 release.

[Stokes, Ian]

> On 09/13/2018 01:43 PM, Ian Stokes wrote:
> > Modify travis linux build script to use the latest DPDK stable release
> > 17.11.4. Update docs for latest DPDK stable releases.
> >
> 
> I didn't see a specific branch-2.9 patch, and it doesn't apply due to
> the docs having moved. If you are intending it for that branch, you
> could just move the content. It's ok for branch-2.10/master.

Yes, the plan was to update 2.9 as well, but just move the changes to the 
correct docs as part of it. I can submit another patch if people prefer but 
it's pretty low risk I would think.

> 
> Acked-by: Kevin Traynor 
> 

Thanks
Ian

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

Re: [ovs-dev] [PATCH 1/1] dpdk: Use DPDK 17.11.4 release.

[Kevin Traynor]

On 09/13/2018 01:43 PM, Ian Stokes wrote:
> Modify travis linux build script to use the latest
> DPDK stable release 17.11.4. Update docs for latest
> DPDK stable releases.
> 

I didn't see a specific branch-2.9 patch, and it doesn't apply due to
the docs having moved. If you are intending it for that branch, you
could just move the content. It's ok for branch-2.10/master.

Acked-by: Kevin Traynor 

> Signed-off-by: Ian Stokes 
> ---
>  .travis/linux-build.sh   | 2 +-
>  Documentation/faq/releases.rst   | 6 +++---
>  Documentation/intro/install/dpdk.rst | 8 
>  Documentation/topics/dpdk/vhost-user.rst | 6 +++---
>  4 files changed, 11 insertions(+), 11 deletions(-)
> 
> diff --git a/.travis/linux-build.sh b/.travis/linux-build.sh
> index 4b9fc4a..1fe5bbf 100755
> --- a/.travis/linux-build.sh
> +++ b/.travis/linux-build.sh
> @@ -83,7 +83,7 @@ fi
>  
>  if [ "$DPDK" ]; then
>  if [ -z "$DPDK_VER" ]; then
> -DPDK_VER="17.11.3"
> +DPDK_VER="17.11.4"
>  fi
>  install_dpdk $DPDK_VER
>  if [ "$CC" = "clang" ]; then
> diff --git a/Documentation/faq/releases.rst b/Documentation/faq/releases.rst
> index 41d41e3..17d66fc 100644
> --- a/Documentation/faq/releases.rst
> +++ b/Documentation/faq/releases.rst
> @@ -165,10 +165,10 @@ Q: What DPDK version does each Open vSwitch release 
> work with?
>  2.4.x2.0
>  2.5.x2.2
>  2.6.x16.07.2
> -2.7.x16.11.7
> +2.7.x16.11.8
>  2.8.x17.05.2
> -2.9.x17.11.3
> -2.10.x   17.11.3
> +2.9.x17.11.4
> +2.10.x   17.11.4
>   ===
>  
>  Q: Are all the DPDK releases that OVS versions work with maintained?
> diff --git a/Documentation/intro/install/dpdk.rst 
> b/Documentation/intro/install/dpdk.rst
> index 36501c6..312b1a8 100644
> --- a/Documentation/intro/install/dpdk.rst
> +++ b/Documentation/intro/install/dpdk.rst
> @@ -42,7 +42,7 @@ Build requirements
>  In addition to the requirements described in :doc:`general`, building Open
>  vSwitch with DPDK will require the following:
>  
> -- DPDK 17.11.3
> +- DPDK 17.11.4
>  
>  - A `DPDK supported NIC`_
>  
> @@ -71,9 +71,9 @@ Install DPDK
>  #. Download the `DPDK sources`_, extract the file and set ``DPDK_DIR``::
>  
> $ cd /usr/src/
> -   $ wget http://fast.dpdk.org/rel/dpdk-17.11.3.tar.xz
> -   $ tar xf dpdk-17.11.3.tar.xz
> -   $ export DPDK_DIR=/usr/src/dpdk-stable-17.11.3
> +   $ wget http://fast.dpdk.org/rel/dpdk-17.11.4.tar.xz
> +   $ tar xf dpdk-17.11.4.tar.xz
> +   $ export DPDK_DIR=/usr/src/dpdk-stable-17.11.4
> $ cd $DPDK_DIR
>  
>  #. (Optional) Configure DPDK as a shared library
> diff --git a/Documentation/topics/dpdk/vhost-user.rst 
> b/Documentation/topics/dpdk/vhost-user.rst
> index b1e2285..176bf17 100644
> --- a/Documentation/topics/dpdk/vhost-user.rst
> +++ b/Documentation/topics/dpdk/vhost-user.rst
> @@ -320,9 +320,9 @@ To begin, instantiate a guest as described in 
> :ref:`dpdk-vhost-user` or
>  DPDK sources to VM and build DPDK::
>  
>  $ cd /root/dpdk/
> -$ wget http://fast.dpdk.org/rel/dpdk-17.11.3.tar.xz
> -$ tar xf dpdk-17.11.3.tar.xz
> -$ export DPDK_DIR=/root/dpdk/dpdk-stable-17.11.3
> +$ wget http://fast.dpdk.org/rel/dpdk-17.11.4.tar.xz
> +$ tar xf dpdk-17.11.4.tar.xz
> +$ export DPDK_DIR=/root/dpdk/dpdk-stable-17.11.4
>  $ export DPDK_TARGET=x86_64-native-linuxapp-gcc
>  $ export DPDK_BUILD=$DPDK_DIR/$DPDK_TARGET
>  $ cd $DPDK_DIR
> 

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

Re: [ovs-dev] [PATCH branch-2.7] dpdk: Use DPDK 16.11.8 release.

[Kevin Traynor]

On 09/13/2018 02:29 PM, Ian Stokes wrote:
> Modify travis linux build script to use the latest
> DPDK stable release 16.11.8. Update docs for latest
> DPDK stable releases.
>

Acked-by: Kevin Traynor 

> Signed-off-by: Ian Stokes 
> ---
>  .travis/linux-build.sh   | 2 +-
>  Documentation/faq/releases.rst   | 2 +-
>  Documentation/intro/install/dpdk.rst | 6 +++---
>  Documentation/topics/dpdk/vhost-user.rst | 6 +++---
>  4 files changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/.travis/linux-build.sh b/.travis/linux-build.sh
> index 7909c0c..f4ec4ee 100755
> --- a/.travis/linux-build.sh
> +++ b/.travis/linux-build.sh
> @@ -80,7 +80,7 @@ fi
>  
>  if [ "$DPDK" ]; then
>  if [ -z "$DPDK_VER" ]; then
> -DPDK_VER="16.11.6"
> +DPDK_VER="16.11.8"
>  fi
>  install_dpdk $DPDK_VER
>  if [ "$CC" = "clang" ]; then
> diff --git a/Documentation/faq/releases.rst b/Documentation/faq/releases.rst
> index 8636927..70e4a09 100644
> --- a/Documentation/faq/releases.rst
> +++ b/Documentation/faq/releases.rst
> @@ -160,7 +160,7 @@ Q: What DPDK version does each Open vSwitch release work 
> with?
>  2.4.x2.0
>  2.5.x2.2
>  2.6.x16.07.2
> -2.7.x16.11.6
> +2.7.x16.11.8
>   ===
>  
>  Q: Are all the DPDK releases that OVS versions work with maintained?
> diff --git a/Documentation/intro/install/dpdk.rst 
> b/Documentation/intro/install/dpdk.rst
> index abc1355..7f9905a 100644
> --- a/Documentation/intro/install/dpdk.rst
> +++ b/Documentation/intro/install/dpdk.rst
> @@ -64,9 +64,9 @@ Install DPDK
>  #. Download the `DPDK sources`_, extract the file and set ``DPDK_DIR``::
>  
> $ cd /usr/src/
> -   $ wget http://fast.dpdk.org/rel/dpdk-16.11.6.tar.xz
> -   $ tar xf dpdk-16.11.6.tar.xz
> -   $ export DPDK_DIR=/usr/src/dpdk-stable-16.11.6
> +   $ wget http://fast.dpdk.org/rel/dpdk-16.11.8.tar.xz
> +   $ tar xf dpdk-16.11.8.tar.xz
> +   $ export DPDK_DIR=/usr/src/dpdk-stable-16.11.8
> $ cd $DPDK_DIR
>  
>  #. (Optional) Configure DPDK as a shared library
> diff --git a/Documentation/topics/dpdk/vhost-user.rst 
> b/Documentation/topics/dpdk/vhost-user.rst
> index 215773b..2291494 100644
> --- a/Documentation/topics/dpdk/vhost-user.rst
> +++ b/Documentation/topics/dpdk/vhost-user.rst
> @@ -271,9 +271,9 @@ To begin, instantiate a guest as described in 
> :ref:`dpdk-vhost-user` or
>  DPDK sources to VM and build DPDK::
>  
>  $ cd /root/dpdk/
> -$ wget http://fast.dpdk.org/rel/dpdk-16.11.6.tar.xz
> -$ tar xf dpdk-16.11.6.tar.xz
> -$ export DPDK_DIR=/root/dpdk/dpdk-stable-16.11.6
> +$ wget http://fast.dpdk.org/rel/dpdk-16.11.8.tar.xz
> +$ tar xf dpdk-16.11.8.tar.xz
> +$ export DPDK_DIR=/root/dpdk/dpdk-stable-16.11.8
>  $ export DPDK_TARGET=x86_64-native-linuxapp-gcc
>  $ export DPDK_BUILD=$DPDK_DIR/$DPDK_TARGET
>  $ cd $DPDK_DIR
> 

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

Re: [ovs-dev] [PATCH v11 0/7] OVS-DPDK flow offload with rte_flow

[Ilya Maximets]

> On Thu, Jun 28, 2018 at 02:39:32PM -0300, Flavio Leitner wrote:
>> Ian, I am afraid that the issue might be local and we most probably can
>> fix with a follow up patch later, so if others are happy with the patchset,
>> please go ahead. I can see this only in the mid of next week.
> 
> The issue was indeed local. I ran few tests with the patchset and
> found no issues. I got at least +1Mpps in my simple flow and 200
> flows test cases.
> 
> Thanks again,
> fbl

Hi Flavio,
Sorry to bother you, but my colleague tries to test HWOL with Mellanox
Connect-X5 NIC and has kind of similar issue. The performance with and
without offloading is almost equal. I'm wondering, maybe you can describe
what kind of local issue you had and how you fixed it?

Thanks in advance.
Best regards, Ilya Maximets.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v8 0/3] Support dynamic rebalancing of offloaded flows

[Simon Horman]

On Thu, Oct 18, 2018 at 09:43:11PM +0530, Sriharsha Basavapatna via dev wrote:
> With the current OVS offload design, when an offload-device fails to add a
> flow rule and returns an error, OVS adds the rule to the kernel datapath.
> The flow gets processed by the kernel datapath for the entire life of that
> flow. This is fine when an error is returned by the device due to lack of
> support for certain keys or actions.
> 
> But when an error is returned due to temporary conditions such as lack of
> resources to add a flow rule, the flow continues to be processed by kernel
> even when resources become available later. That is, those flows never get
> offloaded again. This problem becomes more pronounced when a flow that has
> been initially offloaded may have a smaller packet rate than a later flow
> that could not be offloaded due to lack of resources. This leads to
> inefficient use of HW resources and wastage of host CPU cycles.
> 
> This patch-set addresses this issue by providing a way to detect temporary
> offload resource constraints (Out-Of-Resource or OOR condition) and to
> selectively and dynamically offload flows with a higher packets-per-second
> (pps) rate. This dynamic rebalancing is done periodically on netdevs that
> are in OOR state until resources become available to offload all pending
> flows.
> 
> The patch-set involves the following changes at a high level:
> 
> 1. Detection of Out-Of-Resources (OOR) condition on an offload-capable 
>netdev.
> 2. Gathering flow offload selection criteria for all flows on an OOR netdev;
>i.e, packets-per-second (pps) rate of flows for offloaded and
>non-offloaded (pending) flows.
> 3. Dynamically replacing offloaded flows with a lower pps-rate, with
>non-offloaded flows with a higher pps-rate, on an OOR netdev. A new
>OpenvSwitch configuration option - "offload-rebalance" to enable
>this policy.
> 
> Cost/benefits data points:
> 
> 1. Rough cost of the new rebalancing, in terms of CPU time:
> 
>Ran a test that replaced 256 low pps-rate flows(pings) with 256 high
>pps-rate flows(iperf), in a system with 4 cpus (Intel Xeon E5 @ 2.40GHz;
>2 cores with hw threads enabled, rest disabled). The data showed that cpu
>utilization increased by about ~20%. This increase occurs during the
>specific second in which rebalancing is done. And subsequently (from the
>next second), cpu utilization decreases significantly due to offloading
>of higher pps-rate flows. So effectively there's a bump in cpu utilization
>at the time of rebalancing, that is more than compensated by reduced cpu
>utilization once the right flows get offloaded.
> 
> 2. Rough benefits to the user in terms of offload performance:
> 
>The benefits to the user is reduced cpu utilization in the host, since
>higher pps-rate flows get offloaded, replacing lower pps-rate flows.
>Replacing a single offloaded flood ping flow with an iperf flow (multiple
>connections), shows that the cpu %used that was originally 100% on a
>single cpu (rebalancing disabled) goes down to 35% (rebalancing enabled).
>That is, cpu utilization decreased 65% after rebalancing.
> 
> 3. Circumstances under which the benefits would show up:
> 
>The rebalancing benefits would show up once offload resources are
>exhausted and new flows with higher pps-rate are initiated, that would
>otherwise be handled by kernel datapath costing host cpu cycles.
> 
>This can be observed using 'ovs appctl dpctl/ dump-flows' command. Prior
>to rebalancing, any high pps-rate flows that couldn't be offloaded due to
>resource crunch would show up in the output of 'dump-flows type=ovs' and
>after rebalancing such flows would appear in the output of
>'dump-flows type=offloaded'.

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

[ovs-dev] Crypto BOOM{Doubling/Increase Your Bitcoin}

[Quin Edena]

 Unsubscribe Here 
 Do you wish to get your Bitcoin Doubled, Are you a Bitcoin Miner, Bitcoin 
Investor OR Want to invest in Bitcoin???.
 Here is a reliable profit making Bitcoin Investment/Mining Platform that will 
yield you progressively.
 Its 98% profit making with 160% increase per investment with Instant Package 
Bonus(IPB) applied. This implies that if you invest $100, you stand to earn 
within $290 - $1,760 after 24 hours. Its always profit earning with no single 
lose.
 Follow the link below to learn more and get your Bitcoin Mined. 
  >> Click Here << to sign up and get started.! 

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

Re: [ovs-dev] [PATCH v2] connmgr: Fix vswitchd abort when a port is added and the controller is down

[Eelco Chaudron]

On 18 Oct 2018, at 13:17, nusid...@redhat.com wrote:


From: Numan Siddique 

We see the below trace when a port is added to a bridge and the 
configured

controller is down

0x7fb002f8b207 in raise () from /lib64/libc.so.6
0x7fb002f8c8f8 in abort () from /lib64/libc.so.6
0x7fb004953026 in ofputil_protocol_to_ofp_version () from 
/lib64/libopenvswitch-2.10.so.0
0x7fb00494e38e in ofputil_encode_port_status () from 
/lib64/libopenvswitch-2.10.so.0
0x7fb004ef1c5b in connmgr_send_port_status () from 
/lib64/libofproto-2.10.so.0
0x7fb004efa9f4 in ofport_install () from 
/lib64/libofproto-2.10.so.0

0x7fb004efbfb2 in update_port () from /lib64/libofproto-2.10.so.0
0x7fb004efc7f9 in ofproto_port_add () from 
/lib64/libofproto-2.10.so.0

0x556d540a3f95 in bridge_add_ports__ ()
0x556d540a5a47 in bridge_reconfigure ()
0x556d540a9199 in bridge_run ()
0x556d540a02a5 in main ()

The abort is because of ofputil_protocol_to_ofp_version() is called 
with invalid
protocol - OFPUTIL_P_NONE. Please see [1] for more details. Similar 
aborts are

seen as reported in [2].

The commit [3] changed the behavior of the function 
rconn_get_version().
Before the commit [3], the function ofconn_receives_async_msg() would 
always

return false if the connection to the controller was down, since
rconn_get_version() used to return -1. This patch now checks the rconn
connection status in ofconn_receives_async_msg() and returns false if 
not

connected. This would avoid the aborts seen in the above stack trace.

The issue can be reproduced by running the test added in this patch
without the fix.

[1] - https://bugzilla.redhat.com/show_bug.cgi?id=1640045
[2] - https://bugzilla.redhat.com/show_bug.cgi?id=1637926

[3] - 476d2551ab ("rconn: Introduce new invariant to fix assertion 
failure in corner case.")


Signed-off-by: Numan Siddique 
---


Change looks good to me.

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

Re: [ovs-dev] OVN based distributed virtual routing for VLAN backed networks

[Han Zhou]

Hi Ankur, Mark,

Please find my comments inline below.

(I will spend more time to understand the change for the NAT case. )

Thanks,
Han


On Thu, Oct 18, 2018 at 4:40 PM Ankur Sharma 
wrote:
>
> Hi,
>
> As per our discussion in the IRC meeting  today, i have added all the
diagrams in following google doc.
>
https://docs.google.com/document/d/1uoQH478wM1OZ16HrxzbOUvk5LvFnfNEWbkPT6Zmm9OU/edit?usp=sharing
>
> Please take a look.
>
> Appreciate the feedback so far, looking forward to more discussions.
>
> Thanks
>
> Regards,
> Ankur
>
>
> -Original Message-
> From: Ankur Sharma
> Sent: Wednesday, October 17, 2018 3:37 PM
> To: 'Mark Michelson' ; ovs-dev@openvswitch.org
> Subject: RE: [ovs-dev] OVN based distributed virtual routing for VLAN
backed networks
>
> Hi Mark,
>
> Thanks a lot for the feedback.
> Regarding the figures, i attached the PNGs (shows in my sent items), but
looks like they got filtered.
> My bad on that, is there a location, where OVS community uploads images
for references.
> Please bear with us, hopefully, we will be able to avoid some of these
glitches in our next conversations.
>
> Appreciate your comments on the proposal, please find my replies inline.
>
> Thanks
>
> Regards,
> Ankur
>
> -Original Message-
> From: Mark Michelson 
> Sent: Wednesday, October 17, 2018 2:50 PM
> To: Ankur Sharma ; ovs-dev@openvswitch.org
> Subject: Re: [ovs-dev] OVN based distributed virtual routing for VLAN
backed networks
>
> Hi Ankur,
>
> Thanks for the detailed document! I always appreciate it when things are
planned out in great detail so we know exactly what to expect.
>
> A general comment: there are places below where things like "figure 1"
> and "figure OVN bridge deployment" are referenced, but we can't see them.
Is there a link to another document you can share that has these figures
present?
>
> Other comments of mine are inline below.
>
> On 10/16/2018 06:43 PM, Ankur Sharma wrote:
> > Hi,
> >
> > We have done some effort in evaluating usage of OVN for Distributed
> > Virtual Routing (DVR) for vlan backed networks.

So the proposal should work only when all the HVs are physically L2
connected (no L3 hops in between), correct? OVN doesn't have this
assumption, but I think it should be ok if it is documented well so that
users will understand this limitation when using this feature.

> >
> > We would like to take it forward with the community.
> >
> > We understand that some of the work could be overlapping with existing
> > patches in review.
> >
> > We would appreciate the feedback and would be happy to update our
> > patches to avoid known overlaps.
> >
> > This email explains the proposal. We will be following it up with
patches.
> > Each "CODE CHANGES" section summarizes the change that corresponding
> > patch would have.
> >
> >
> > DISTRIBUTED VIRTUAL ROUTING FOR VLAN BACKED NETWORKS
> > ==
> >
> >
> > 1. OVN Bridge Deployment
> > 
> >
> > Our design follows following ovn-bridge deployment model (please refer
> > to figure OVN Bridge deployment).
> >  i. br-int ==> OVN managed bridge.
> > br-pif ==> Learning Bridge, where physical NICs will be
connected.
> >
> > ii. Any packet that should be on physical network, will travel from
BR-INT
> > to BR-PIF, via patch ports (localnet ports).
> >
> > 2. Layer 2
> > -
> >
> > DESIGN:
> > ~~~
> > a. Leverage on localnet logical port type as path port between
br-int and
> > br-pif.
> > b. Each VLAN backed logical switch will have a localnet port
connected
> > to it.
> > c. Tagging and untagging of vlan headers happens at localnet port
boundary.
> >
> > PIPELINE EXECUTION:
> > ~~~
> > a. Unlike geneve encap based solution, where we execute ingress
pipeline on
> > source chassis and egress pipeline on destination chassis, for
vlan
> > backed logical switches, packet will go through ingress pipeline
> > on destination chassis as well.
> >
> > PACKET FLOW (Figure 1. shows topology and Figure 2. shows the
packet flow):
> >
~~~
> > a. VM sends unicast traffic (destined to VM2_MAC) to br-int.
> > b. For br-int, destination mac is not local, hence it will forward
it to
> > localnet port (by design), which is attached to br-pif. This is
> > the stage at which vlan tag is added. Br-pif forwards the packet
> > to physical interface.
> > c. br-pif on destination chassis sends the received traffic to
patch-ports
> > on br-int (as unicast or unknown unicast).
> > d. br-int does vlan tag check, strips the vlan header and sends
> > the packet to ingress pipeline of the corresponding datapath.
> >
> >
> > KEY DIFFERENCES AS COMPARED TO OVERLAY:
> > ~~~
> > a.