Re: [ovs-dev] [RFC 2/2] dpdk: Update INSTALL.DPDK.md to reflect new config

[Gray, Mark D]

> 
> Why delay the inevitable? :)
> 
Absolutely, I agree with the approach. I was just pointing out that issue.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH] ofproto-dpif: add reply on error in ofproto/tnl-push-pop

[Ilya Maximets]

Fixes hang of 'ovs-appctl ofproto/tnl-push-pop' when an invalid
argument passed.

Signed-off-by: Ilya Maximets 
---
 ofproto/ofproto-dpif.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/ofproto/ofproto-dpif.c b/ofproto/ofproto-dpif.c
index d920ed0..6561c65 100644
--- a/ofproto/ofproto-dpif.c
+++ b/ofproto/ofproto-dpif.c
@@ -5328,6 +5328,8 @@ disable_tnl_push_pop(struct unixctl_conn *conn 
OVS_UNUSED, int argc OVS_UNUSED,
 ofproto_use_tnl_push_pop = true;
 unixctl_command_reply(conn, "Tunnel push-pop on");
 ofproto_revalidate_all_backers();
+} else {
+unixctl_command_reply_error(conn, "Invalid argument");
 }
 }
 
-- 
2.1.4

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] ofproto-dpif: add reply on error in ofproto/tnl-push-pop

[Thadeu Lima de Souza Cascardo]

On Mon, Dec 07, 2015 at 01:02:41PM +0300, Ilya Maximets wrote:
> Fixes hang of 'ovs-appctl ofproto/tnl-push-pop' when an invalid
> argument passed.
> 
> Signed-off-by: Ilya Maximets 
> ---
>  ofproto/ofproto-dpif.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/ofproto/ofproto-dpif.c b/ofproto/ofproto-dpif.c
> index d920ed0..6561c65 100644
> --- a/ofproto/ofproto-dpif.c
> +++ b/ofproto/ofproto-dpif.c
> @@ -5328,6 +5328,8 @@ disable_tnl_push_pop(struct unixctl_conn *conn 
> OVS_UNUSED, int argc OVS_UNUSED,
>  ofproto_use_tnl_push_pop = true;
>  unixctl_command_reply(conn, "Tunnel push-pop on");
>  ofproto_revalidate_all_backers();
> +} else {
> +unixctl_command_reply_error(conn, "Invalid argument");
>  }
>  }
>  
> -- 
> 2.1.4
> 
> ___
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev

Acked-by: Thadeu Lima de Souza Cascardo 
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [RFC 2/2] dpdk: Update INSTALL.DPDK.md to reflect new config

[Zoltan Kiss]

On 04/12/15 16:15, Gray, Mark D wrote:

  5. Start vswitchd:
>
>-   DPDK configuration arguments can be passed to vswitchd via `--dpdk`
>-   argument. This needs to be first argument passed to vswitchd process.
>-   dpdk arg -c is ignored by ovs-dpdk, but it is a required parameter
>-   for dpdk initialization.
>-
>+   DPDK configuration arguments can be passed to vswitchd via the
>Open_vSwitch
>+   other_config database. The recognized configuration options are listed.
>+
>+   * dpdk
>+   This is a boolean configuration option. A value of 'true' tells
>+   Open_vSwitch to initialize the DPDK EAL. A set of nominal defaults are
>+   provided so that simply enabling this option will be sufficient to 
configure
>+   DPDK enabled ports.
>+   * dpdk_core_mask
>+   This is DPDK's -c command line option, and specifies the core mask to
>+   the EAL.

Why exactly do we need this again? We have "other_config:pmd-cpu-mask" which
should set the affinity of the pmd threads. The affinities of the other 
standard pthreads
should by a system administrator. Or, if the intention is that this would allow 
us
to set affinities for the other threads, then the name should be changed to 
something
more meaningful.



My understanding is that OVS-DPDK doesn't really use any "lcore"'s from 
DPDK, but rather creates its own threads, and set the lcore_id in 
pmd_thread_setaffinity_cpu(). At least, I haven't seen any 
rte_eal_[mp_]remote_launch() call in the code, so I think the -c option 
should only have 1 core set for the master thread, everything else just 
waste memory.

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [RFC 2/2] dpdk: Update INSTALL.DPDK.md to reflect new config

[Traynor, Kevin]

> -Original Message-
> From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Zoltan Kiss
> Sent: Monday, December 7, 2015 11:57 AM
> To: Gray, Mark D; Aaron Conole; dev@openvswitch.org
> Cc: Flavio Leitner
> Subject: Re: [ovs-dev] [RFC 2/2] dpdk: Update INSTALL.DPDK.md to reflect new
> config
> 
> 
> 
> On 04/12/15 16:15, Gray, Mark D wrote:
> >>   5. Start vswitchd:
> >> >
> >> >-   DPDK configuration arguments can be passed to vswitchd via `--dpdk`
> >> >-   argument. This needs to be first argument passed to vswitchd process.
> >> >-   dpdk arg -c is ignored by ovs-dpdk, but it is a required parameter
> >> >-   for dpdk initialization.
> >> >-
> >> >+   DPDK configuration arguments can be passed to vswitchd via the
> >> >Open_vSwitch
> >> >+   other_config database. The recognized configuration options are
> listed.
> >> >+
> >> >+   * dpdk
> >> >+   This is a boolean configuration option. A value of 'true' tells
> >> >+   Open_vSwitch to initialize the DPDK EAL. A set of nominal defaults
> are
> >> >+   provided so that simply enabling this option will be sufficient to
> configure
> >> >+   DPDK enabled ports.
> >> >+   * dpdk_core_mask
> >> >+   This is DPDK's -c command line option, and specifies the core mask to
> >> >+   the EAL.
> > Why exactly do we need this again? We have "other_config:pmd-cpu-mask"
> which
> > should set the affinity of the pmd threads. The affinities of the other
> standard pthreads
> > should by a system administrator. Or, if the intention is that this would
> allow us
> > to set affinities for the other threads, then the name should be changed to
> something
> > more meaningful.
> >
> 
> My understanding is that OVS-DPDK doesn't really use any "lcore"'s from
> DPDK, but rather creates its own threads, and set the lcore_id in
> pmd_thread_setaffinity_cpu(). At least, I haven't seen any
> rte_eal_[mp_]remote_launch() call in the code, so I think the -c option
> should only have 1 core set for the master thread, everything else just
> waste memory.

I agree. At present I see it only uses the lowest core in the -c option as the
master thread. 

Aside from removing the command line args, I think we need to up level the docs
so that an OVS user knows what the -c does and the (lack of) relationship with
pmd-cpu-mask. I've seen a few examples recently where there is confusion between
them. I can put in a patch to give a brief description in the docs for the short
term, and we can keep this in mind for a bigger change like Aaron's.

> ___
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH 2/2] support L3 logical router in vtep emulator

[Shuangmin Zhang]

This patch is to support L3 DLR E-W traffic functionality in ovs-vtep. So it is 
focus on supporting switch-binding field in Logical_Router Table schema. 

Like what we do for logical switch, there are 2 parts of work

1> physical handling
In this part, create binding between logical router and logical switch,  
create peer ports between them, and create related openflow tables, similiar 
with logical switch
2> run function
In this part, update lif mac-ip bindings if any change, create ARP table to 
respond arp request for gateway,  then update routing table and forwarding 
table to create openflow entry to update src and dst macs in the packet.

Another part of work is to enhance vtep-ctl to let it recognize Logical Router 
Table in VTEP DB, additionally, support add-lr command, but it could be trival.

There are some limiations and assumptions here
1>  single-tier logical router only
2>  don't support dynamically arping destination VM's mac when packet arrive at 
gateway, so ipaddr field in local/remote mac table need to be filled by advance.
3>  E-W traffic only

---
 vtep/ovs-vtep   | 343 +++-
 vtep/vtep-ctl.c | 122 +++-
 2 files changed, 462 insertions(+), 3 deletions(-)

