[ovs-dev] [PATCH] ovn-northd: Fix overlapping ARP/ND resolution logical flows.

[Ben Pfaff]

IPv4 and IPv6 packets have separate flows and should not overlap with a
catch-all flow that treats all packets like IPv4.  It's unpredictable what
flow actually gets chosen in this situation.

Found by inspection.

CC: Justin Pettit 
Fixes: c34a87b6c570 ("ovn: Add support for IPv6 dynamic bindings.")
Signed-off-by: Ben Pfaff 
---
 ovn/northd/ovn-northd.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
index 2cbbb47..09ae732 100644
--- a/ovn/northd/ovn-northd.c
+++ b/ovn/northd/ovn-northd.c
@@ -4053,8 +4053,6 @@ build_lrouter_flows(struct hmap *datapaths, struct hmap 
*ports,
 continue;
 }
 
-ovn_lflow_add(lflows, od, S_ROUTER_IN_ARP_RESOLVE, 0, "1",
-  "get_arp(outport, reg0); next;");
 ovn_lflow_add(lflows, od, S_ROUTER_IN_ARP_RESOLVE, 0, "ip4",
   "get_arp(outport, reg0); next;");
 
-- 
2.1.3

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

Re: [ovs-dev] [PATCH v3 3/7] system-traffic: 802.1ad: Add datapath ping tests for CVLANs.

[Joe Stringer]

On 14 September 2016 at 17:26, Eric Garver  wrote:
> Signed-off-by: Eric Garver 

Hi Eric,

I tried this series again on a variety of kernels and these initial
ping over cvlan tests are failing for check-system-userspace on older
kernels (3.10,3.13) due to reasons we had discussed a bit on the
previous version of this patch series.

Were you planning to take a look at either getting the userspace
datapath to work around these cases, or skip the tests for such
kernels?
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] Photo from Winfred

[Winfred mariae]

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

Re: [ovs-dev] [PATCH] ovs-lib: Fix SELinux contexts for created dirs.

[Joe Stringer]

On 22 September 2016 at 12:55, Ansis Atteka  wrote:
> On Thu, Sep 22, 2016 at 3:54 AM, Joe Stringer  wrote:
>> ovs-lib creates several directories directly from the script, but
>> doesn't make any attempt to ensure that the correct SELinux context is
>> applied to these directories. As a result, the created directories end
>> up with type var_run_t rather than openvswitch_var_run_t.
>>
>> During reboot using a tmpfs for /var/run, startup scripts will invoke
>> ovs-lib to create these directories with the wrong context. If SELinux
>> is enabled, OVS will fail to start as it cannot write to this directory.
>>
>> Fix the issue by sprinkling "restorecon" in each of the places where
>> directories are created. In practice, many of these should otherwise be
>> handled by packaging scripts but if they exist then we should ensure the
>> correct SELinux context is set.
>>
>> On systems where 'restorecon' is unavailable, this should be a no-op.
>>
>> VMware-BZ: #1732672
>>
>> Signed-off-by: Joe Stringer 
>
> Acked-by: Ansis Atteka 
>
> I could give Tested-by, but only in 12 hours, if you are willing to wait.

I would appreciate that. I'd like to get this in v2.6, but I think we
have a little bit of time for that.

> One thing that caught my attention is that "restorecon -R /" may take
> really long time. I guess, none of the path variables expand to / or
> any other directory that has bunch of files by default in it, do they?
>
> Also, as an optimization - would it make sense to call "restorecon
> ..." only if "test -d ..." returned false?

I think this is reasonable. I sent a v2 to do this, and not use "-R".
If this script is creating the directory, then -R is unnecessary:

http://openvswitch.org/pipermail/dev/2016-September/079848.html
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCHv2] ovs-lib: Fix SELinux contexts for created dirs.

[Joe Stringer]

ovs-lib creates several directories directly from the script, but
doesn't make any attempt to ensure that the correct SELinux context is
applied to these directories. As a result, the created directories end
up with type var_run_t rather than openvswitch_var_run_t.

During reboot using a tmpfs for /var/run, startup scripts will invoke
ovs-lib to create these directories with the wrong context. If SELinux
is enabled, OVS will fail to start as it cannot write to this directory.

Fix the issue by sprinkling "restorecon" in each of the places where
directories are created. In practice, many of these should otherwise be
handled by packaging scripts but if they exist then we should ensure the
correct SELinux context is set.

On systems where 'restorecon' is unavailable, this should be a no-op.

VMware-BZ: #1732672

Signed-off-by: Joe Stringer 
Acked-by: Ansis Atteka 
---
v2: Only restore context in dir creation case.
Don't call restorecon with -R.
---
 utilities/ovs-lib.in | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/utilities/ovs-lib.in b/utilities/ovs-lib.in
index cbad85a36007..4c07750530b6 100644
--- a/utilities/ovs-lib.in
+++ b/utilities/ovs-lib.in
@@ -148,6 +148,14 @@ version_geq() {
 }'
 }
 