diff --git a/vtep/ovs-vtep b/vtep/ovs-vtep
index 46a5692..41b3a9b 100755
--- a/vtep/ovs-vtep
+++ b/vtep/ovs-vtep
@@ -43,8 +43,11 @@ ps_name = ""
 ps_type = ""
 Tunnel_Ip = ""
 Lswitches = {}
+Lrouters = {}
 Bindings = {}
+Switch_Bindings = {}
 ls_count = 0
+lr_count = 0
 tun_id = 0
 bfd_bridge = "vtep_bfd"
 bfd_ref = {}
@@ -56,6 +59,7 @@ def call_prog(prog, args_list):
 output = ""
 else:
 output = output[0].strip()
+
 return output
 
 def ovs_vsctl(args):
@@ -74,6 +78,227 @@ def unixctl_exit(conn, unused_argv, unused_aux):
 conn.reply(None)
 
 
+class Logical_Router(object):
+def __init__(self, lr_name):
+global lr_count
+self.name = lr_name
+#lr_count += 1
+#self.short_name = "vtep_lr" + str(lr_count)
+self.short_name = "vtep_" + lr_name
+vlog.info("creating lrouter %s (%s)" % (self.name, self.short_name))
+self.ports = {}
+self.dst_ips = {}
+self.lifs = {}
+self.setup_lr()
+
+def __del__(self):
+vlog.info("destroying lrouter %s" % self.name)
+
+def setup_lr(self):
+if ps_type:
+ovs_vsctl("--may-exist add-br %s -- set Bridge %s datapath_type=%s"
+  % (self.short_name, self.short_name, ps_type))
+else:
+ovs_vsctl("--may-exist add-br %s" % self.short_name)
+
+ovs_vsctl("br-set-external-id %s vtep_logical_router true"
+  % self.short_name)
+ovs_vsctl("br-set-external-id %s logical_router_name %s"
+  % (self.short_name, self.name))
+
+ovs_ofctl("del-flows %s" % self.short_name)
+ovs_ofctl("add-flow %s priority=0,action=drop" % self.short_name)
+
+def update_flood(self):
+flood_ports = self.ports.values()
+
+ovs_ofctl("add-flow %s table=1,priority=0,action=%s"
+  % (self.short_name, ",".join(flood_ports)))
+
+def run(self):
+#vlog.info("start lrouter running")
+self.update_lif_macs()
+self.update_forwarding_macs()
+
+def update_lif_macs(self):
+lif_pl_uuid = vtep_ctl("--columns=_uuid find Physical_Locator 
dst_ip=127.0.0.1").partition(":")[2].strip()
+new_lifs = set()
+
+# update lif macs
+for switch_binding in Switch_Bindings.keys():
+lr_name, lif = switch_binding.split("-", 1)
+if lr_name != self.name:
+continue
+
+ls_name = Switch_Bindings[switch_binding]
+ls_uuid = get_logical_switch_uuid(ls_name)
+lif_mac_column = vtep_ctl("--columns=MAC find Ucast_Macs_Remote 
logical_switch=%s locator=%s"
+  % (ls_uuid, lif_pl_uuid))
+
+if not lif_mac_column:
+continue
+
+lif_ip = lif.strip("\"").partition("(")[2].partition("/")[0]
+lif_ip_mask = lif.strip("\"").partition("(")[2].strip(")")
+lif_port_r = lif.strip("\"").partition("(")[0].strip() + "-r"
+lif_mac = lif_mac_column.partition(":")[2].strip()
+
+new_lifs.add(lif)
+if lif in self.lifs.keys():
+if self.lifs[lif] == lif_mac:
+continue
+else:
+del self.lifs[lif]
+ovs_ofctl("del-flow %s ip,nw_dst=%s" % (self.short_name, 
lif_ip_mask))
+
+self.lifs[lif] = lif_mac
+
+# get ip's hex format
+lif_ip_hex = getHexIp(lif_ip)
+lif_mac_hex = "0x" + "".join(lif_mac.strip("\"").split(":"))
+
+# create ARP flow table
+ovs_ofctl("add-flow %s table=1,dl_type=0x0806,nw_dst=%s,actions="
+  "move:NXM

Re: [ovs-dev] [PATCH 0/7] Enable NSH based Service Function Chaining support in OVS

[Jesse Gross]

On Fri, Nov 6, 2015 at 4:23 PM, Jesse Gross  wrote:
> On Tue, Nov 3, 2015 at 10:20 AM, Liu, Mengke  wrote:
>>> > So for NSH header, we need to add the TLV support. For the fixed
>>> > fields of NSH header like NSI, NSP, we’d like to add specific
>>> > meta-flow fields for them, for example:
>>> >
>>> > MFF_NSPType: NXM_NX_NSP (105), Length:4 bytes
>>> >
>>> > MFF_NSI Type: NXM_NX_NSI (106),  Length:1 bytes
>>> >
>>> > But for the variable length context headers of NSH, we’d like to use
>>> > fields like “tun_metadata” (tnl->metadata) to support it. We also have two
>>> options:
>>> >
>>> > 1)  Reuse the “tun_metadata” for NSH variable context header, it’s
>>> > similar to current Geneve TLV support. But it’s a little wield because
>>> > the NSH header is already an independent protocol layer but not belong
>>> > to the tunnel layer.
>>> >
>>> > 2)  Define a new “nsh_metadata” fields for NSH variable context 
>>> > header.
>>> >
>>> > Which one do you prefer? Please tell us for you inputs on our
>>> > modification plan.
>>>
>>> I would definitely like to reuse the same set of fields as were used for
>>> Geneve since there are a large number of them and have a second set
>>> seems wasteful. I don't think there is anything that inherently ties them to
>>> tunneling, so if you have a different name that is more generic we can still
>>> change them as long as it is before OVS 2.5 is released.
>>>
>>> By the way, there are several OpenFlow commands that were added support
>>> mapping TLVs to fields. These are currently specific to Geneve because they
>>> validate some protocol specific aspects. NSH actually uses the same TLV
>>> format as Geneve, so in theory they could be shared (and it would be nice to
>>> avoid duplicating these). The main thing that concerns me about this is the
>>> possibility that the protocols will diverge in the future or some other 
>>> protocol
>>> that does not have the same format will want to use the same thing. In any
>>> case, it would be nice to think about how this could be made useable by
>>> everybody before OVS 2.5.
>>
>> For NSH TLV implementation, We agree that  we should reuse the same set of 
>> fields as were used for Geneve. As NSH in MD-Type 2 use same TLV format as 
>> Geneve, they can share the pool of 64 NXMs which can be mapped on Geneve 
>> TLVs or NSH TLVs. It may be better to make the command name more generic. 
>> For example, we can rename “add-geneve-map” to “add-tlv-map”.
>> An example in our initial design for NSH MD-type 2 support:
>> ovs-ofctl add-tlv-map br0 {class=0x,type=0,len=4}->tun_metadata0
>> ovs-ofctl add-flow br0 in_port=LOCAL, actions=push_nsh, set_field:221->nsp, 
>> set_field:3->nsi, set_field:2->nsh_md_type,set_field:111->tun_metadata0, 1
>> What do you think about this proposal for NSH TLV support?
>
> I think it's basically fine although I worry a bit that "add-tlv-map"
> isn't overly descriptive - it isn't obvious that it is referring to
> this type of metadata or there could be TLVs in other formats.

I just wanted to point out that OVS 2.5 has branched at this point and
contains the current (Geneve-centric) names of these commands/fields.
If you want to change them, I would still apply a patch to help with
forward compatibility. However, the window of time to do that is
rapidly closing, so speak now or forever hold your peace.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] vtep: support L3 logical router E-W traffic in Hardware vtep emulator

[Guru Shetty]

On 6 December 2015 at 23:23, Shuangmin Zhang  wrote:

> Signed-off-by: Shuangmin Zhang 
>

How did you send this patch? Are you able to download this mail and apply
it with 'git am'? If not, try sending a mail to yourself with 'git
send-email' and then download that mail (if destination is gmail, you can
do a 'show original' and then download. If you use mutt, you can simply
download) and then 'git am' that saved mail (if gmail, you need to remove
the first line)

To install all the things needed to use 'git send-email' on Ubuntu, you
will need to install the following packages.
sudo apt-get install git git-email libmail-sendmail-perl libmailtools-perl


>
>
> ---
>
>   vtep/ovs-vtep
>
>   vtep/vtep-ctl.c
>
> 2 files changed, 462 insertions(+), 3 deletions(-)
>
>
>
> diff --git a/vtep/ovs-vtep b/vtep/ovs-vtep
>
> index 46a5692..41b3a9b 100755
>
> --- a/vtep/ovs-vtep
>
> +++ b/vtep/ovs-vtep
>
> @@ -43,8 +43,11 @@ ps_name = ""
>
>  ps_type = ""
>
>  Tunnel_Ip = ""
>
>  Lswitches = {}
>
> +Lrouters = {}
>
>  Bindings = {}
>
> +Switch_Bindings = {}
>
>  ls_count = 0
>
> +lr_count = 0
>
>  tun_id = 0
>
>  bfd_bridge = "vtep_bfd"
>
>  bfd_ref = {}
>
> @@ -56,6 +59,7 @@ def call_prog(prog, args_list):
>
>  output = ""
>
>  else:
>
>  output = output[0].strip()
>
> +
>
>  return output
>
>
>
>  def ovs_vsctl(args):
>
> @@ -74,6 +78,227 @@ def unixctl_exit(conn, unused_argv, unused_aux):
>
>  conn.reply(None)
>
>
>
>
>
> +class Logical_Router(object):
>
> +def __init__(self, lr_name):
>
> +global lr_count
>
> +self.name = lr_name
>
> +#lr_count += 1
>
> +#self.short_name = "vtep_lr" + str(lr_count)
>
> +self.short_name = "vtep_" + lr_name
>
> +vlog.info("creating lrouter %s (%s)" % (self.name,
> self.short_name))
>
> +self.ports = {}
>
> +self.dst_ips = {}
>
> +self.lifs = {}
>
> +self.setup_lr()
>
> +
>
> +def __del__(self):
>
> +vlog.info("destroying lrouter %s" % self.name)
>
> +
>
> +def setup_lr(self):
>
> +if ps_type:
>
> +ovs_vsctl("--may-exist add-br %s -- set Bridge %s
> datapath_type=%s"
>
> +  % (self.short_name, self.short_name, ps_type))
>
> +else:
>
> +ovs_vsctl("--may-exist add-br %s" % self.short_name)
>
> +
>
> +ovs_vsctl("br-set-external-id %s vtep_logical_router true"
>
> +  % self.short_name)
>
> +ovs_vsctl("br-set-external-id %s logical_router_name %s"
>
> +  % (self.short_name, self.name))
>
> +
>
> +ovs_ofctl("del-flows %s" % self.short_name)
>
> +ovs_ofctl("add-flow %s priority=0,action=drop" % self.short_name)
>
> +
>
> +def update_flood(self):
>
> +flood_ports = self.ports.values()
>
> +
>
> +ovs_ofctl("add-flow %s table=1,priority=0,action=%s"
>
> +  % (self.short_name, ",".join(flood_ports)))
>
> +
>
> +def run(self):
>
> +#vlog.info("start lrouter running")
>
> +self.update_lif_macs()
>
> +self.update_forwarding_macs()
>
> +
>
> +def update_lif_macs(self):
>
> +lif_pl_uuid = vtep_ctl("--columns=_uuid find Physical_Locator
> dst_ip=127.0.0.1").partition(":")[2].strip()
>
> +new_lifs = set()
>
> +
>
> +# update lif macs
>
> +for switch_binding in Switch_Bindings.keys():
>
> +lr_name, lif = switch_binding.split("-", 1)
>
> +if lr_name != self.name:
>
> +continue
>
> +
>
> +ls_name = Switch_Bindings[switch_binding]
>
> +ls_uuid = get_logical_switch_uuid(ls_name)
>
> +lif_mac_column = vtep_ctl("--columns=MAC find
> Ucast_Macs_Remote logical_switch=%s locator=%s"
>
> +  % (ls_uuid, lif_pl_uuid))
>
> +
>
> +if not lif_mac_column:
>
> +continue
>
> +
>
> +lif_ip = lif.strip("\"").partition("(")[2].partition("/")[0]
>
> +lif_ip_mask = lif.strip("\"").partition("(")[2].strip(")")
>
> +lif_port_r = lif.strip("\"").partition("(")[0].strip() + "-r"
>
> +lif_mac = lif_mac_column.partition(":")[2].strip()
>
> +
>
> +new_lifs.add(lif)
>
> +if lif in self.lifs.keys():
>
> +if self.lifs[lif] == lif_mac:
>
> +continue
>
> +else:
>
> +del self.lifs[lif]
>
> +ovs_ofctl("del-flow %s ip,nw_dst=%s" %
> (self.short_name, lif_ip_mask))
>
> +
>
> +self.lifs[lif] = lif_mac
>
> +
>
> +# get ip's hex format
>
> +lif_ip_hex = getHexIp(lif_ip)
>
> +lif_mac_hex = "0x" + "".join(lif_mac.strip("\"").split(":"))
>
> +
>
> +# create ARP flow table
>
> +ovs_ofctl("add-flow %s
> table=1,dl_type=0x0806,nw_dst=%s,actions="
>
> +
> "move:NXM_OF_ETH_SRC[]->NXM_OF_ETH_DST[],mod_dl_src:%s,"
>
> +
> "load:0x2->NXM_OF_

Re: [ovs-dev] [PATCH] ofproto-dpif: add reply on error in ofproto/tnl-push-pop

[Ben Pfaff]

On Mon, Dec 07, 2015 at 01:02:41PM +0300, Ilya Maximets wrote:
> Fixes hang of 'ovs-appctl ofproto/tnl-push-pop' when an invalid
> argument passed.
> 
> Signed-off-by: Ilya Maximets 

Thanks, applied to master, branch-2.5, branch-2.4.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 2/2] support L3 logical router in vtep emulator

[Ben Pfaff]

On Tue, Dec 08, 2015 at 07:35:44AM +0800, Shuangmin Zhang wrote:
> This patch is to support L3 DLR E-W traffic functionality in ovs-vtep. So it 
> is focus on supporting switch-binding field in Logical_Router Table schema. 
> 
> Like what we do for logical switch, there are 2 parts of work

Is there a patch 1/2 somewhere?
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] seq: Add a coverage counter for seq_change.

[Ben Pfaff]

On Fri, Dec 04, 2015 at 03:57:09PM -0800, Jarno Rajahalme wrote:
> Having a coverage counter tracking the value of the internal seq_next
> should help in debugging.
> 
> Suggested-by: Justin Pettit 
> Signed-off-by: Jarno Rajahalme 

Acked-by: Ben Pfaff 
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH] INSTALL.DPDK.md: Clarify DPDK arguments.

[Kevin Traynor]

Add some information about the DPDK -c and -n parameters.

Signed-off-by: Kevin Traynor 
Reported-by: Zoltan Kiss 
---
 INSTALL.DPDK.md |   14 --
 1 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/INSTALL.DPDK.md b/INSTALL.DPDK.md
index 96b686c..ee016da 100644
--- a/INSTALL.DPDK.md
+++ b/INSTALL.DPDK.md
@@ -145,8 +145,18 @@ Using the DPDK with ovs-vswitchd:
 