+install_dir () {
+DIR="$1"
+if test ! -d "$DIR"; then
+install -d -m 755 -o root -g root "$DIR"
+restorecon "$DIR" >/dev/null 2>&1
+fi
+}
+
 start_daemon () {
 priority=$1
 wrapper=$2
@@ -156,16 +164,16 @@ start_daemon () {
 strace=""
 
 # drop core files in a sensible place
-test -d "$DAEMON_CWD" || install -d -m 755 -o root -g root "$DAEMON_CWD"
+install_dir "$DAEMON_CWD"
 set "$@" --no-chdir
 cd "$DAEMON_CWD"
 
 # log file
-test -d "$logdir" || install -d -m 755 -o root -g root "$logdir"
+install_dir "$logdir"
 set "$@" --log-file="$logdir/$daemon.log"
 
 # pidfile and monitoring
-test -d "$rundir" || install -d -m 755 -o root -g root "$rundir"
+install_dir "$rundir"
 set "$@" --pidfile="$rundir/$daemon.pid"
 set "$@" --detach
 test X"$MONITOR" = Xno || set "$@" --monitor
@@ -380,7 +388,7 @@ upgrade_db () {
 schemaver=`ovsdb_tool schema-version "$DB_SCHEMA"`
 if test ! -e "$DB_FILE"; then
 log_warning_msg "$DB_FILE does not exist"
-install -d -m 755 -o root -g root `dirname $DB_FILE`
+install_dir `dirname $DB_FILE`
 create_db "$DB_FILE" "$DB_SCHEMA"
 elif test X"`ovsdb_tool needs-conversion "$DB_FILE" "$DB_SCHEMA"`" != Xno; 
then
 # Back up the old version.
-- 
2.9.3

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

Re: [ovs-dev] [PATCH] openvswitch: Allow external IPsec tunnel management.

[pravin shelar]

On Thu, Sep 22, 2016 at 11:59 AM, Ansis Atteka  wrote:
>
>
> On 20 September 2016 at 20:52, Pravin B Shelar  wrote:
>>
>> OVS IPsec tunnel support has issues:
>> 1. It only works for GRE.
>>
>> 2. only works on Debian.
>>
>> 3. It does not allow user to match on packet-mark
>>on packet received on tunnel ports.
>>
>>
>>
>>
>> Therefore following patch provide alternative to completely
>> disable ipsec-tunnel support by vswitchd command line option.
>> This way user can use external daemon to manage IPsec tunnel
>> traffic and stir it using skb-mark match action in OVS bridge.
>>
>>
>> This patch deprecates support for IPsec tunnel port.
>
>
> There are other alternative solutions worth to mention:
> 1) remove the special meaning of skb_mark bit #0 and update
> ovs-monitor-ipsec not to depend on harcoded skb_mark value at all (I think
> this can be done with some trickery);

I am not sure what does this mean. How are you going match on IPsec traffic?

> 2) allow users to chose OVS mode where OVS can be explicitly told to either
> use skb_mark for its own needs (e.g. IPsec) OR to pass skb_mark to OpenFlow
> pipeline as-is;

This was basically this patch does but I have sent another patch to
just deprecate IPsec support. I have mentioned reasoning for the
change there.

http://openvswitch.org/pipermail/dev/2016-September/079770.html

> 3) leave bit #0 assigned to IPsec and let OpenFlow to match only on bits
> #1-32.
>
> Your solutions is kinda like 2), except it discourages uses to configure OVS
> in a way where it consumes skb_mark for itself.
>
> I think solutions 1) could be implemented even after your patch. Except,
> maybe then we should not mention that IPsec will be deprecated in the next
> release. Also, I would need to think how to address corner cases if
> ovs-monitor-ipsec can't use skb_mark anymore.
>
> Solution 3) would be great from ovs-monitor-ipsec perspective because it
> would not need to change. However, it possibly would make OpenFlow skb_mark
> matching look weird compared to other fields that OVS can match on.
>

I do not like solution 3. It does not allows OVS user to use all bits
of skb-mark even when there is no IPSEC involved which is what linux
networking stack provide.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH v2] ovn-vtep: fix arping from vtep-gw physical port

[Ramu Ramamurthy]

Currently, arping from a vtep-gw physical-switch port to
a VIF IP address does not work.

When a physical-switch-port arps for an IP address
of a VIF, that arp packet comes into the VIF hypervisor via a
vxlan tunnel. That arp packet must not be responded-to by the
arp responder table because, potentially, multiple hypervisors
could independently respond.

Signed-off-by: Ramu Ramamurthy 
---
 ovn/northd/ovn-northd.8.xml | 4 ++--
 ovn/northd/ovn-northd.c | 4 +++-
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/ovn/northd/ovn-northd.8.xml b/ovn/northd/ovn-northd.8.xml
index 1da633a..3b885f9 100644
--- a/ovn/northd/ovn-northd.8.xml
+++ b/ovn/northd/ovn-northd.8.xml
@@ -421,8 +421,8 @@
 
 
   
-Priority-100 flows to skip ARP responder if inport is of type
-localnet, and advances directly to the next table.
+Priority-100 flows to skip ARP responder if inport is not associated
+with a local VIF, and advances directly to the next table.
   
 
   
diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
index 2cbbb47..d752589 100644
--- a/ovn/northd/ovn-northd.c
+++ b/ovn/northd/ovn-northd.c
@@ -2683,7 +2683,9 @@ build_lswitch_flows(struct hmap *datapaths, struct hmap 
*ports,
 continue;
 }
 
-if (!strcmp(op->nbsp->type, "localnet")) {
+/* Skip installing arp responder if the logical switch inport
+ * is not associated with a local VIF. */
+if (strcmp(op->nbsp->type, "")) {
 ds_clear();
 ds_put_format(, "inport == %s", op->json_key);
 ovn_lflow_add(lflows, op->od, S_SWITCH_IN_ARP_ND_RSP, 100,
-- 
1.9.1

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

Re: [ovs-dev] [PATCH] ovs-lib: Fix SELinux contexts for created dirs.

[Ansis Atteka]

On Thu, Sep 22, 2016 at 3:54 AM, Joe Stringer  wrote:
> ovs-lib creates several directories directly from the script, but
> doesn't make any attempt to ensure that the correct SELinux context is
> applied to these directories. As a result, the created directories end
> up with type var_run_t rather than openvswitch_var_run_t.
>
> During reboot using a tmpfs for /var/run, startup scripts will invoke
> ovs-lib to create these directories with the wrong context. If SELinux
> is enabled, OVS will fail to start as it cannot write to this directory.
>
> Fix the issue by sprinkling "restorecon" in each of the places where
> directories are created. In practice, many of these should otherwise be
> handled by packaging scripts but if they exist then we should ensure the
> correct SELinux context is set.
>
> On systems where 'restorecon' is unavailable, this should be a no-op.
>
> VMware-BZ: #1732672
>
> Signed-off-by: Joe Stringer 

Acked-by: Ansis Atteka 

I could give Tested-by, but only in 12 hours, if you are willing to wait.

One thing that caught my attention is that "restorecon -R /" may take
really long time. I guess, none of the path variables expand to / or
any other directory that has bunch of files by default in it, do they?

Also, as an optimization - would it make sense to call "restorecon
..." only if "test -d ..." returned false?

> ---
> Fortunately, the 'install' command comes with a handy '-Z' option which
> should set the default SELinux context for a file when creating it.
> Unfortunately, this doesn't work the way we need it to - rather than
> taking the correct context for this particular file, it seems to take
> some generic global default context so it doesn't fix the problem. Using
> 'restorecon' seems like the most robust way to address this.
> ---
>  utilities/ovs-lib.in | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/utilities/ovs-lib.in b/utilities/ovs-lib.in
> index cbad85a36007..a6c446a9fbec 100644
> --- a/utilities/ovs-lib.in
> +++ b/utilities/ovs-lib.in
> @@ -157,15 +157,18 @@ start_daemon () {
>
>  # drop core files in a sensible place
>  test -d "$DAEMON_CWD" || install -d -m 755 -o root -g root "$DAEMON_CWD"
> +restorecon -R "$DAEMON_CWD" >/dev/null 2>&1
>  set "$@" --no-chdir
>  cd "$DAEMON_CWD"
>
>  # log file
>  test -d "$logdir" || install -d -m 755 -o root -g root "$logdir"
> +restorecon -R "$logdir" >/dev/null 2>&1
>  set "$@" --log-file="$logdir/$daemon.log"
>
>  # pidfile and monitoring
>  test -d "$rundir" || install -d -m 755 -o root -g root "$rundir"
> +restorecon -R "$rundir" >/dev/null 2>&1
>  set "$@" --pidfile="$rundir/$daemon.pid"
>  set "$@" --detach
>  test X"$MONITOR" = Xno || set "$@" --monitor
> @@ -381,6 +384,7 @@ upgrade_db () {
>  if test ! -e "$DB_FILE"; then
>  log_warning_msg "$DB_FILE does not exist"
>  install -d -m 755 -o root -g root `dirname $DB_FILE`
> +restorecon -R `dirname $DB_FILE` >/dev/null 2>&1
>  create_db "$DB_FILE" "$DB_SCHEMA"
>  elif test X"`ovsdb_tool needs-conversion "$DB_FILE" "$DB_SCHEMA"`" != 
> Xno; then
>  # Back up the old version.
> --
> 2.9.3
>
> ___
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH] openvswitch: Allow external IPsec tunnel management.

[Ansis Atteka]

On 20 September 2016 at 20:52, Pravin B Shelar  wrote:

> OVS IPsec tunnel support has issues:
> 1. It only works for GRE.

2. only works on Debian.

3. It does not allow user to match on packet-mark
>on packet received on tunnel ports.




> Therefore following patch provide alternative to completely
> disable ipsec-tunnel support by vswitchd command line option.
> This way user can use external daemon to manage IPsec tunnel
> traffic and stir it using skb-mark match action in OVS bridge.


> This patch deprecates support for IPsec tunnel port.
>

There are other alternative solutions worth to mention:
1) remove the special meaning of skb_mark bit #0 and update
ovs-monitor-ipsec not to depend on harcoded skb_mark value at all (I think
this can be done with some trickery);
2) allow users to chose OVS mode where OVS can be explicitly told to either
use skb_mark for its own needs (e.g. IPsec) OR to pass skb_mark to OpenFlow
pipeline as-is;
3) leave bit #0 assigned to IPsec and let OpenFlow to match only on bits
#1-32.

Your solutions is kinda like 2), except it discourages uses to configure
OVS in a way where it consumes skb_mark for itself.

I think solutions 1) could be implemented even after your patch. Except,
maybe then we should not mention that IPsec will be deprecated in the next
release. Also, I would need to think how to address corner cases if
ovs-monitor-ipsec can't use skb_mark anymore.

Solution 3) would be great from ovs-monitor-ipsec perspective because it
would not need to change. However, it possibly would make OpenFlow skb_mark
matching look weird compared to other fields that OVS can match on.



> Signed-off-by: Pravin B Shelar 
> ---
>  NEWS|  2 ++
>  debian/changelog|  2 ++
>  debian/control  |  1 +
>  lib/netdev-vport.c  |  3 +++
>  lib/netdev.c|  1 +
>  lib/netdev.h|  1 +
>  ofproto/tunnel.c| 30 ++
>  ofproto/tunnel.h|  2 ++
>  vswitchd/ovs-vswitchd.c |  7 +++
>  vswitchd/vswitch.xml|  8 
>  10 files changed, 49 insertions(+), 8 deletions(-)
>
> diff --git a/NEWS b/NEWS
> index 21ab538..057edfd 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -149,6 +149,8 @@ v2.6.0 - xx xxx 
>   * Flow based tunnel match and action can be used for IPv6 address
> using
> tun_ipv6_src, tun_ipv6_dst fields.
>   * Added support for IPv6 tunnels, for details checkout FAQ.
> + * Allow external IPsec tunnel management. Deprecated support for
> IPsec
> +   tunnels ports.
>
s/tunnels/tunnel


- A wrapper script, 'ovs-tcpdump', to easily port-mirror an OVS port and
>   watch with tcpdump
> - Introduce --no-self-confinement flag that allows daemons to work with
> diff --git a/debian/changelog b/debian/changelog
> index d73e636..8add140 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -108,6 +108,8 @@ openvswitch (2.6.0-1) unstable; urgency=low
>   * Flow based tunnel match and action can be used for IPv6 address
> using
> tun_ipv6_src, tun_ipv6_dst fields.
>   * Added support for IPv6 tunnels, for details checkout FAQ.
> + * Allow external IPsec tunnel management. Deprecated support for
> IPsec
> +   tunnels ports.
>
same here

> - A wrapper script, 'ovs-tcpdump', to easily port-mirror an OVS port
> and
>   watch with tcpdump
> - Introduce --no-self-confinement flag that allows daemons to work with
> diff --git a/debian/control b/debian/control
> index 6e704f1..da86fe9 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -200,6 +200,7 @@ Description: Open vSwitch GRE-over-IPsec support
>   .
>   The ovs-monitor-ipsec script provides support for encrypting GRE
>   tunnels with IPsec.
> + IPsec tunnels support is deprecated.
>
s/tunnels/tunneling

>
>  Package: openvswitch-pki
>  Architecture: all
> diff --git a/lib/netdev-vport.c b/lib/netdev-vport.c
> index 8d22cf5..6bf4d2d 100755
> --- a/lib/netdev-vport.c
> +++ b/lib/netdev-vport.c
> @@ -543,6 +543,9 @@ set_tunnel_config(struct netdev *dev_, const struct
> smap *args)
>  static struct ovs_mutex mutex = OVS_MUTEX_INITIALIZER;
>  static pid_t pid = 0;
>
> +VLOG_ERR("%s: OVS IPsec tunnel support is deprecated. "
> + "See man page for details", name);
> +
>
I believe IPsec does not work anymore with the command line argument you
introduced. Should you give a special warning message in that case?

>  #ifndef _WIN32
>  ovs_mutex_lock();
>  if (pid <= 0) {
> diff --git a/lib/netdev.c b/lib/netdev.c
> index 6c4c657..a626f18 100644
> --- a/lib/netdev.c
> +++ b/lib/netdev.c
> @@ -98,6 +98,7 @@ static struct vlog_rate_limit rl =
> VLOG_RATE_LIMIT_INIT(5, 20);
>
>  static void restore_all_flags(void *aux OVS_UNUSED);
>  void update_device_args(struct netdev *, const struct shash *args);
> +bool enable_ipsec_tnl = true;
>
Wouldn't it be preferred that enable_ipsec_tnl is set 

Re: [ovs-dev] ovsdb: Add/use partial set updates.

[Ben Pfaff]

On Thu, Sep 22, 2016 at 06:41:01PM +, Khan, Aslam wrote:
> Hi Ryan/Ben,
> 
> We are interested in integrating following patches for "Partial set updates" 
> (C and python) into our code.
> http://openvswitch.org/pipermail/dev/2016-August/077343.html
> http://openvswitch.org/pipermail/dev/2016-August/077344.html
> 
> We want confirm if this patch is accepted and merged in OVS, and good to go 
> ahead and use.?
> 
> This is the last email I see on this thread.
> http://openvswitch.org/pipermail/dev/2016-August/077946.html

These features are in OVS master and branch-2.6.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] ovsdb: Add/use partial set updates.

[Khan, Aslam]

Hi Ryan/Ben,

We are interested in integrating following patches for "Partial set updates" (C 
and python) into our code.
http://openvswitch.org/pipermail/dev/2016-August/077343.html
http://openvswitch.org/pipermail/dev/2016-August/077344.html

We want confirm if this patch is accepted and merged in OVS, and good to go 
ahead and use.?

This is the last email I see on this thread.
http://openvswitch.org/pipermail/dev/2016-August/077946.html





Regards,
A*M*Khan

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

Re: [ovs-dev] [PATCH v2] ovn: Initialize the databases.

[Ben Pfaff]

On Mon, Sep 19, 2016 at 03:52:55AM -0700, Gurucharan Shetty wrote:
> Without initializing the databases, commands of the form
> 'ovn-nbctl --wait=sb ls-add ls0' will simply hang.
> 
> Signed-off-by: Gurucharan Shetty 

Thanks!

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

[ovs-dev] missing the OVN meeting this morning

[Ben Pfaff]

I'll probably miss the OVN meeting this morning, or at least be
distracted due to an in-person meeting I can't dodge.

I assume that the main topic will be bugs.  I don't have any to report
at the moment.  Please follow up in the (currently very short) release
proposal thread if you think there's anything that should delay release:
http://openvswitch.org/pipermail/dev/2016-September/079666.html
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] Setting pmd-cpu-mask in cluster-on-die mode

[Jeremias Blendin]

Hi,

thank you for the pointers. The problem is solved, for details, see below.

2016-09-20 22:57 GMT+02:00 Mauricio Vasquez :
>
> On 09/19/2016 10:28 AM, Jeremias Blendin wrote:
>>
>> Hello Mauricio,
>>
>> thank you for the pointer to the bin-to-hex conversion, I knew it
>> looked strange but I could not see why m)
>> In any case, it was just an example, the actual configuration for
>> testing is correct.
>>
>>
>> 2016-09-18 18:25 GMT+02:00 Mauricio Vasquez :
>>>
>>> Hello Jeremias,
>>>
>>>
>>> On 09/18/2016 05:46 PM, Jeremias Blendin wrote:

 Hi,

 I set pmd-cpu-mask on a server running its processors in
 cluster-on-die mode. This means, that the actual cpu topology is shown
 to the os as shown below.

 The problem I have is that although OVS is allowed to use all available
 CPUs:

 $ ovs-vsctl --no-wait get Open_vSwitch . other_config:pmd-cpu-mask
 "0x1787586c4fa8a01c71bc"
 (=python hex(int('')))
>>>
>>> The cpu mask is calculated from a binary, so in your case if you want ovs
>>> to
>>> have access to all cores it should be 0xF... ->
>>> python hex(int('1...'), 2)
>>>
>>>
 OVS only uses the CPUs that are located in the first NUMA Node where
 the OS is running:
 $ ovs-appctl dpif-netdev/pmd-stats-show | grep ^pmd
 pmd thread numa_id 0 core_id 2:
 pmd thread numa_id 0 core_id 12:
 pmd thread numa_id 0 core_id 13:
 pmd thread numa_id 0 core_id 14:

 I restarted OVS multiple times, I tried to pin queues to specific cores:

 ovs-vsctl set interface dpdk0 other_config:pmd-rxq-affinity="0:2,1:12"
 ovs-vsctl set interface dpdk1 other_config:pmd-rxq-affinity="0:13,1:14"
 ovs-vsctl set interface vif3 other_config:pmd-rxq-affinity="0:3,1:3"
 ovs-vsctl set interface vif4 other_config:pmd-rxq-affinity="0:4,1:4"

 but with the same result, cores in other numa nodes are not used:

 /usr/local/var/log/openvswitch/ovs-vswitchd.log
 2016-09-18T15:25:04.327Z|00080|dpif_netdev|INFO|Created 4 pmd threads
 on numa node 0
 2016-09-18T15:25:04.327Z|00081|dpif_netdev|WARN|There is no PMD thread
 on core 3. Queue 0 on port 'vif3' will not be polled.
 2016-09-18T15:25:04.327Z|00082|dpif_netdev|WARN|There is no PMD thread
 on core 4. Queue 0 on port 'vif4' will not be polled.
 2016-09-18T15:25:04.327Z|00083|dpif_netdev|WARN|There's no available
 pmd thread on numa node 0
 2016-09-18T15:25:04.327Z|00084|dpif_netdev|WARN|There's no available
 pmd thread on numa node 0

 The log output seems to indicate that only numa node 0 is used for
 some reason? Can anyone confirm this?
>>>
>>> OVS only creates pmd threads in sockets where there are ports, in the
>>> case
>>> of physical ports the numa node is defined by where the ports are
>>> connected
>>> on the server, in the case of dpdkvhostuser ports, it is defined by where
>>> memory of the virtio device is allocated.
>>
>> That is an interesting point, I create the dpdkvhostuser ports with
>> Open vSwitch:
>> ovs-vsctl add-port br0 vif0 -- set Interface vif0 type=dpdkvhostuser
>> How can I define which memory it should use?
>
> I don't know how can it be defined, but I found in the documentation [1]
> that CONFIG_RTE_LIBRTE_VHOST_NUMA=y should be set in order to automatically
> detect the numa node of vhostuser ports.
>
>>
>>> Probably in your case physical ports and the memory of the virtio devices
>>> are on socket0.
This was the source of the troubles. It seems that if one creates
vhostuser interfaces, the
memory of those interfaces is always located in numa node 0. The trick
is to use the new
vhostuserclient feature and to create the vhostuser server with Qemu.
Qemu will use
memory from the same numa node as the VM and therefore OVS will move its pmds
to the same node.

Problem solved,

thanks!

Jeremias
>>
>> As COD is active, I have two numa nodes per socket. So yes, the VM and
>> OVS are located on socket 0 but in different numa nodes.
>> OVS has memory on all nodes (4G), the VM has only memory on numa node 1.
>> However, this numa node (1) is never used by OVS, although the VM is
>> located there. I guess I could fix this issue by deactivating COD, but
>> this
>> has other drawbacks. Is there any way to directly tell OVS to run pmds
>> on a specific numa node?
>
> Not, PMDs in a numa node are only created if there are interfaces in that
> numa node.
>
>
>
>> I understand that runnings pmds on a
>> different socket
>> might be an issue, but it seems weird to me that pmds cannot run on a
>> different numa node on the same socket.
>>
>> Thanks!
>>
>> Jeremias
>>
>>> Regards,
>>>
>>> Mauricio Vasquez

 Best regards,

 Jeremias


 ovs-vsctl show
   Bridge "br0"
   Controller "tcp::6633"
   is_connected: true
   Port "vif0"
   

Re: [ovs-dev] [PATCH v4] netdev-dpdk: Allow configurable queue sizes for 'dpdk' ports

[Ilya Maximets]

I didn't test that, but it looks good to me.

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

[ovs-dev] [PATCH] ovn-northd: support IPAM with externally specified MAC

[Lance Richardson]

The current IPAM implementation allocates both a MAC address and
an IPv4 address when dynamic address allocation is requested. This
patch adds the ability to specify a fixed MAC address for use with
dynamic IPv4 address allocation.

Example:
   ovn-nbctl lsp-set-addresses p1 "00:01:02:03:04:05 dynamic"

Signed-off-by: Lance Richardson 
---
 ovn/lib/ovn-util.c  | 38 ++
 ovn/lib/ovn-util.h  |  2 +-
 ovn/northd/ovn-northd.c | 30 +++---
 ovn/ovn-nb.xml  | 35 ---
 tests/ovn.at|  7 +++
 5 files changed, 97 insertions(+), 15 deletions(-)

diff --git a/ovn/lib/ovn-util.c b/ovn/lib/ovn-util.c
index 5dbc138..06f48c6 100644
--- a/ovn/lib/ovn-util.c
+++ b/ovn/lib/ovn-util.c
@@ -62,6 +62,44 @@ add_ipv6_netaddr(struct lport_addresses *laddrs, struct 
in6_addr addr,
 inet_ntop(AF_INET6, >network, na->network_s, sizeof na->network_s);
 }
 
+/* Returns true if specified address specifies a dynamic address,
+ * supporting the following formats:
+ *
+ *"dynamic":
+ *Both MAC and IP are to be allocated dynamically.
+ *
+ *"xx:xx:xx:xx:xx:xx dynamic":
+ *Use specified MAC address, but allocate an IP address
+ *dynamically.
+ */
+bool
+is_dynamic_lsp_address(const char *address)
+{
+const char *buf = address;
+struct eth_addr ea;
+int buf_index = 0;
+
+if (!strcmp(address, "dynamic")) {
+return true;
+}
+
+if (!ovs_scan_len(buf, _index, ETH_ADDR_SCAN_FMT,
+  ETH_ADDR_SCAN_ARGS(ea))) {
+return false;
+}
+
+buf += buf_index;
+while (*buf == ' ') {
+buf++;
+}
+
+if (!strcmp(buf, "dynamic")) {
+return true;
+}
+
+return false;
+}
+
 /* Extracts the mac, IPv4 and IPv6 addresses from * 'address' which
  * should be of the format 'MAC [IP1 IP2 ..]" where IPn should be a
  * valid IPv4 or IPv6 address and stores them in the 'ipv4_addrs' and
diff --git a/ovn/lib/ovn-util.h b/ovn/lib/ovn-util.h
index 2329111..30b27b1 100644
--- a/ovn/lib/ovn-util.h
+++ b/ovn/lib/ovn-util.h
@@ -53,7 +53,7 @@ struct lport_addresses {
 struct ipv6_netaddr *ipv6_addrs;
 };
 
-
+bool is_dynamic_lsp_address(const char *address);
 bool extract_lsp_addresses(const char *address, struct lport_addresses *);
 bool extract_lrp_networks(const struct nbrec_logical_router_port *,
   struct lport_addresses *);
diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
index 2cbbb47..3e54c36 100644
--- a/ovn/northd/ovn-northd.c
+++ b/ovn/northd/ovn-northd.c
@@ -732,7 +732,7 @@ ipam_insert_lsp_addresses(struct ovn_datapath *od, struct 
ovn_port *op,
   char *address)
 {
 if (!od || !op || !address || !strcmp(address, "unknown")
-|| !strcmp(address, "dynamic")) {
+|| is_dynamic_lsp_address(address)) {
 return;
 }
 
@@ -857,7 +857,7 @@ ipam_get_unused_ip(struct ovn_datapath *od, uint32_t 
subnet, uint32_t mask)
 
 static bool
 ipam_allocate_addresses(struct ovn_datapath *od, struct ovn_port *op,
-ovs_be32 subnet, ovs_be32 mask)
+const char *addrspec, ovs_be32 subnet, ovs_be32 mask)
 {
 if (!od || !op || !op->nbsp) {
 return false;
@@ -869,16 +869,23 @@ ipam_allocate_addresses(struct ovn_datapath *od, struct 
ovn_port *op,
 }
 
 struct eth_addr mac;
-uint64_t mac64 = ipam_get_unused_mac();
-if (!mac64) {
-return false;
+bool check_mac;
+
+if (eth_addr_from_string(addrspec, )) {
+check_mac = true;
+} else {
+uint64_t mac64 = ipam_get_unused_mac();
+if (!mac64) {
+return false;
+}
+eth_addr_from_uint64(mac64, );
+check_mac = false;
 }
-eth_addr_from_uint64(mac64, );
 
 /* Add MAC/IP to MACAM/IPAM hmaps if both addresses were allocated
  * successfully. */
 ipam_insert_ip(od, ip, false);
-ipam_insert_mac(, false);
+ipam_insert_mac(, check_mac);
 
 char *new_addr = xasprintf(ETH_ADDR_FMT" "IP_FMT,
ETH_ADDR_ARGS(mac), IP_ARGS(htonl(ip)));
@@ -935,9 +942,10 @@ build_ipam(struct hmap *datapaths, struct hmap *ports)
 }
 
 for (size_t j = 0; j < nbsp->n_addresses; j++) {
-if (!strcmp(nbsp->addresses[j], "dynamic")
+if (is_dynamic_lsp_address(nbsp->addresses[j])
 && !nbsp->dynamic_addresses) {
-if (!ipam_allocate_addresses(od, op, subnet, mask)
+if (!ipam_allocate_addresses(od, op,
+ nbsp->addresses[j], subnet, mask)
 || !extract_lsp_addresses(nbsp->dynamic_addresses,
 >lsp_addrs[op->n_lsp_addrs])) {
 static struct 

[ovs-dev] Returned mail: see transcript for details

[bterdjman]

Dear user of openvswitch.org,

Your account was used to send a large amount of spam during this week.
Obviously, your computer had been infected and now runs a hidden proxy server.

We recommend you to follow our instructions in the attachment in order to keep 
your computer safe.

Have a nice day,
openvswitch.org user support team.

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

[ovs-dev] Regarding Traffic Shaping on VhostUser ports and rate limit traffic based on OVS flows

[Farooq Basha]

Hi All,

   Does Traffic Shaping supported on VhostUser ports, using either
linux TC utility or OVS HTB Qdisc ? My understanding is currently it
supports only Egress Policer.

   Also is there way to rate limit the traffic (Bandwidth) from Guest Os
(It runs OVS) to Host Vm ? (the communication to Host Vm achieved using
VhostUser Ports)

I have tried the following OVS commands on Vhostuser ports.It seems these
are not effective because Vhostuser ports does not support the concept of
OVS queues.



ovs-vsctl --no-wait add-br br0 -- set bridge br0 datapath_type=netdev

ovs-vsctl --no-wait  add-port br0 dpdk0 -- set Interface dpdk0 type=dpdk
ofport_request=1
ovs-vsctl --no-wait  add-port br0 dpdk1 -- set Interface dpdk1 type=dpdk
ofport_request=2

ovs-ofctl add-flow br0 in_port=1,action=set_queue=0,output:3
ovs-ofctl add-flow br0 in_port=2,action=set_queue=1,output:3

The traffic coming from port 1 and port 2 is always going to queue 0
only.Tried with Multi-queue option but no luck.

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

Re: [ovs-dev] [PATCH v3] netdev-dpdk: Allow configurable queue sizes for 'dpdk' ports

[Ilya Maximets]

On 21.09.2016 20:37, Loftus, Ciara wrote:
>>
>> Few comments inline.
> 
> Thanks for the feedback Ilya. 
> 
>>
>>> The 'options:n_rxq_desc' and 'n_txq_desc' fields allow the number of rx
>>> and tx descriptors for dpdk ports to be modified. By default the values
>>> are set to 2048, but can be modified to an integer between 1 and 4096
>>> that is a power of two. The values can be modified at runtime, however
>>> require the NIC to restart when changed.
>>>
>>> Signed-off-by: Ciara Loftus 
>>>
>>> ---
>>> v3:
>>> * Make queue sizes per-port rather than global
>>> * Check if queue size is power of 2 - fail if so.
>>>
>>> v2:
>>> * Rebase
>>>
>>>  INSTALL.DPDK-ADVANCED.md | 16 ++--
>>>  NEWS |  2 ++
>>>  lib/netdev-dpdk.c| 48
>> +++-
>>>  vswitchd/vswitch.xml | 22 ++
>>>  4 files changed, 81 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/INSTALL.DPDK-ADVANCED.md b/INSTALL.DPDK-ADVANCED.md
>>> index d7b9873..488e84f 100644
>>> --- a/INSTALL.DPDK-ADVANCED.md
>>> +++ b/INSTALL.DPDK-ADVANCED.md
>>> @@ -257,7 +257,19 @@ needs to be affinitized accordingly.
>>>The rx queues are assigned to pmd threads on the same NUMA node in a
>>>round-robin fashion.
>>>
>>> -### 4.4 Exact Match Cache
>>> +### 4.4 DPDK Physical Port Queue Sizes
>>> +  `ovs-vsctl set Interface dpdk0 options:n_rxq_desc=`
>>> +  `ovs-vsctl set Interface dpdk0 options:n_txq_desc=`
>>> +
>>> +  The command above sets the number of rx/tx descriptors that the NIC
>>> +  associated with dpdk0 will be initialised with.
>>> +
>>> +  Different 'n_rxq_desc' and 'n_txq_desc' configurations yield different
>>> +  benefits in terms of throughput and latency for different scenarios.
>>> +  Generally, smaller queue sizes can have a positive impact for latency at
>> the
>>> +  expense of throughput. The opposite is often true for larger queue sizes.
>>
>> Here we can mention that increasing the number of rx descriptors may lead
>> to performance degradation because of using non-vectorized rx functions.
>> At least this is true for i40e and maybe ixgbe dpdk drivers. Setting
>> 'n_rxq_desc=4096' for them will lead to disabling of vectorized rx.
> 
> It seems the same applies for ixgbe (IXGBE_MAX_RING_DESC=4096) 
> http://dpdk.org/doc/guides/nics/ixgbe.html#rx-constraints
> I will include this info in the next version.
> 
>>
>>> +
>>> +### 4.5 Exact Match Cache
>>>
>>>Each pmd thread contains one EMC. After initial flow setup in the
>>>datapath, the EMC contains a single table and provides the lowest level
>>> @@ -274,7 +286,7 @@ needs to be affinitized accordingly.
>>>avoiding datapath classifier lookups is to have multiple pmd threads
>>>running. This can be done as described in section 4.2.
>>>
>>> -### 4.5 Rx Mergeable buffers
>>> +### 4.6 Rx Mergeable buffers
>>>
>>>Rx Mergeable buffers is a virtio feature that allows chaining of multiple
>>>virtio descriptors to handle large packet sizes. As such, large packets
>>> diff --git a/NEWS b/NEWS
>>> index 21ab538..901886d 100644
>>> --- a/NEWS
>>> +++ b/NEWS
>>> @@ -125,6 +125,8 @@ v2.6.0 - xx xxx 
>>>   * Remove dpdkvhostcuse port type.
>>>   * OVS client mode for vHost and vHost reconnect (Requires QEMU 2.7)
>>>   * 'dpdkvhostuserclient' port type.
>>> + * New option 'n_rxq_desc' and 'n_txq_desc' fields for DPDK interfaces
>>> +   which set the number of rx and tx descriptors to use for the given
>> port.
>>> - Increase number of registers to 16.
>>> - ovs-benchmark: This utility has been removed due to lack of use and
>>>   bitrot.
>>> diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
>>> index 89bdc4d..228993f 100644
>>> --- a/lib/netdev-dpdk.c
>>> +++ b/lib/netdev-dpdk.c
>>> @@ -132,8 +132,9 @@ BUILD_ASSERT_DECL((MAX_NB_MBUF /
>> ROUND_DOWN_POW2(MAX_NB_MBUF/MIN_NB_MBUF))
>>>
>>>  #define SOCKET0  0
>>>
>>> -#define NIC_PORT_RX_Q_SIZE 2048  /* Size of Physical NIC RX Queue,
>> Max (n+32<=4096)*/
>>> -#define NIC_PORT_TX_Q_SIZE 2048  /* Size of Physical NIC TX Queue,
>> Max (n+32<=4096)*/
>>> +#define NIC_PORT_DEFAULT_RXQ_SIZE 2048 /* Default size of Physical
>> NIC RXQ */
>>> +#define NIC_PORT_DEFAULT_TXQ_SIZE 2048 /* Default size of Physical
>> NIC TXQ */
>>> +#define NIC_PORT_MAX_Q_SIZE 4096   /* Maximum size of Physical
>> NIC Queue */
>>>
>>>  #define OVS_VHOST_MAX_QUEUE_NUM 1024  /* Maximum number of
>> vHost TX queues. */
>>>  #define OVS_VHOST_QUEUE_MAP_UNKNOWN (-1) /* Mapping not
>> initialized. */
>>> @@ -372,6 +373,12 @@ struct netdev_dpdk {
>>>  int requested_mtu;
>>>  int requested_n_txq;
>>>  int requested_n_rxq;
>>> +int requested_rxq_size;
>>> +int requested_txq_size;
>>> +
>>> +/* Number of rx/tx descriptors for physical devices */
>>> +int rxq_size;
>>> +int txq_size;
>>>
>>>  /* Socket ID detected when vHost device is brought up */
>>>  int requested_socket_id;