DPDK configuration arguments can be passed to vswitchd via `--dpdk`
argument. This needs to be first argument passed to vswitchd process.
-   dpdk arg -c is ignored by ovs-dpdk, but it is a required parameter
-   for dpdk initialization.
+   The DPDK configuration arguments are passed to DPDK during DPDK
+   initialization.
+
+   The DPDK -c coremask is a required argument. To avoid wasted resources
+   only one core should be set. The standard OVS threads (e.g. main
+   process, handler, revalidator) will run on the core that is specified.
+
+   Note: Ideally the -c coremask should not overlap with any pmd-cpu-mask
+   setting where the DPDK polling threads will run to avoid cpu contention.
+
+   The DPDK -n argument is a required argument that is a DPDK optimization
+   for the number of memory channels. It is typically set to 4.
 
```
export DB_SOCK=/usr/local/var/run/openvswitch/db.sock
-- 
1.7.4.1

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 2/2] support L3 logical router in vtep emulator

[Justin Pettit]

> On Dec 7, 2015, at 9:15 AM, Ben Pfaff  wrote:
> 
> On Tue, Dec 08, 2015 at 07:35:44AM +0800, Shuangmin Zhang wrote:
>> This patch is to support L3 DLR E-W traffic functionality in ovs-vtep. So it 
>> is focus on supporting switch-binding field in Logical_Router Table schema. 
>> 
>> Like what we do for logical switch, there are 2 parts of work
> 
> Is there a patch 1/2 somewhere?

I'd asked him (off-list) to resubmit the patch with a couple of superficial 
fixes.  I think he meant this to be "v2", not "2/2".

--Justin


___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] ovn-nbctl:What are router commands like?

[Russell Bryant]

On 12/04/2015 12:10 AM, Wei Li wrote:
> I have created a pull request on git for adding db commands help

Saw it, and replied.  :-)

https://github.com/openvswitch/ovs/pull/93

> and I want to change the output of "/ovn-nbctl show/"
> 
> 1: "ovn-nbctl show" will print all switch and all router like this:
> lswitch 363cf780-c233-4cbd-a9b3-57bfad8dc907
> (neutron-9822d5dd-017c-4c82-92d8-8b71f7d55255)
> lport 9e8378b9-80b2-4d6a-864a-6d378bcc4a66
> addresses: fa:16:3e:4c:3b:fc 1.1.1.1
> lport 9f36e7fc-372f-45c4-bca5-aac172bd4ac6
> addresses: fa:16:3e:74:6a:65 1.1.1.2
> lswitch 654c9341-e29b-4575-af9a-8f3a698ba8b4
> (neutron-8b3dbb6d-2dab-41c9-9c1f-66e0a489484b)
> lport f9becbbb-fbdf-49bb-92fc-25fc2aacf019
> addresses: fa:16:3e:6d:55:00 2.2.2.1
> lport 2af73da5-c1f1-4d78-9997-3e6be6d8a36a
> addresses: fa:16:3e:f0:96:0d 2.2.2.2
> lrouter fb3b447d-b287-46c4-a663-1a5cb95b42f2
> (neutron-17941229-a31e-4033-a845-5fada1922325)
> lport 9e8378b9-80b2-4d6a-864a-6d378bcc4a66
> network: 1.1.1.1/24
> mac: fa:16:3e:4c:3b:fc
> lport f9becbbb-fbdf-49bb-92fc-25fc2aacf019
> network: 2.2.2.1/24
> mac: fa:16:3e:6d:55:00

This seems fine to me.

> 2: delete "/show LSWITCH/"   use "/list TBL [REC]/" for specified one
> 
> is ok?

I'm looking at this again and I think it's worth keeping because the
output is a bit friendlier.

How about supporting both "show LSWITCH" and "show LROUTER".  The
implementation would just have to search both tables for a match on name
or UUID.

-- 
Russell Bryant
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH] datapath: Avoid warning for unused static data on Linux <=3.9.0.

[Ben Pfaff]

Signed-off-by: Ben Pfaff 
---
 datapath/actions.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/datapath/actions.c b/datapath/actions.c
index 0d6375f..9dccf47 100644
--- a/datapath/actions.c
+++ b/datapath/actions.c
@@ -68,7 +68,9 @@ struct ovs_frag_data {
u8 l2_data[MAX_L2_LEN];
 };
 
+#if LINUX_VERSION_CODE > KERNEL_VERSION(3,9,0)
 static DEFINE_PER_CPU(struct ovs_frag_data, ovs_frag_data_storage);
+#endif
 
 #define DEFERRED_ACTION_FIFO_SIZE 10
 struct action_fifo {
-- 
2.1.3

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] new warnings

[Ben Pfaff]

On Fri, Dec 04, 2015 at 08:22:31AM -0800, Ben Pfaff wrote:
> I'm getting the following new warnings since the big backports series.
> This is with GCC 4.9 and Linux 3.2:

I sent a patch for one of the warnings:
http://openvswitch.org/pipermail/dev/2015-December/063108.html
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH] FAQ: Add entry about different datapaths features.

[Daniele Di Proietto]

This is an easy way to keep track of the features supported by the
different datapaths.

Nithin helped filling the list for the Hyper-V port.

CC: Nithin Raju 
Signed-off-by: Daniele Di Proietto 
---
 FAQ.md | 64 
 1 file changed, 64 insertions(+)

diff --git a/FAQ.md b/FAQ.md
index 8397e0f..aaf2026 100644
--- a/FAQ.md
+++ b/FAQ.md
@@ -188,6 +188,70 @@ A: Features are gradually introduced into the upstream 
kernel so unless
 |STT| 2.4+ | 3.5+
 | Conntrack | 2.5+ | 3.10+
 
+### Q: Are all features available with all datapaths?
+
+A: Open vSwitch supports different datapaths on different platforms.  Each
+   datapath has a different feature set: the following tables try to summarize
+   the status.
+
+   Supported datapaths:
+
+   * *Linux upstream*: The datapath implemented by the kernel module shipped
+   with the upstream Linux kernel.  The numbers here refer
+   to the minimum Linux version that has an openvswitch
+   module supporting a feature.
+
+   * *Linux OVS tree*: The datapath implemented by the Linux kernel module
+   distributed with the OVS source tree. The numbers here
+   refer to the minimum Linux kernel version against which
+   the module can be compiled to support a feature.
+
+   * *Userspace*: Also known as DPDK, dpif-netdev or dummy datapath.
+
+   * *Hyper-V*: Also known as the windows datapath.
+
+   The following table lists the datapath supported features from
+   an Open vSwitch user's perspective.
+
+Feature   | Linux upstream | Linux OVS tree | Userspace | Hyper-V |
+--|:--:|:--:|:-:|:---:|
+Connection tracking   |  4.3   |   3.10 |NO |   NO|
+Tunnel - LISP |  NO|   YES  |NO |   NO|
+Tunnel - STT  |  NO|   3.5  |NO |   YES   |
+Tunnel - GRE  |  3.11  |   YES  |YES|   NO|
+Tunnel - VXLAN|  3.12  |   YES  |YES|   YES   |
+Tunnel - Geneve   |  3.18  |   YES  |YES|   NO|
+QoS   |  YES   |   YES  |NO |   NO|
+sFlow |  YES   |   YES  |YES|   NO|
+Set action|  YES   |   YES  |YES| PARTIAL |
+NIC Bonding   |  YES   |   YES  |YES|   NO|
+Multiple VTEPs|  YES   |   YES  |YES|   NO|
+
+   **Notes:** 
+   * Only a limited set of flow fields is modifiable via the set action by the
+ Hyper-V datapath.
+   * The Hyper-V datapath only supports one physical NIC per datapath. This is
+ why bonding is not supported.
+   * The Hyper-V datapath can have at most one IP address configured as a
+ tunnel endpoint.
+   
+   The following table lists features that do not *directly* impact an
+   Open vSwitch user, e.g. because their absence can be hidden by the ofproto
+   layer (usually this comes with a performance penalty).
+
+Feature   | Linux upstream | Linux OVS tree | Userspace | Hyper-V |
+--|:--:|:--:|:-:|:---:|
+SCTP flows|  3.12  |   YES  |YES|   YES   |
+MPLS  |  3.19  |   YES  |YES|   NO|
+UFID  |  4.0   |   YES  |YES|   NO|
+Megaflows |  3.12  |   YES  |YES|   NO|
+Masked set action |  4.0   |   YES  |YES|   NO|
+Recirculation |  3.19  |   YES  |YES|   NO|
+TCP flags matching|  3.13  |   YES  |YES|   NO|
+Validate flow actions |  YES   |   YES  |N/A|   NO|
+Multiple datapaths|  YES   |   YES  |YES|   NO|
+Tunnel TSO - STT  |  N/A   |   YES  |NO |   YES   |
+
 ### Q: I get an error like this when I configure Open vSwitch:
 
configure: error: Linux kernel in  is version , but
-- 
2.1.4

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH] datapath-windows: reduce padding size in _OVS_PACKET_HDR_INFO

[Nithin Raju]

Fixing a little buglet from commit: efee3309.

Signed-by: Nithin Raju 
---
 datapath-windows/ovsext/NetProto.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/datapath-windows/ovsext/NetProto.h 
b/datapath-windows/ovsext/NetProto.h
index a364869..c60081a 100644
--- a/datapath-windows/ovsext/NetProto.h
+++ b/datapath-windows/ovsext/NetProto.h
@@ -205,7 +205,7 @@ typedef union _OVS_PACKET_HDR_INFO {
 UINT16 tcpCsumNeeded:1;
 UINT16 udpCsumNeeded:1;
 UINT16 udpCsumZero:1;
-UINT16 pad:9;
+UINT16 pad:8;
 } ;
 UINT64 value;
 } OVS_PACKET_HDR_INFO, *POVS_PACKET_HDR_INFO;
-- 
1.8.5.6

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 2/2] support L3 logical router in vtep emulator

[Shuangmin Zhang]

Yeah, while I generated patch with form-patch,  it generated 2 patches,
another is 0001-ofproto-dpif-Validate-NAT-action-support.patch,  but that
is not my code change, don¹t know why it comes up. It is a already
checkin-patch by Daniele Di.

Thanks
Shuangmin.

On 12/8/15, 1:58 AM, "Justin Pettit"  wrote:

>
>> On Dec 7, 2015, at 9:15 AM, Ben Pfaff  wrote:
>> 
>> On Tue, Dec 08, 2015 at 07:35:44AM +0800, Shuangmin Zhang wrote:
>>> This patch is to support L3 DLR E-W traffic functionality in ovs-vtep.
>>>So it is focus on supporting switch-binding field in Logical_Router
>>>Table schema. 
>>> 
>>> Like what we do for logical switch, there are 2 parts of work
>> 
>> Is there a patch 1/2 somewhere?
>
>I'd asked him (off-list) to resubmit the patch with a couple of
>superficial fixes.  I think he meant this to be "v2", not "2/2".
>
>--Justin
>
>

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 2/2] support L3 logical router in vtep emulator

[Ben Pfaff]

Using "git format-patch -1" if you want to generate one patch.

On Mon, Dec 07, 2015 at 11:19:41PM +, Shuangmin Zhang wrote:
> Yeah, while I generated patch with form-patch,  it generated 2 patches,
> another is 0001-ofproto-dpif-Validate-NAT-action-support.patch,  but that
> is not my code change, don¹t know why it comes up. It is a already
> checkin-patch by Daniele Di.
> 
> Thanks
> Shuangmin.
> 
> On 12/8/15, 1:58 AM, "Justin Pettit"  wrote:
> 
> >
> >> On Dec 7, 2015, at 9:15 AM, Ben Pfaff  wrote:
> >> 
> >> On Tue, Dec 08, 2015 at 07:35:44AM +0800, Shuangmin Zhang wrote:
> >>> This patch is to support L3 DLR E-W traffic functionality in ovs-vtep.
> >>>So it is focus on supporting switch-binding field in Logical_Router
> >>>Table schema. 
> >>> 
> >>> Like what we do for logical switch, there are 2 parts of work
> >> 
> >> Is there a patch 1/2 somewhere?
> >
> >I'd asked him (off-list) to resubmit the patch with a couple of
> >superficial fixes.  I think he meant this to be "v2", not "2/2".
> >
> >--Justin
> >
> >
> 
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH] NEWS: Improve organization.

[Ben Pfaff]

From: Ben Pfaff 

Signed-off-by: Ben Pfaff 
---
I'd like to apply this to master and branch-2.5.  I think it makes
it a little easier to read.

 NEWS | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/NEWS b/NEWS
index e1f3d33..a6b1599 100644
--- a/NEWS
+++ b/NEWS
@@ -15,20 +15,19 @@ v2.5.0 - xx xxx 
  * OpenFlow 1.4+ OFPTC_VACANCY_EVENTS is now implemented.
  * OpenFlow 1.4+ OFPMP_TABLE_DESC is now implemented.
  * Allow modifying the ICMPv4/ICMPv6 type and code fields.
+ * OpenFlow 1.4+ OFPT_SET_ASYNC_CONFIG and OFPT_GET_ASYNC_CONFIG are
+   now implemented.
- ovs-ofctl:
  * New "out_group" keyword for OpenFlow 1.1+ matching on output group.
-   - Support for matching/generating options as well as the OAM bit with
- Geneve tunnels.
+   - Tunnels:
+ * Geneve tunnels can now match and set options and the OAM bit.
+ * The nonstandard GRE64 tunnel extension has been dropped.
- Support Multicast Listener Discovery (MLDv1 and MLDv2).
- Add 'symmetric_l3l4' and 'symmetric_l3l4+udp' hash functions.
- sFlow agent now reports tunnel and MPLS structures.
-   - Added OpenFlow 1.4+ OFPT_SET_ASYNC_CONFIG and OFPT_GET_ASYNC_CONFIG
- that allows controllers to have more precise control over OpenFlow1.4
- asynchronous messages.
- New 'check-system-userspace', 'check-kmod' and 'check-kernel' Makefile
  targets to run a new system testsuite.  These tests can be run inside
  a Vagrant box.  See INSTALL.md for details
-   - Dropped support for GRE64 tunnel.
- Mark --syslog-target argument as deprecated.  It will be removed in
  the next OVS release.
- Added --user option to all daemons
-- 
2.1.3

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] NEWS: Improve organization.

[Ben Pfaff]

On Mon, Dec 07, 2015 at 03:29:08PM -0800, Ben Pfaff wrote:
> From: Ben Pfaff 
> 
> Signed-off-by: Ben Pfaff 
> ---
> I'd like to apply this to master and branch-2.5.  I think it makes
> it a little easier to read.

I've been sitting on this for a while, so it still has old email
addresses on it.  I'll fix that before committing, of course.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] NEWS: Improve organization.

[Justin Pettit]

> On Dec 7, 2015, at 3:31 PM, Ben Pfaff  wrote:
> 
> On Mon, Dec 07, 2015 at 03:29:08PM -0800, Ben Pfaff wrote:
>> From: Ben Pfaff 
>> 
>> Signed-off-by: Ben Pfaff 
>> ---
>> I'd like to apply this to master and branch-2.5.  I think it makes
>> it a little easier to read.
> 
> I've been sitting on this for a while, so it still has old email
> addresses on it.  I'll fix that before committing, of course.

Acked-by: Justin Pettit 

--Justin




___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] ovn-nbctl:What are router commands like?

[Ben Pfaff]

On Mon, Dec 07, 2015 at 01:13:27PM -0500, Russell Bryant wrote:
> I'm looking at this again and I think it's worth keeping because the
> output is a bit friendlier.
> 
> How about supporting both "show LSWITCH" and "show LROUTER".  The
> implementation would just have to search both tables for a match on name
> or UUID.

I guess that lswitch-show and lrouter-show might be OK too.

For ovs-vsctl, I don't think that "show" supports any arguments at all.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] FAQ: Add entry about different datapaths features.

[Ben Pfaff]

On Mon, Dec 07, 2015 at 01:00:46PM -0800, Daniele Di Proietto wrote:
> This is an easy way to keep track of the features supported by the
> different datapaths.
> 
> Nithin helped filling the list for the Hyper-V port.
> 
> CC: Nithin Raju 
> Signed-off-by: Daniele Di Proietto 

This looks really nice.

I think that "userspace" also includes the NetBSD and FreeBSD ports, so
it might be nice to mention that.

I didn't read the entries in detail.  It might be nice to let people
take a day or so to verify that they think the entries are correct.

Acked-by: Ben Pfaff 
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] datapath: Avoid warning for unused static data on Linux <=3.9.0.

[Pravin Shelar]

On Mon, Dec 7, 2015 at 12:34 PM, Ben Pfaff  wrote:
> Signed-off-by: Ben Pfaff 

Acked-by: Pravin B Shelar 

Thanks.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] NEWS: Improve organization.

[Ben Pfaff]

On Mon, Dec 07, 2015 at 03:36:24PM -0800, Justin Pettit wrote:
> 
> > On Dec 7, 2015, at 3:31 PM, Ben Pfaff  wrote:
> > 
> > On Mon, Dec 07, 2015 at 03:29:08PM -0800, Ben Pfaff wrote:
> >> From: Ben Pfaff 
> >> 
> >> Signed-off-by: Ben Pfaff 
> >> ---
> >> I'd like to apply this to master and branch-2.5.  I think it makes
> >> it a little easier to read.
> > 
> > I've been sitting on this for a while, so it still has old email
> > addresses on it.  I'll fix that before committing, of course.
> 
> Acked-by: Justin Pettit 

Thanks.  I applied this to master and branch-2.5.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] datapath-windows: Support for OVS_KEY_ATTR_MPLS attribute

[Nithin Raju]

Hi Sorin,
I found some bugs in OvsActionMplsPush(). Can you pls. clarify if my
comments are valid? If they are genuine bugs, did your testing not catch
them? Apologies, if I missed anything.

I¹ll review the rest of the patch after the claritification.

Thanks,
-- Nithin

-Original Message-
From: dev  on behalf of Sorin Vinturis

Date: Wednesday, November 11, 2015 at 12:11 PM
To: "dev@openvswitch.org" 
Subject: [ovs-dev] [PATCH] datapath-windows: Support for
OVS_KEY_ATTR_MPLS   attribute

>This patch adds OVS_KEY_ATTR_MPLS to the OVS flow mechanism.
>
>Signed-off-by: Sorin Vinturis 
>---
> datapath-windows/ovsext/Actions.c  | 176
>+
> datapath-windows/ovsext/DpInternal.h   |   7 ++
> datapath-windows/ovsext/Ethernet.h |   2 +
> datapath-windows/ovsext/Flow.c |  89 -
> datapath-windows/ovsext/NetProto.h |  33 +++
> datapath-windows/ovsext/PacketParser.c |  12 +--
> datapath-windows/ovsext/PacketParser.h |   7 ++
> 7 files changed, 318 insertions(+), 8 deletions(-)
>
>diff --git a/datapath-windows/ovsext/Actions.c
>b/datapath-windows/ovsext/Actions.c
>index ce592b3..9ee1763 100644
>--- a/datapath-windows/ovsext/Actions.c
>+++ b/datapath-windows/ovsext/Actions.c
>@@ -1074,6 +1074,142 @@ OvsPopVlanInPktBuf(OvsForwardingContext
>*ovsFwdCtx)
> return NDIS_STATUS_SUCCESS;
> }
> 
>+static __inline NDIS_STATUS
>+OvsActionMplsPush(OvsForwardingContext *ovsFwdCtx,
>+  const struct ovs_action_push_mpls *mpls)
>+{
>+NDIS_STATUS status;
>+PNET_BUFFER curNb = NULL;
>+PMDL curMdl = NULL;
>+PUINT8 bufferStart = NULL;
>+OVS_PACKET_HDR_INFO *layers = &ovsFwdCtx->layers;
>+EthHdr *ethHdr = NULL;
>+MPLSHdr *mplsHdr = NULL;
>+UINT32 mdlLen = 0, curMdlOffset = 0;
>+UINT32 packetLen = 0;
>+PNET_BUFFER_LIST newNbl;
>+
>+curNb = NET_BUFFER_LIST_FIRST_NB(ovsFwdCtx->curNbl);
>+ASSERT(curNb->Next == NULL);
>+packetLen = NET_BUFFER_DATA_LENGTH(curNb);
>+curMdl = NET_BUFFER_CURRENT_MDL(curNb);
>+NdisQueryMdl(curMdl, &bufferStart, &mdlLen, LowPagePriority);
>+if (!bufferStart) {
>+ovsActionStats.noResource++;
>+return NDIS_STATUS_RESOURCES;
>+}
>+curMdlOffset = NET_BUFFER_CURRENT_MDL_OFFSET(curNb);
>+mdlLen -= curMdlOffset;
>+mdlLen -= NET_BUFFER_CURRENT_MDL_OFFSET(curNb);
>+ASSERT(mdlLen > 0);
>+/* Bail out if the L2 header is not in a contiguous buffer. */
>+if (MIN(packetLen, mdlLen) < sizeof *ethHdr) {
>+ASSERT(FALSE);
>+return NDIS_STATUS_FAILURE;
>+}
>+ASSERT((INT)mdlLen >= 0);

You don¹t need any of these checks if the NBL is going to be copied
anyway. These checks are needed if you are going to modify the packet
inline. Look at OvsUpdateIPv4Header() for correct usage.

>+
>+newNbl = OvsPartialCopyNBL(ovsFwdCtx->switchContext,
>ovsFwdCtx->curNbl,
>+   MPLS_HLEN, 0, TRUE /*copy NBL info*/);

What is the intention of this partial copy? Are you trying to allocate
more headroom or creating a copy so as to update the L2 header?

You probably want to do:
newNbl = OvsPartialCopyNBL(ovsFwdCtx->switchContext, ovsFwdCtx->curNbl,
   L2 Header size + MPLS_HLEN, MPLS_HLEN, TRUE
/*copy NBL info*/);


>+if (!newNbl) {
>+ovsActionStats.noCopiedNbl++;
>+return NDIS_STATUS_RESOURCES;
>+}
>+OvsCompleteNBLForwardingCtx(ovsFwdCtx,
>+L"Complete after partial copy.");
>+
>+status = OvsInitForwardingCtx(ovsFwdCtx, ovsFwdCtx->switchContext,
>+  newNbl, ovsFwdCtx->srcVportNo, 0,
>+ 
>NET_BUFFER_LIST_SWITCH_FORWARDING_DETAIL(newNbl),
>+  NULL, &ovsFwdCtx->layers, FALSE);
>+if (status != NDIS_STATUS_SUCCESS) {
>+OvsCompleteNBLForwardingCtx(ovsFwdCtx,
>+L"OVS-Dropped due to resources");
>+return NDIS_STATUS_RESOURCES;
>+}
>+
>+curNb = NET_BUFFER_LIST_FIRST_NB(ovsFwdCtx->curNbl);
>+ASSERT(curNb->Next == NULL);
>+curMdl = NET_BUFFER_CURRENT_MDL(curNb);
>+NdisQueryMdl(curMdl, &bufferStart, &mdlLen, LowPagePriority);
>+if (!curMdl) {
>+ovsActionStats.noResource++;
>+return NDIS_STATUS_RESOURCES;
>+}
>+curMdlOffset = NET_BUFFER_CURRENT_MDL_OFFSET(curNb);
>+mdlLen -= curMdlOffset;
>+ASSERT(mdlLen >= MPLS_HLEN);
>+
>+ethHdr = (EthHdr *)(bufferStart + curMdlOffset);
>+ethHdr->Type = mpls->mpls_ethertype;
>+
>+mplsHdr = (MPLSHdr *)(bufferStart + curMdlOffset + MPLS_HLEN);

mplsHdr should be at: (void *)ethHdr + MPLS_HLEN.

>+mplsHdr->mpls_lse = mpls->mpls_lse;

As I understood, the packet was like:
ETH + IP

The new NBL just after the partial copy looks like:
HEADROOM (4B) + ETH + IP

You want this to look like:
ETH + MPLS + IP

You need to left shift the Eth header, including the source and
destination MAC address

Re: [ovs-dev] [PATCH] FAQ: Add entry about different datapaths features.

[Daniele Di Proietto]

On 07/12/2015 15:49, "Ben Pfaff"  wrote:

>On Mon, Dec 07, 2015 at 01:00:46PM -0800, Daniele Di Proietto wrote:
>> This is an easy way to keep track of the features supported by the
>> different datapaths.
>> 
>> Nithin helped filling the list for the Hyper-V port.
>> 
>> CC: Nithin Raju 
>> Signed-off-by: Daniele Di Proietto 
>
>This looks really nice.
>
>I think that "userspace" also includes the NetBSD and FreeBSD ports, so
>it might be nice to mention that.

Good point, I'll mention that.

>I didn't read the entries in detail.  It might be nice to let people
>take a day or so to verify that they think the entries are correct.

Sure, I'll wait for more feedback.

>Acked-by: Ben Pfaff 

Thanks for the review!

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH 2/4] datapath: Backport: openvswitch: properly refcount vport-vxlan module

[Pravin B Shelar]

Upstream commit:
After 614732eaa12d, no refcount is maintained for the vport-vxlan module.
This allows the userspace to remove such module while vport-vxlan
devices still exist, which leads to later oops.

v1 -> v2:
 - move vport 'owner' initialization in ovs_vport_ops_register()
   and make such function a macro

Fixes: 614732eaa12d ("openvswitch: Use regular VXLAN net_device device")
Signed-off-by: Paolo Abeni 
Signed-off-by: David S. Miller 

Upstream: 83e4bf7a74 ("openvswitch: properly refcount vport-vxlan
module").
Signed-off-by: Pravin B Shelar 
---
 datapath/vport-geneve.c |1 -
 datapath/vport-gre.c|1 -
 datapath/vport-lisp.c   |1 -
 datapath/vport-stt.c|1 -
 datapath/vport.c|4 ++--
 datapath/vport.h|8 +++-
 6 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/datapath/vport-geneve.c b/datapath/vport-geneve.c
index 3b5c1ab..392d750 100644
--- a/datapath/vport-geneve.c
+++ b/datapath/vport-geneve.c
@@ -129,7 +129,6 @@ static struct vport_ops ovs_geneve_vport_ops = {
.destroy= ovs_netdev_tunnel_destroy,
.get_options= geneve_get_options,
.send   = geneve_xmit,
-   .owner  = THIS_MODULE,
.get_egress_tun_info= geneve_get_egress_tun_info,
 };
 
diff --git a/datapath/vport-gre.c b/datapath/vport-gre.c
index a9ac0d4..50aaba5 100644
--- a/datapath/vport-gre.c
+++ b/datapath/vport-gre.c
@@ -97,7 +97,6 @@ static struct vport_ops ovs_gre_vport_ops = {
.send   = gre_fb_xmit,
.get_egress_tun_info= gre_get_egress_tun_info,
.destroy= ovs_netdev_tunnel_destroy,
-   .owner  = THIS_MODULE,
 };
 
 static int __init ovs_gre_tnl_init(void)
diff --git a/datapath/vport-lisp.c b/datapath/vport-lisp.c
index e6c00fa..3ce8613 100644
--- a/datapath/vport-lisp.c
+++ b/datapath/vport-lisp.c
@@ -129,7 +129,6 @@ static struct vport_ops ovs_lisp_vport_ops = {
.destroy= ovs_netdev_tunnel_destroy,
.get_options= lisp_get_options,
.send   = lisp_xmit,
-   .owner  = THIS_MODULE,
.get_egress_tun_info= lisp_get_egress_tun_info,
 };
 
diff --git a/datapath/vport-stt.c b/datapath/vport-stt.c
index 9e2079a..b8e0c88 100644
--- a/datapath/vport-stt.c
+++ b/datapath/vport-stt.c
@@ -131,7 +131,6 @@ static struct vport_ops ovs_stt_vport_ops = {
.destroy= ovs_netdev_tunnel_destroy,
.get_options= stt_get_options,
.send   = ovs_stt_xmit,
-   .owner  = THIS_MODULE,
.get_egress_tun_info= stt_get_egress_tun_info,
 };
 
diff --git a/datapath/vport.c b/datapath/vport.c
index 899119f..01702d7 100644
--- a/datapath/vport.c
+++ b/datapath/vport.c
@@ -113,7 +113,7 @@ static struct hlist_head *hash_bucket(const struct net 
*net, const char *name)
return &dev_table[hash & (VPORT_HASH_BUCKETS - 1)];
 }
 
-int ovs_vport_ops_register(struct vport_ops *ops)
+int __ovs_vport_ops_register(struct vport_ops *ops)
 {
int err = -EEXIST;
struct vport_ops *o;
@@ -129,7 +129,7 @@ errout:
ovs_unlock();
return err;
 }
-EXPORT_SYMBOL_GPL(ovs_vport_ops_register);
+EXPORT_SYMBOL_GPL(__ovs_vport_ops_register);
 
 void ovs_vport_ops_unregister(struct vport_ops *ops)
 {
diff --git a/datapath/vport.h b/datapath/vport.h
index d820719..33c3935 100644
--- a/datapath/vport.h
+++ b/datapath/vport.h
@@ -212,7 +212,13 @@ static inline const char *ovs_vport_name(struct vport 
*vport)
return vport->dev->name;
 }
 
-int ovs_vport_ops_register(struct vport_ops *ops);
+int __ovs_vport_ops_register(struct vport_ops *ops);
+#define ovs_vport_ops_register(ops)\
+({ \
+   (ops)->owner = THIS_MODULE; \
+   __ovs_vport_ops_register(ops);  \
+})
+
 void ovs_vport_ops_unregister(struct vport_ops *ops);
 
 static inline struct rtable *ovs_tunnel_route_lookup(struct net *net,
-- 
1.7.1

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH 0/4] datapath: Backported upstream fixes.

[Pravin B Shelar]

Few important bugfixes for OVS out of tree module.

Pravin B Shelar (4):
  datapath: Backport: openvswitch: fix hangup on vxlan/gre/geneve
device deletion
  datapath: Backport: openvswitch: properly refcount vport-vxlan module
  datapath: Backport: vxlan: fix incorrect RCO bit in VXLAN header
  datapath: Backport: vxlan: interpret IP headers for ECN correctly

 datapath/dp_notify.c  |2 +-
 datapath/linux/compat/include/net/vxlan.h |2 +-
 datapath/linux/compat/vxlan.c |6 ++
 datapath/vport-geneve.c   |1 -
 datapath/vport-gre.c  |1 -
 datapath/vport-lisp.c |1 -
 datapath/vport-netdev.c   |   10 --
 datapath/vport-stt.c  |1 -
 datapath/vport.c  |4 ++--
 datapath/vport.h  |8 +++-
 10 files changed, 21 insertions(+), 15 deletions(-)

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH 4/4] datapath: Backport: vxlan: interpret IP headers for ECN correctly

[Pravin B Shelar]

Upstream commit:
When looking for outer IP header, use the actual socket address family, not
the address family of the default destination which is not set for metadata
based interfaces (and doesn't have to match the address family of the
received packet even if it was set).

Fix also the misleading comment.

Signed-off-by: Jiri Benc 
Signed-off-by: David S. Miller 

Upstream: ce212d0f6f5 ("vxlan: interpret IP headers for ECN correctly")
Signed-off-by: Pravin B Shelar 
---
 datapath/linux/compat/vxlan.c |6 ++
 1 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/datapath/linux/compat/vxlan.c b/datapath/linux/compat/vxlan.c
index 4076a2f..dd0015d 100644
--- a/datapath/linux/compat/vxlan.c
+++ b/datapath/linux/compat/vxlan.c
@@ -824,7 +824,6 @@ static void vxlan_rcv(struct vxlan_sock *vs, struct sk_buff 
*skb,
 #endif
union vxlan_addr saddr;
int err = 0;
-   union vxlan_addr *remote_ip;
 
/* For flow based devices, map all packets to VNI 0 */
if (vs->flags & VXLAN_F_COLLECT_METADATA)
@@ -835,7 +834,6 @@ static void vxlan_rcv(struct vxlan_sock *vs, struct sk_buff 
*skb,
if (!vxlan)
goto drop;
 
-   remote_ip = &vxlan->default_dst.remote_ip;
skb_reset_mac_header(skb);
skb_scrub_packet(skb, !net_eq(vxlan->net, dev_net(vxlan->dev)));
skb->protocol = eth_type_trans(skb, vxlan->dev);
@@ -845,8 +843,8 @@ static void vxlan_rcv(struct vxlan_sock *vs, struct sk_buff 
*skb,
if (ether_addr_equal(eth_hdr(skb)->h_source, vxlan->dev->dev_addr))
goto drop;
 
-   /* Re-examine inner Ethernet packet */
-   if (remote_ip->sa.sa_family == AF_INET) {
+   /* Get data from the outer IP header */
+   if (vxlan_get_sk_family(vs) == AF_INET) {
oip = ip_hdr(skb);
saddr.sin.sin_addr.s_addr = oip->saddr;
saddr.sa.sa_family = AF_INET;
-- 
1.7.1

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH 3/4] datapath: Backport: vxlan: fix incorrect RCO bit in VXLAN header

[Pravin B Shelar]

Upstream commit:
Commit 3511494ce2f3d ("vxlan: Group Policy extension") changed definition of
VXLAN_HF_RCO from 0x0020 to BIT(24). This is obviously incorrect. It's
also in violation with the RFC draft.

Fixes: 3511494ce2f3d ("vxlan: Group Policy extension")
Cc: Thomas Graf 
Cc: Tom Herbert 
Signed-off-by: Jiri Benc 
Acked-by: Tom Herbert 
Signed-off-by: David S. Miller 

Upstream: c5fb8caaf91 ("vxlan: fix incorrect RCO bit in VXLAN header")
Signed-off-by: Pravin B Shelar 
---
 datapath/linux/compat/include/net/vxlan.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/datapath/linux/compat/include/net/vxlan.h 
b/datapath/linux/compat/include/net/vxlan.h
index 13de97a..b50cd17 100644
--- a/datapath/linux/compat/include/net/vxlan.h
+++ b/datapath/linux/compat/include/net/vxlan.h
@@ -101,7 +101,7 @@ struct vxlanhdr {
 };
 
 /* VXLAN header flags. */
-#define VXLAN_HF_RCO BIT(24)
+#define VXLAN_HF_RCO BIT(21)
 #define VXLAN_HF_VNI BIT(27)
 #define VXLAN_HF_GBP BIT(31)
 
-- 
1.7.1

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH 1/4] datapath: Backport: openvswitch: fix hangup on vxlan/gre/geneve device deletion

[Pravin B Shelar]

Upstream commit:

Each openvswitch tunnel vport (vxlan,gre,geneve) holds a reference
to the underlying tunnel device, but never released it when such
device is deleted.
Deleting the underlying device via the ip tool cause the kernel to
hangup in the netdev_wait_allrefs() loop.
This commit ensure that on device unregistration dp_detach_port_notify()
is called for all vports that hold the device reference, properly
releasing it.

Fixes: 614732eaa12d ("openvswitch: Use regular VXLAN net_device device")
Fixes: b2acd1dc3949 ("openvswitch: Use regular GRE net_device instead of 
vport")
Fixes: 6b001e682e90 ("openvswitch: Use Geneve device.")
Signed-off-by: Paolo Abeni 
Acked-by: Flavio Leitner 
Acked-by: Pravin B Shelar 
Signed-off-by: David S. Miller 

Upstream: 131753030("openvswitch: fix hangup on vxlan/gre/geneve device
deletion").
Signed-off-by: Pravin B Shelar 
---
 datapath/dp_notify.c|2 +-
 datapath/vport-netdev.c |   10 --
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/datapath/dp_notify.c b/datapath/dp_notify.c
index 9434c19..424f35d 100644
--- a/datapath/dp_notify.c
+++ b/datapath/dp_notify.c
@@ -60,7 +60,7 @@ void ovs_dp_notify_wq(struct work_struct *work)
struct hlist_node *n;
 
hlist_for_each_entry_safe(vport, n, &dp->ports[i], 
dp_hash_node) {
-   if (vport->ops->type != OVS_VPORT_TYPE_NETDEV)
+   if (vport->ops->type == OVS_VPORT_TYPE_INTERNAL)
continue;
 
if (!(vport->dev->priv_flags & 
IFF_OVS_DATAPATH))
diff --git a/datapath/vport-netdev.c b/datapath/vport-netdev.c
index 21431d3..a1df79b 100644
--- a/datapath/vport-netdev.c
+++ b/datapath/vport-netdev.c
@@ -213,9 +213,15 @@ void ovs_netdev_tunnel_destroy(struct vport *vport)
if (vport->dev->priv_flags & IFF_OVS_DATAPATH)
ovs_netdev_detach_dev(vport);
 
-   /* Early release so we can unregister the device */
+   /* We can be invoked by both explicit vport deletion and
+* underlying netdev deregistration; delete the link only
+* if it's not already shutting down.
+*/
+
+   if (vport->dev->reg_state == NETREG_REGISTERED)
+   rtnl_delete_link(vport->dev);
+
dev_put(vport->dev);
-   rtnl_delete_link(vport->dev);
vport->dev = NULL;
rtnl_unlock();
 
-- 
1.7.1

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 0/4] datapath: Backported upstream fixes.

[Jesse Gross]

On Mon, Dec 7, 2015 at 6:23 PM, Pravin B Shelar  wrote:
> Few important bugfixes for OVS out of tree module.
>
> Pravin B Shelar (4):
>   datapath: Backport: openvswitch: fix hangup on vxlan/gre/geneve
> device deletion
>   datapath: Backport: openvswitch: properly refcount vport-vxlan module
>   datapath: Backport: vxlan: fix incorrect RCO bit in VXLAN header
>   datapath: Backport: vxlan: interpret IP headers for ECN correctly

All of these look good to me.

Acked-by: Jesse Gross 
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [ovs] ovn-nbctl:add db commands help (#93)

[Wei Li]

在 2015/12/7 23:30, Russell Bryant 写道:


Can you update the man page, as well?


I would like to do this,but have a question

There is a reference to /db-ctl-base.man/ in /ovn-sbctl.8.in/ implement 
by "/.so lib/db-ctl-base.man/"


but ovn-nbctl`s manpage is xml format

How to add a reference to another manual page in xml file?


Thanks!

—
Reply to this email directly or view it on GitHub 
.




___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] Returned mail: Data format error

[Post Office]

Dear user dev@openvswitch.org,

Your email account was used to send a huge amount of junk email during this 
week.
Probably, your computer was infected by a recent virus and now runs a trojaned 
proxy server.

Please follow the instructions in order to keep your computer safe.

Best wishes,
The openvswitch.org team.

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev