Re: [ovs-dev] [PATCH] util: Better document ALIGNED_CAST.

2018-09-17 Thread Ben Pfaff 
On Mon, Sep 17, 2018 at 10:12:09PM -0700, Han Zhou wrote:
> On Mon, Sep 17, 2018 at 10:01 PM Ben Pfaff  wrote:
> >
> > CC: Han Zhou 
> > Signed-off-by: Ben Pfaff 
> > ---
> >  include/openvswitch/util.h | 10 --
> >  1 file changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/openvswitch/util.h b/include/openvswitch/util.h
> > index b4d49ee21804..9189e6480b1c 100644
> > --- a/include/openvswitch/util.h
> > +++ b/include/openvswitch/util.h
> > @@ -273,8 +273,14 @@ is_pow2(uintmax_t x)
> >  #define BITMAP_ULONG_BITS (sizeof(unsigned long) * CHAR_BIT)
> >  #define BITMAP_N_LONGS(N_BITS) DIV_ROUND_UP(N_BITS, BITMAP_ULONG_BITS)
> >
> > -/* Given ATTR, and TYPE, cast the ATTR to TYPE by first casting ATTR to
> > - * (void *). This is to suppress the alignment warning issued by clang.
> */
> > +/* Given ATTR, and TYPE, cast the ATTR to TYPE by first casting ATTR to
> (void
> > + * *).  This suppresses the alignment warning issued by Clang and newer
> > + * versions of GCC when a pointer is cast to a type with a stricter
> alignment.
> > + *
> > + * Add ALIGNED_CAST only if you are sure that the cast is actually
> correct,
> > + * that is, that the pointer is actually properly aligned for the
> stricter
> > + * type.  On RISC architectures, dereferencing a misaligned pointer can
> cause a
> > + * segfault, so it is important to be aware of correct alignment. */
> >  #define ALIGNED_CAST(TYPE, ATTR) ((TYPE) (void *) (ATTR))
> >
> >  #ifdef __cplusplus
> > --
> > 2.16.1
> >
> 
> Thanks Ben.
> Acked-by: Han Zhou 

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

Re: [ovs-dev] [PATCH] util: Better document ALIGNED_CAST.

2018-09-17 Thread Han Zhou 
On Mon, Sep 17, 2018 at 10:01 PM Ben Pfaff  wrote:
>
> CC: Han Zhou 
> Signed-off-by: Ben Pfaff 
> ---
>  include/openvswitch/util.h | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/include/openvswitch/util.h b/include/openvswitch/util.h
> index b4d49ee21804..9189e6480b1c 100644
> --- a/include/openvswitch/util.h
> +++ b/include/openvswitch/util.h
> @@ -273,8 +273,14 @@ is_pow2(uintmax_t x)
>  #define BITMAP_ULONG_BITS (sizeof(unsigned long) * CHAR_BIT)
>  #define BITMAP_N_LONGS(N_BITS) DIV_ROUND_UP(N_BITS, BITMAP_ULONG_BITS)
>
> -/* Given ATTR, and TYPE, cast the ATTR to TYPE by first casting ATTR to
> - * (void *). This is to suppress the alignment warning issued by clang.
*/
> +/* Given ATTR, and TYPE, cast the ATTR to TYPE by first casting ATTR to
(void
> + * *).  This suppresses the alignment warning issued by Clang and newer
> + * versions of GCC when a pointer is cast to a type with a stricter
alignment.
> + *
> + * Add ALIGNED_CAST only if you are sure that the cast is actually
correct,
> + * that is, that the pointer is actually properly aligned for the
stricter
> + * type.  On RISC architectures, dereferencing a misaligned pointer can
cause a
> + * segfault, so it is important to be aware of correct alignment. */
>  #define ALIGNED_CAST(TYPE, ATTR) ((TYPE) (void *) (ATTR))
>
>  #ifdef __cplusplus
> --
> 2.16.1
>

Thanks Ben.
Acked-by: Han Zhou 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] Info - 18.09.2018

2018-09-17 Thread Erik Co. & GmbH 
Hallo,
Wir vergeben Kredite an Privatpersonen und Unternehmen. Der Zinssatz wird 3% 
pro Jahr betragen. Wir haben Investoren, die daran interessiert sind, Projekte 
mit gro�em Volumen zu finanzieren, und wir geben Darlehen ohne Vorabgeb�hr aus. 
Kontaktieren Sie mich mit den folgenden Informationen, damit wir Ihnen die 
Bedingungen des Darlehens zur Verf�gung stellen k�nnen.
Vollst�ndiger Name:
Darlehensbetrag erforderlich ::
Amortisationsdauer (1 - 30 Jahre):
Handynummer:
 Antworte mir f�r weitere Informationen.
..
..
 Hello, 
We give out loans to individuals and companies. The interest rate will be 3% 
annually. We have investors who are interested in financing projects of large 
volume and we give out loan without any upfront fee.  Contact me with the 
following information so we can provide you with the terms and conditions of 
the loan.
Full name:
Loan amount required::
Payback duration (1  13 30 Years):
Mobile phone number:
 Reply me for more information.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] ovsdb-idlc: Use ALIGNED_CAST to avoid spurious warnings for index rows.

2018-09-17 Thread Ben Pfaff 
On Thu, Sep 13, 2018 at 04:26:52PM -0700, Han Zhou wrote:
> On Thu, Sep 13, 2018 at 2:54 PM Ben Pfaff  wrote:
> >
> > On Wed, Sep 12, 2018 at 03:47:05PM -0700, Han Zhou wrote:
> > > On Wed, Sep 12, 2018 at 2:18 PM Ben Pfaff  wrote:
> > > >
> > > > On Tue, Sep 11, 2018 at 11:32:25PM -0700, Han Zhou wrote:
> > > > > On Mon, Sep 10, 2018 at 1:01 PM Ben Pfaff  wrote:
> > > > > >
> > > > > > The *_index_init_row() function casts a generic ovsdb_idl_row
> pointer
> > > to
> > > > > > a specific type of row pointer.  This can cause an increase in
> > > required
> > > > > > alignment with some kinds of data on some architectures.  GCC
> > > complains,
> > > > > > e.g.:
> > > > > >
> > > > > > lib/vswitch-idl.c: In function
> > > > > 'ovsrec_flow_sample_collector_set_index_init_row'
> > > > > > lib/vswitch-idl.c:9277:12: warning: cast increases required
> > > alignment
> > > > > of target
> > > > >
> > > > > Hi Ben, could you share on which compiler/version you see this
> warning?
> > > >
> > > > It's on non-x86 architectures, e.g. mipsel.  I don't think it's
> > > > particularly sensitive to GCC version but this is with version 8.2.0:
> > > >
> > >
> https://buildd.debian.org/status/fetch.php?pkg=openvswitch=mipsel=2.10.0%2B2018.08.28%2Bgit.8ca7c82b7d%2Bds1-3=1536673373=0
> > >
> > > I see, thanks. But I wonder why it complains only for this particular
> type
> > > cast - there are many type casts in other places.
> >
> > Without actually looking carefully, I think it's because struct
> > ovsdb_idl_row doesn't have any 64-bit members but the row type in
> > question does ("int64_t id;").  That makes it look to the compiler like
> > we're doing something questionable.
> >
> > > Do you have a hint on when should the ALIGNED_CAST be used, or do we
> > > have to rely on the compiler warnings - and it is not easy to get
> > > since most developers doesn't compile for other archs.
> >
> > The sole value of ALIGNED_CAST is suppressing compiler warnings, in the
> > case where the compiler's warning is uninformed.  Thus, there's no good
> > reason for developers to add these proactively anyway.
> 
> So it seems only in rare situation will this happen, and it is not a too
> bad idea to rely on upstream CI system to find out.
> 
> BTW, the questions are only about how to avoid this in the future when we
> submitting code. For the patch itself:
> 
> Acked-by: hzh...@ebay.com

Thanks, I applied this to master and branch-2.10, and sent out a patch
to better document ALIGNED_CAST.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] util: Better document ALIGNED_CAST.

2018-09-17 Thread Ben Pfaff 
CC: Han Zhou 
Signed-off-by: Ben Pfaff 
---
 include/openvswitch/util.h | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/include/openvswitch/util.h b/include/openvswitch/util.h
index b4d49ee21804..9189e6480b1c 100644
--- a/include/openvswitch/util.h
+++ b/include/openvswitch/util.h
@@ -273,8 +273,14 @@ is_pow2(uintmax_t x)
 #define BITMAP_ULONG_BITS (sizeof(unsigned long) * CHAR_BIT)
 #define BITMAP_N_LONGS(N_BITS) DIV_ROUND_UP(N_BITS, BITMAP_ULONG_BITS)
 
-/* Given ATTR, and TYPE, cast the ATTR to TYPE by first casting ATTR to
- * (void *). This is to suppress the alignment warning issued by clang. */
+/* Given ATTR, and TYPE, cast the ATTR to TYPE by first casting ATTR to (void
+ * *).  This suppresses the alignment warning issued by Clang and newer
+ * versions of GCC when a pointer is cast to a type with a stricter alignment.
+ *
+ * Add ALIGNED_CAST only if you are sure that the cast is actually correct,
+ * that is, that the pointer is actually properly aligned for the stricter
+ * type.  On RISC architectures, dereferencing a misaligned pointer can cause a
+ * segfault, so it is important to be aware of correct alignment. */
 #define ALIGNED_CAST(TYPE, ATTR) ((TYPE) (void *) (ATTR))
 
 #ifdef __cplusplus
-- 
2.16.1

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

Re: [ovs-dev] [PATCH] Update tutorial for newer versions of Faucet and Open vSwitch.

2018-09-17 Thread Ben Pfaff 
On Wed, Sep 12, 2018 at 11:53:28AM +1200, Brad Cowie wrote:
> Newer versions of Faucet use a dynamic OpenFlow pipeline based on what
> features are enabled in the configuration file. Update log output, flow
> table dumps and explanations to be consistent with newer Faucet versions.
> 
> Remove mentions of bugs that we have since fixed in Faucet since the
> tutorial was originally written.
> 
> Adds documentation on changes to Open vSwitch commands to recommend
> using a version that is compatible with the features of the tutorial.
> 
> Reported-by: Matthias Ableidinger 
> Reported-at: 
> https://mail.openvswitch.org/pipermail/ovs-discuss/2018-August/047180.html
> Signed-off-by: Brad Cowie 

This is really nice.  Thank you.

To avoid causing even more confusion, I'm going to hold off on applying
it until the series that it relies on has been applied.  I hope that is
soon.

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

Re: [ovs-dev] [PATCH v3] rhel: Ship ovs shared libraries, fedora

2018-09-17 Thread Ben Pfaff 
On Wed, Sep 12, 2018 at 07:55:57PM -0300, Flavio Leitner wrote:
> On Wed, Sep 12, 2018 at 12:43:51PM -0700, Martin Xu wrote:
> > This patch extends 4886d4d2495b (debian, rhel: Ship ovs shared libraries
> > and header files) to fedora, by packaging the shared libraries in
> > openvswitch and openvswitch-dvel RPM. These files are always packaged in
> > the RPMs built with rhel6 spec file.
> > 
> > VMware-BZ: #2036847
> > 
> > Signed-off-by: Martin Xu 
> > CC: Flavio Leitner 
> > ---
> 
> Acked-by: Flavio Leitner 

Thanks Martin and Flavio.

I applied this to master and branch-2.10.  It looks like the cited base
patch was also in 2.9 and 2.8 but the patch didn't apply cleanly so I
skipped those backports.  If you do want a backport that far, please
send a patch with the conflict resolved.

Thanks,

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

Re: [ovs-dev] [PATCH] ofproto-dpif-xlate: Fix translation of groups with no buckets.

2018-09-17 Thread Ben Pfaff 
On Thu, Sep 13, 2018 at 04:58:08PM +0200, Eelco Chaudron wrote:
> 
> 
> On 2 Sep 2018, at 18:30, Ben Pfaff wrote:
> 
> >A group can have no buckets, in which case ovs_list_back() assert-fails.
> >This fixes the problem.
> >
> >Found by OFTest.
> >
> >Fixes: a04e58881e25 ("ofproto-dpif-xlate: Simplify translation for
> >groups.")
> >Signed-off-by: Ben Pfaff 
> 
> The change looks fine to me.
> 
> In addition the issue was found in one of our regressions, and this patch
> solved it.
> https://bugzilla.redhat.com/show_bug.cgi?id=1626488
> 
> Acked-by: Eelco Chaudron 

Thanks.  Applied to master and branch-2.10.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] dpif-netdev: Fix "execute" packet length check.

2018-09-17 Thread Ben Pfaff 
On Mon, Sep 17, 2018 at 04:23:09PM +0800, wangyunjian wrote:
> From: Yunjian Wang 
> 
> The length check is wrong for immediate arguments to "execute" packet.
> The ethernet header length should be considered.
> 
> Signed-off-by: Yunjian Wang 
> ---
>  lib/dpif-netdev.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
> index 9fb82cc..6522f27 100644
> --- a/lib/dpif-netdev.c
> +++ b/lib/dpif-netdev.c
> @@ -3632,9 +3632,11 @@ dpif_netdev_execute(struct dpif *dpif, struct 
> dpif_execute *execute)
>  struct dp_netdev *dp = get_dp_netdev(dpif);
>  struct dp_netdev_pmd_thread *pmd;
>  struct dp_packet_batch pp;
> +int n_vlan = flow_count_vlan_headers(execute->flow);
>  
>  if (dp_packet_size(execute->packet) < ETH_HEADER_LEN ||
> -dp_packet_size(execute->packet) > UINT16_MAX) {
> +dp_packet_size(execute->packet) > UINT16_MAX +
> +ETH_HEADER_LEN + VLAN_HEADER_LEN * n_vlan) {
>  return EINVAL;
>  }

I was taking the 64-kB limit as a limit on the size of a buffer.  This
interprets it as a MTU limit ignoring L2 headers.  Can you explain the
importance and significance of the change?

Before I read the patch in detail, I expected it to change the "<
ETH_HEADER_LEN" to something more like "< ETH_HEADER_LEN + 4 * n_vlan".
I'm still a little surprised it doesn't do that.
___
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

2018-09-17 Thread Ben Pfaff 
On Fri, Sep 14, 2018 at 01:12:17PM +0100, Ian Stokes wrote:
> Hi Ben,
> 
> The following changes since commit 949758946767ff79b4c3eb5eca755c6cf21643e3:
> 
>   ovs-save: Don't always include the default flow during restore (2018-09-13
> 05:19:54 -0700)
> 
> are available in the git repository at:
> 
>   https://github.com/istokes/ovs dpdk_merge
> 
> for you to fetch changes up to e77c97b9d693a96349af68c37c561252d8d7dcb8:
> 
>   dpif-netdev: Add round-robin based rxq to pmd assignment. (2018-09-14
> 11:45:05 +0100)

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

Re: [ovs-dev] [PATCH] ovn: Add DHCP support for option 252.

2018-09-17 Thread Ben Pfaff 
Looks low risk, applies and builds cleanly, so I applied it to
branch-2.10.

On Mon, Sep 17, 2018 at 04:01:17PM -0400, Mark Michelson wrote:
> Hi folks,
> 
> Any chance that this could be a candidate for a 2.10 backport?
> 
> On 08/20/2018 04:14 PM, Mark Michelson wrote:
> >This adds DHCP support for web proxy auto detection.
> >
> >Signed-off-by: Mark Michelson 
> >---
> >  ovn/lib/ovn-l7.h| 2 ++
> >  ovn/northd/ovn-northd.c | 3 ++-
> >  ovn/ovn-nb.xml  | 8 
> >  tests/ovn.at| 6 +++---
> >  tests/test-ovn.c| 1 +
> >  5 files changed, 16 insertions(+), 4 deletions(-)
> >
> >diff --git a/ovn/lib/ovn-l7.h b/ovn/lib/ovn-l7.h
> >index b8d6683bc..817e9f002 100644
> >--- a/ovn/lib/ovn-l7.h
> >+++ b/ovn/lib/ovn-l7.h
> >@@ -70,6 +70,8 @@ struct gen_opts_map {
> >  #define DHCP_OPT_T1 DHCP_OPTION("T1", 58, "uint32")
> >  #define DHCP_OPT_T2 DHCP_OPTION("T2", 59, "uint32")
> >+#define DHCP_OPT_WPAD DHCP_OPTION("wpad", 252, "str")
> >+
> >  static inline uint32_t
> >  gen_opt_hash(char *opt_name)
> >  {
> >diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
> >index ba86bf559..a1cfd4bdf 100644
> >--- a/ovn/northd/ovn-northd.c
> >+++ b/ovn/northd/ovn-northd.c
> >@@ -7186,7 +7186,8 @@ static struct gen_opts_map supported_dhcp_opts[] = {
> >  DHCP_OPT_MTU,
> >  DHCP_OPT_LEASE_TIME,
> >  DHCP_OPT_T1,
> >-DHCP_OPT_T2
> >+DHCP_OPT_T2,
> >+DHCP_OPT_WPAD,
> >  };
> >  static struct gen_opts_map supported_dhcpv6_opts[] = {
> >diff --git a/ovn/ovn-nb.xml b/ovn/ovn-nb.xml
> >index bc60a25dd..441a2deae 100644
> >--- a/ovn/ovn-nb.xml
> >+++ b/ovn/ovn-nb.xml
> >@@ -1991,6 +1991,14 @@
> >  Microsoft Windows DHCPv4 clients.
> >
> >  
> >+
> >+
> >+  
> >+The DHCPv4 option code for this option is 252. This option is 
> >used
> >+as part of web proxy auto discovery to provide a URL for a web
> >+proxy.
> >+  
> >+
> >
> >
> >diff --git a/tests/ovn.at b/tests/ovn.at
> >index 70c6c50b3..6165d69c0 100644
> >--- a/tests/ovn.at
> >+++ b/tests/ovn.at
> >@@ -1100,9 +1100,9 @@ put_arp(inport, arp.spa, arp.sha);
> >  # put_dhcp_opts
> >  reg1[0] = put_dhcp_opts(offerip = 1.2.3.4, router = 10.0.0.1);
> >  encodes as 
> > controller(userdata=00.00.00.02.00.00.00.00.00.01.de.10.00.00.00.40.01.02.03.04.03.04.0a.00.00.01,pause)
> >-reg2[5] = 
> >put_dhcp_opts(offerip=10.0.0.4,router=10.0.0.1,netmask=255.255.254.0,mtu=1400,domain="ovn.org");
> >-formats as reg2[5] = put_dhcp_opts(offerip = 10.0.0.4, router = 
> >10.0.0.1, netmask = 255.255.254.0, mtu = 1400, domain = "ovn.org");
> >-encodes as 
> >controller(userdata=00.00.00.02.00.00.00.00.00.01.de.10.00.00.00.25.0a.00.00.04.03.04.0a.00.00.01.01.04.ff.ff.fe.00.1a.02.05.78.0f.07.6f.76.6e.2e.6f.72.67,pause)
> >+reg2[5] = 
> >put_dhcp_opts(offerip=10.0.0.4,router=10.0.0.1,netmask=255.255.254.0,mtu=1400,domain="ovn.org",wpad="https://example.org;);
> >+formats as reg2[5] = put_dhcp_opts(offerip = 10.0.0.4, router = 
> >10.0.0.1, netmask = 255.255.254.0, mtu = 1400, domain = "ovn.org", wpad = 
> >"https://example.org;);
> >+encodes as 
> >controller(userdata=00.00.00.02.00.00.00.00.00.01.de.10.00.00.00.25.0a.00.00.04.03.04.0a.00.00.01.01.04.ff.ff.fe.00.1a.02.05.78.0f.07.6f.76.6e.2e.6f.72.67.fc.13.68.74.74.70.73.3a.2f.2f.65.78.61.6d.70.6c.65.2e.6f.72.67,pause)
> >  reg0[15] = 
> > put_dhcp_opts(offerip=10.0.0.4,router=10.0.0.1,netmask=255.255.255.0,mtu=1400,ip_forward_enable=1,default_ttl=121,dns_server={8.8.8.8,7.7.7.7},classless_static_route={30.0.0.0/24,10.0.0.4,40.0.0.0/16,10.0.0.6,0.0.0.0/0,10.0.0.1},ethernet_encap=1,router_discovery=0);
> >  formats as reg0[15] = put_dhcp_opts(offerip = 10.0.0.4, router = 
> > 10.0.0.1, netmask = 255.255.255.0, mtu = 1400, ip_forward_enable = 1, 
> > default_ttl = 121, dns_server = {8.8.8.8, 7.7.7.7}, classless_static_route 
> > = {30.0.0.0/24, 10.0.0.4, 40.0.0.0/16, 10.0.0.6, 0.0.0.0/0, 10.0.0.1}, 
> > ethernet_encap = 1, router_discovery = 0);
> >  encodes as 
> > controller(userdata=00.00.00.02.00.00.00.00.00.01.de.10.00.00.00.6f.0a.00.00.04.03.04.0a.00.00.01.01.04.ff.ff.ff.00.1a.02.05.78.13.01.01.17.01.79.06.08.08.08.08.08.07.07.07.07.79.14.18.1e.00.00.0a.00.00.04.10.28.00.0a.00.00.06.00.0a.00.00.01.24.01.01.1f.01.00,pause)
> >diff --git a/tests/test-ovn.c b/tests/test-ovn.c
> >index d4a5d599e..5e6d1c3b4 100644
> >--- a/tests/test-ovn.c
> >+++ b/tests/test-ovn.c
> >@@ -182,6 +182,7 @@ create_gen_opts(struct hmap *dhcp_opts, struct hmap 
> >*dhcpv6_opts,
> >  dhcp_opt_add(dhcp_opts, "tcp_ttl", 37, "uint8");
> >  dhcp_opt_add(dhcp_opts, "mtu", 26, "uint16");
> >  dhcp_opt_add(dhcp_opts, "lease_time",  51, "uint32");
> >+dhcp_opt_add(dhcp_opts, "wpad", 252, "str");
> >  /* DHCPv6 options. */
> >  hmap_init(dhcpv6_opts);
> >
> 
> ___
> dev mailing list
> d...@openvswitch.org
>

Re: [ovs-dev] [patch v2] conntrack: Add rcu support.

2018-09-17 Thread Ben Pfaff 
On Mon, Sep 17, 2018 at 02:05:49PM -0700, Darrell Ball wrote:
> Add in rcu support for conntrack. At the same time, the array of
> hmaps is replaced by a cmap.  Using a single map also simplifies
> the handling of nat and allows the removal of the nat_conn map.
> There is still some cleanup to do and a few things to check. I'll
> probably split out into several patches later
> 
> Signed-off-by: Darrell Ball 
> ---
> 
> v1->v2: Some synchronization changes; new expiry lists lock.
> Fix the 4 Travis builds that were failing.

Would you mind dropping the ct-specific locking constructs too?  They do
not add any additional abstraction and they will make it harder to debug
because the source file name and line number recorded in the ovs_mutex
will always point to the ct-specific function, not to their callers.

I haven't fully reviewed this (not sure I'm the right person).

Thanks,

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

Re: [ovs-dev] [PATCH net-next] net: fix return type of ndo_start_xmit function

2018-09-17 Thread YueHaibing 



On 2018/9/17 23:09, David Miller wrote:
> 
> Please don't do this.
> 
> The hard part of fixing this is not what you are doing, changing the
> return type.
> 
> The hard part is fixing each and every function to actually return
> values which are members of the netdev_tx_t enumeration.
> 
> Please fix each and every function properly.

Ok, I will do it, thank you for review.

> 
> Thank you.
> 
> .
> 

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

Re: [ovs-dev] [PATCH v4] gre: Rename fallback devices to avoid udev's interference

2018-09-17 Thread Gregory Rose 

On 9/17/2018 4:34 PM, Yifeng Sun wrote:

Hi Greg,

Your guess is correct. The FB device is only created once.
Even if more tunnels are added, there are still only one FB device.
Yes, three digits should be enough in our case.

Thanks,
Yifeng


Excellent!  Thanks for confirming.  I think if you just remove that 
section of the patch and resubmit

it should be fine.

I know you've done a lot of extra work testing this but I prefer staying 
in synch with upstream code

as much as possible.  It makes life easier down the road.

Thanks again for your hard work,

- Greg




On Mon, Sep 17, 2018 at 2:28 PM Gregory Rose > wrote:


On 9/17/2018 1:40 PM, Yifeng Sun wrote:

Hi Greg,

I checked that the 'else' part in the above patch is actually
executed. So it should be necessary to keep them.

Thanks,
Yifeng


That's interesting but I expect that it is only executed once
during creation of the FB device.  Does it continue
to get invoked if you keep adding new tunnels?  Can you try adding
new ip gre tunnels and see if we would ever actually get to 100 of
them? Enough to create a 3 digit trailing number?

The reason I ask is that the kernel code is checking IFNAMSIZ - 3
and I think that check is sufficient because
only the FB devices, of which there should only be one, will cause
that block to be executed.  I'm not sure
though!  If you could try that out I'd appreciate it but I do
believe that for all non-FB devices cases the name
of the tunnel will be in parms->name.  Confirming that would tell
us whether you need to make a patch
for upstream or not.

Thanks Yifeng!

- Greg



On Mon, Sep 17, 2018 at 9:51 AM Yifeng Sun
mailto:pkusunyif...@gmail.com>> wrote:

Hi Greg,

Sure, thanks for the review. I will work on it.

Yifeng

On Mon, Sep 17, 2018 at 8:49 AM Gregory Rose
mailto:gvrose8...@gmail.com>> wrote:

On 9/15/2018 9:24 PM, Yifeng Sun wrote:
> On certain kernel versions, when openvswitch kernel
module creates
> a gre0 interface, the kernel’s gre module will jump out
and compete
> to control the gre0 interface. This will cause the
failure of
> openvswitch kernel module loading.
>
> This fix renames fallback devices by adding a prefix
"ovs-".
>
> Signed-off-by: Yifeng Sun mailto:pkusunyif...@gmail.com>>
> VMware Issue: #2162866
> ---
> Please backport this patch to upstream OVS down to 2.9,
thanks.
>
> v1->v2: Added sanity check for device names, thanks Justin.
> v2->v3: Fix an indent error.
> v3->v4: Fix by code review, also fix a potenial bug.
>
>   datapath/linux/compat/ip6_gre.c    | 5 +++--
>   datapath/linux/compat/ip6_tunnel.c | 6 +++---
>   datapath/linux/compat/ip_gre.c     | 2 +-
>   datapath/linux/compat/ip_tunnel.c  | 7 +++
>   4 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/datapath/linux/compat/ip6_gre.c
b/datapath/linux/compat/ip6_gre.c
> index 00dbefc9b099..182785273c6f 100644
> --- a/datapath/linux/compat/ip6_gre.c
> +++ b/datapath/linux/compat/ip6_gre.c
> @@ -377,7 +377,7 @@ static struct ip6_tnl
*ip6gre_tunnel_locate(struct net *net,
>       if (parms->name[0])
>               strlcpy(name, parms->name, IFNAMSIZ);
>       else
> -             strcpy(name, "ip6gre%d");
> +             strlcpy(name, "ovs-ip6gre%d", IFNAMSIZ);
>
>       dev = alloc_netdev(sizeof(*t), name,
NET_NAME_UNKNOWN,
> ip6gre_tunnel_setup);
> @@ -1712,7 +1712,8 @@ static int __net_init
ip6gre_init_net(struct net *net)
>       struct ip6gre_net *ign = net_generic(net,
ip6gre_net_id);
>       int err;
>
> -     ign->fb_tunnel_dev = alloc_netdev(sizeof(struct
ip6_tnl), "ip6gre0",
> +     ign->fb_tunnel_dev = alloc_netdev(sizeof(struct
ip6_tnl),
> +  "ovs-ip6gre0",
>  NET_NAME_UNKNOWN,
>  ip6gre_tunnel_setup);
>       if (!ign->fb_tunnel_dev) {
> diff --git a/datapath/linux/compat/ip6_tunnel.c
b/datapath/linux/compat/ip6_tunnel.c
> index 56fd8b4dd342..9f4bae7dd3d1 100644
> --- a/datapath/linux/compat/ip6_tunnel.c
> +++ b/datapath/linux/compat/ip6_tunnel.c
> @@ -355,7 +355,7 @@ static struct ip6_tnl
*ip6_tnl_create(struct net *net, struct __ip6_tnl_parm *p)
>       if

Re: [ovs-dev] [PATCH v4] gre: Rename fallback devices to avoid udev's interference

2018-09-17 Thread Yifeng Sun 
Hi Greg,

Your guess is correct. The FB device is only created once.
Even if more tunnels are added, there are still only one FB device.
Yes, three digits should be enough in our case.

Thanks,
Yifeng


On Mon, Sep 17, 2018 at 2:28 PM Gregory Rose  wrote:

> On 9/17/2018 1:40 PM, Yifeng Sun wrote:
>
> Hi Greg,
>
> I checked that the 'else' part in the above patch is actually
> executed. So it should be necessary to keep them.
>
> Thanks,
> Yifeng
>
>
> That's interesting but I expect that it is only executed once during
> creation of the FB device.  Does it continue
> to get invoked if you keep adding new tunnels?  Can you try adding new ip
> gre tunnels and see if we would ever actually get to 100 of them? Enough to
> create a 3 digit trailing number?
>
> The reason I ask is that the kernel code is checking IFNAMSIZ - 3 and I
> think that check is sufficient because
> only the FB devices, of which there should only be one, will cause that
> block to be executed.  I'm not sure
> though!  If you could try that out I'd appreciate it but I do believe that
> for all non-FB devices cases the name
> of the tunnel will be in parms->name.  Confirming that would tell us
> whether you need to make a patch
> for upstream or not.
>
> Thanks Yifeng!
>
> - Greg
>
>
> On Mon, Sep 17, 2018 at 9:51 AM Yifeng Sun  wrote:
>
>> Hi Greg,
>>
>> Sure, thanks for the review. I will work on it.
>>
>> Yifeng
>>
>> On Mon, Sep 17, 2018 at 8:49 AM Gregory Rose 
>> wrote:
>>
>>> On 9/15/2018 9:24 PM, Yifeng Sun wrote:
>>> > On certain kernel versions, when openvswitch kernel module creates
>>> > a gre0 interface, the kernel’s gre module will jump out and compete
>>> > to control the gre0 interface. This will cause the failure of
>>> > openvswitch kernel module loading.
>>> >
>>> > This fix renames fallback devices by adding a prefix "ovs-".
>>> >
>>> > Signed-off-by: Yifeng Sun 
>>> > VMware Issue: #2162866
>>> > ---
>>> > Please backport this patch to upstream OVS down to 2.9, thanks.
>>> >
>>> > v1->v2: Added sanity check for device names, thanks Justin.
>>> > v2->v3: Fix an indent error.
>>> > v3->v4: Fix by code review, also fix a potenial bug.
>>> >
>>> >   datapath/linux/compat/ip6_gre.c| 5 +++--
>>> >   datapath/linux/compat/ip6_tunnel.c | 6 +++---
>>> >   datapath/linux/compat/ip_gre.c | 2 +-
>>> >   datapath/linux/compat/ip_tunnel.c  | 7 +++
>>> >   4 files changed, 10 insertions(+), 10 deletions(-)
>>> >
>>> > diff --git a/datapath/linux/compat/ip6_gre.c
>>> b/datapath/linux/compat/ip6_gre.c
>>> > index 00dbefc9b099..182785273c6f 100644
>>> > --- a/datapath/linux/compat/ip6_gre.c
>>> > +++ b/datapath/linux/compat/ip6_gre.c
>>> > @@ -377,7 +377,7 @@ static struct ip6_tnl *ip6gre_tunnel_locate(struct
>>> net *net,
>>> >   if (parms->name[0])
>>> >   strlcpy(name, parms->name, IFNAMSIZ);
>>> >   else
>>> > - strcpy(name, "ip6gre%d");
>>> > + strlcpy(name, "ovs-ip6gre%d", IFNAMSIZ);
>>> >
>>> >   dev = alloc_netdev(sizeof(*t), name, NET_NAME_UNKNOWN,
>>> >  ip6gre_tunnel_setup);
>>> > @@ -1712,7 +1712,8 @@ static int __net_init ip6gre_init_net(struct net
>>> *net)
>>> >   struct ip6gre_net *ign = net_generic(net, ip6gre_net_id);
>>> >   int err;
>>> >
>>> > - ign->fb_tunnel_dev = alloc_netdev(sizeof(struct ip6_tnl),
>>> "ip6gre0",
>>> > + ign->fb_tunnel_dev = alloc_netdev(sizeof(struct ip6_tnl),
>>> > +   "ovs-ip6gre0",
>>> > NET_NAME_UNKNOWN,
>>> > ip6gre_tunnel_setup);
>>> >   if (!ign->fb_tunnel_dev) {
>>> > diff --git a/datapath/linux/compat/ip6_tunnel.c
>>> b/datapath/linux/compat/ip6_tunnel.c
>>> > index 56fd8b4dd342..9f4bae7dd3d1 100644
>>> > --- a/datapath/linux/compat/ip6_tunnel.c
>>> > +++ b/datapath/linux/compat/ip6_tunnel.c
>>> > @@ -355,7 +355,7 @@ static struct ip6_tnl *ip6_tnl_create(struct net
>>> *net, struct __ip6_tnl_parm *p)
>>> >   if (p->name[0])
>>> >   strlcpy(name, p->name, IFNAMSIZ);
>>> >   else
>>> > - sprintf(name, "ip6tnl%%d");
>>> > + strlcpy(name, "ovs-ip6tnl%d", IFNAMSIZ);
>>> >
>>> >   dev = alloc_netdev(sizeof(*t), name, NET_NAME_UNKNOWN,
>>> >  ip6_tnl_dev_setup);
>>> > @@ -1410,7 +1410,7 @@ ip6_tnl_parm_to_user(struct ip6_tnl_parm *u,
>>> const struct __ip6_tnl_parm *p)
>>> >* %SIOCCHGTUNNEL: change tunnel parameters to those given
>>> >* %SIOCDELTUNNEL: delete tunnel
>>> >*
>>> > - *   The fallback device "ip6tnl0", created during module
>>> > + *   The fallback device "ovs-ip6tnl0", created during module
>>> >*   initialization, can be used for creating other tunnel devices.
>>> >*
>>> >* Return:
>>> > @@ -2093,7 +2093,7 @@ static int __net_init ip6_tnl_init_net(struct
>>> net *net)
>>> >   ip6n->tnls[1] = ip6n->tnls_r_l;
>>> >
>>> >   err = -ENOMEM;
>>> > -

[ovs-dev] Máster en Dirección Comercial

2018-09-17 Thread Estrategia de ventas 



 
 
 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

 
 
 
 

---
Este correo electrónico ha sido comprobado en busca de virus por AVG.
http://www.avg.com
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v4] gre: Rename fallback devices to avoid udev's interference

2018-09-17 Thread Gregory Rose 

On 9/17/2018 1:40 PM, Yifeng Sun wrote:

Hi Greg,

I checked that the 'else' part in the above patch is actually
executed. So it should be necessary to keep them.

Thanks,
Yifeng


That's interesting but I expect that it is only executed once during 
creation of the FB device.  Does it continue
to get invoked if you keep adding new tunnels?  Can you try adding new 
ip gre tunnels and see if we would ever actually get to 100 of them? 
Enough to create a 3 digit trailing number?


The reason I ask is that the kernel code is checking IFNAMSIZ - 3 and I 
think that check is sufficient because
only the FB devices, of which there should only be one, will cause that 
block to be executed.  I'm not sure
though!  If you could try that out I'd appreciate it but I do believe 
that for all non-FB devices cases the name
of the tunnel will be in parms->name.  Confirming that would tell us 
whether you need to make a patch

for upstream or not.

Thanks Yifeng!

- Greg



On Mon, Sep 17, 2018 at 9:51 AM Yifeng Sun > wrote:


Hi Greg,

Sure, thanks for the review. I will work on it.

Yifeng

On Mon, Sep 17, 2018 at 8:49 AM Gregory Rose mailto:gvrose8...@gmail.com>> wrote:

On 9/15/2018 9:24 PM, Yifeng Sun wrote:
> On certain kernel versions, when openvswitch kernel module
creates
> a gre0 interface, the kernel’s gre module will jump out and
compete
> to control the gre0 interface. This will cause the failure of
> openvswitch kernel module loading.
>
> This fix renames fallback devices by adding a prefix "ovs-".
>
> Signed-off-by: Yifeng Sun mailto:pkusunyif...@gmail.com>>
> VMware Issue: #2162866
> ---
> Please backport this patch to upstream OVS down to 2.9, thanks.
>
> v1->v2: Added sanity check for device names, thanks Justin.
> v2->v3: Fix an indent error.
> v3->v4: Fix by code review, also fix a potenial bug.
>
>   datapath/linux/compat/ip6_gre.c    | 5 +++--
>   datapath/linux/compat/ip6_tunnel.c | 6 +++---
>   datapath/linux/compat/ip_gre.c     | 2 +-
>   datapath/linux/compat/ip_tunnel.c  | 7 +++
>   4 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/datapath/linux/compat/ip6_gre.c
b/datapath/linux/compat/ip6_gre.c
> index 00dbefc9b099..182785273c6f 100644
> --- a/datapath/linux/compat/ip6_gre.c
> +++ b/datapath/linux/compat/ip6_gre.c
> @@ -377,7 +377,7 @@ static struct ip6_tnl
*ip6gre_tunnel_locate(struct net *net,
>       if (parms->name[0])
>               strlcpy(name, parms->name, IFNAMSIZ);
>       else
> -             strcpy(name, "ip6gre%d");
> +             strlcpy(name, "ovs-ip6gre%d", IFNAMSIZ);
>
>       dev = alloc_netdev(sizeof(*t), name, NET_NAME_UNKNOWN,
>                          ip6gre_tunnel_setup);
> @@ -1712,7 +1712,8 @@ static int __net_init
ip6gre_init_net(struct net *net)
>       struct ip6gre_net *ign = net_generic(net, ip6gre_net_id);
>       int err;
>
> -     ign->fb_tunnel_dev = alloc_netdev(sizeof(struct
ip6_tnl), "ip6gre0",
> +     ign->fb_tunnel_dev = alloc_netdev(sizeof(struct ip6_tnl),
> +  "ovs-ip6gre0",
>  NET_NAME_UNKNOWN,
>  ip6gre_tunnel_setup);
>       if (!ign->fb_tunnel_dev) {
> diff --git a/datapath/linux/compat/ip6_tunnel.c
b/datapath/linux/compat/ip6_tunnel.c
> index 56fd8b4dd342..9f4bae7dd3d1 100644
> --- a/datapath/linux/compat/ip6_tunnel.c
> +++ b/datapath/linux/compat/ip6_tunnel.c
> @@ -355,7 +355,7 @@ static struct ip6_tnl
*ip6_tnl_create(struct net *net, struct __ip6_tnl_parm *p)
>       if (p->name[0])
>               strlcpy(name, p->name, IFNAMSIZ);
>       else
> -             sprintf(name, "ip6tnl%%d");
> +             strlcpy(name, "ovs-ip6tnl%d", IFNAMSIZ);
>
>       dev = alloc_netdev(sizeof(*t), name, NET_NAME_UNKNOWN,
>                          ip6_tnl_dev_setup);
> @@ -1410,7 +1410,7 @@ ip6_tnl_parm_to_user(struct
ip6_tnl_parm *u, const struct __ip6_tnl_parm *p)
>    *     %SIOCCHGTUNNEL: change tunnel parameters to those given
>    *     %SIOCDELTUNNEL: delete tunnel
>    *
> - *   The fallback device "ip6tnl0", created during module
> + *   The fallback device "ovs-ip6tnl0", created during module
>    *   initialization, can be used for creating other tunnel
devices.
>    *
>    * Return:
> @@ -2093,7 +2093,7 @@ static int __net_init
ip6_tnl_init_net(struct net *net)
>       ip6n->tnls[1] = ip6n->tnls_r_l;
>
>       err = -ENOMEM;

[ovs-dev] [patch v2] conntrack: Add rcu support.

2018-09-17 Thread Darrell Ball 
Add in rcu support for conntrack. At the same time, the array of
hmaps is replaced by a cmap.  Using a single map also simplifies
the handling of nat and allows the removal of the nat_conn map.
There is still some cleanup to do and a few things to check. I'll
probably split out into several patches later

Signed-off-by: Darrell Ball 
---

v1->v2: Some synchronization changes; new expiry lists lock.
Fix the 4 Travis builds that were failing.

 lib/conntrack-icmp.c|  20 +-
 lib/conntrack-other.c   |  14 +-
 lib/conntrack-private.h | 129 ++--
 lib/conntrack-tcp.c |  33 +-
 lib/conntrack.c | 853 ++--
 lib/conntrack.h |  86 +
 6 files changed, 475 insertions(+), 660 deletions(-)

diff --git a/lib/conntrack-icmp.c b/lib/conntrack-icmp.c
index 40fd1d8..4c7960b 100644
--- a/lib/conntrack-icmp.c
+++ b/lib/conntrack-icmp.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2015, 2016 Nicira, Inc.
+ * Copyright (c) 2015, 2016, 2017, 2018 Nicira, Inc.
  *
  * Licensed under the Apache License, Version 2.0 (the "License");
  * you may not use this file except in compliance with the License.
@@ -46,16 +46,17 @@ conn_icmp_cast(const struct conn *conn)
 }
 
 static enum ct_update_res
-icmp_conn_update(struct conn *conn_, struct conntrack_bucket *ctb,
- struct dp_packet *pkt OVS_UNUSED, bool reply, long long now)
+icmp_conn_update(struct conn *conn_, struct dp_packet *pkt OVS_UNUSED,
+ bool reply, long long now)
 {
 struct conn_icmp *conn = conn_icmp_cast(conn_);
 
-if (reply && conn->state != ICMPS_REPLY) {
+conn->state = ICMPS_FIRST;
+if (reply) {
 conn->state = ICMPS_REPLY;
 }
 
-conn_update_expiration(ctb, >up, icmp_timeouts[conn->state], now);
+conn_update_expiration(>up, icmp_timeouts[conn->state], now);
 
 return CT_UPDATE_VALID;
 }
@@ -79,15 +80,12 @@ icmp6_valid_new(struct dp_packet *pkt)
 }
 
 static struct conn *
-icmp_new_conn(struct conntrack_bucket *ctb, struct dp_packet *pkt OVS_UNUSED,
-   long long now)
+icmp_new_conn(struct dp_packet *pkt OVS_UNUSED, long long now)
 {
-struct conn_icmp *conn;
-
-conn = xzalloc(sizeof *conn);
+struct conn_icmp *conn = xzalloc(sizeof *conn);
 conn->state = ICMPS_FIRST;
 
-conn_init_expiration(ctb, >up, icmp_timeouts[conn->state], now);
+conn_init_expiration(>up, icmp_timeouts[conn->state], now);
 
 return >up;
 }
diff --git a/lib/conntrack-other.c b/lib/conntrack-other.c
index 2920889..79efb5f 100644
--- a/lib/conntrack-other.c
+++ b/lib/conntrack-other.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2015, 2016 Nicira, Inc.
+ * Copyright (c) 2015, 2016, 2017, 2018 Nicira, Inc.
  *
  * Licensed under the Apache License, Version 2.0 (the "License");
  * you may not use this file except in compliance with the License.
@@ -43,8 +43,8 @@ conn_other_cast(const struct conn *conn)
 }
 
 static enum ct_update_res
-other_conn_update(struct conn *conn_, struct conntrack_bucket *ctb,
-  struct dp_packet *pkt OVS_UNUSED, bool reply, long long now)
+other_conn_update(struct conn *conn_, struct dp_packet *pkt OVS_UNUSED,
+  bool reply, long long now)
 {
 struct conn_other *conn = conn_other_cast(conn_);
 
@@ -54,7 +54,7 @@ other_conn_update(struct conn *conn_, struct conntrack_bucket 
*ctb,
 conn->state = OTHERS_MULTIPLE;
 }
 
-conn_update_expiration(ctb, >up, other_timeouts[conn->state], now);
+conn_update_expiration(>up, other_timeouts[conn->state], now);
 
 return CT_UPDATE_VALID;
 }
@@ -66,15 +66,13 @@ other_valid_new(struct dp_packet *pkt OVS_UNUSED)
 }
 
 static struct conn *
-other_new_conn(struct conntrack_bucket *ctb, struct dp_packet *pkt OVS_UNUSED,
-   long long now)
+other_new_conn(struct dp_packet *pkt OVS_UNUSED, long long now)
 {
 struct conn_other *conn;
 
 conn = xzalloc(sizeof *conn);
 conn->state = OTHERS_FIRST;
-
-conn_init_expiration(ctb, >up, other_timeouts[conn->state], now);
+conn_init_expiration(>up, other_timeouts[conn->state], now);
 
 return >up;
 }
diff --git a/lib/conntrack-private.h b/lib/conntrack-private.h
index a344801..eafe739 100644
--- a/lib/conntrack-private.h
+++ b/lib/conntrack-private.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2015, 2016, 2017 Nicira, Inc.
+ * Copyright (c) 2015, 2016, 2017, 2018 Nicira, Inc.
  *
  * Licensed under the Apache License, Version 2.0 (the "License");
  * you may not use this file except in compliance with the License.
@@ -21,6 +21,7 @@
 #include 
 #include 
 
+#include "cmap.h"
 #include "conntrack.h"
 #include "ct-dpif.h"
 #include "openvswitch/hmap.h"
@@ -57,12 +58,6 @@ struct conn_key {
 uint8_t nw_proto;
 };
 
-struct nat_conn_key_node {
-struct hmap_node node;
-struct conn_key key;
-struct conn_key value;
-};
-
 /* This is used for alg expectations; an expectation is a
  * context created in preparation for establishing a data
  *

Re: [ovs-dev] [PATCH v4] gre: Rename fallback devices to avoid udev's interference

2018-09-17 Thread Yifeng Sun 
Hi Greg,

I checked that the 'else' part in the above patch is actually
executed. So it should be necessary to keep them.

Thanks,
Yifeng

On Mon, Sep 17, 2018 at 9:51 AM Yifeng Sun  wrote:

> Hi Greg,
>
> Sure, thanks for the review. I will work on it.
>
> Yifeng
>
> On Mon, Sep 17, 2018 at 8:49 AM Gregory Rose  wrote:
>
>> On 9/15/2018 9:24 PM, Yifeng Sun wrote:
>> > On certain kernel versions, when openvswitch kernel module creates
>> > a gre0 interface, the kernel’s gre module will jump out and compete
>> > to control the gre0 interface. This will cause the failure of
>> > openvswitch kernel module loading.
>> >
>> > This fix renames fallback devices by adding a prefix "ovs-".
>> >
>> > Signed-off-by: Yifeng Sun 
>> > VMware Issue: #2162866
>> > ---
>> > Please backport this patch to upstream OVS down to 2.9, thanks.
>> >
>> > v1->v2: Added sanity check for device names, thanks Justin.
>> > v2->v3: Fix an indent error.
>> > v3->v4: Fix by code review, also fix a potenial bug.
>> >
>> >   datapath/linux/compat/ip6_gre.c| 5 +++--
>> >   datapath/linux/compat/ip6_tunnel.c | 6 +++---
>> >   datapath/linux/compat/ip_gre.c | 2 +-
>> >   datapath/linux/compat/ip_tunnel.c  | 7 +++
>> >   4 files changed, 10 insertions(+), 10 deletions(-)
>> >
>> > diff --git a/datapath/linux/compat/ip6_gre.c
>> b/datapath/linux/compat/ip6_gre.c
>> > index 00dbefc9b099..182785273c6f 100644
>> > --- a/datapath/linux/compat/ip6_gre.c
>> > +++ b/datapath/linux/compat/ip6_gre.c
>> > @@ -377,7 +377,7 @@ static struct ip6_tnl *ip6gre_tunnel_locate(struct
>> net *net,
>> >   if (parms->name[0])
>> >   strlcpy(name, parms->name, IFNAMSIZ);
>> >   else
>> > - strcpy(name, "ip6gre%d");
>> > + strlcpy(name, "ovs-ip6gre%d", IFNAMSIZ);
>> >
>> >   dev = alloc_netdev(sizeof(*t), name, NET_NAME_UNKNOWN,
>> >  ip6gre_tunnel_setup);
>> > @@ -1712,7 +1712,8 @@ static int __net_init ip6gre_init_net(struct net
>> *net)
>> >   struct ip6gre_net *ign = net_generic(net, ip6gre_net_id);
>> >   int err;
>> >
>> > - ign->fb_tunnel_dev = alloc_netdev(sizeof(struct ip6_tnl),
>> "ip6gre0",
>> > + ign->fb_tunnel_dev = alloc_netdev(sizeof(struct ip6_tnl),
>> > +   "ovs-ip6gre0",
>> > NET_NAME_UNKNOWN,
>> > ip6gre_tunnel_setup);
>> >   if (!ign->fb_tunnel_dev) {
>> > diff --git a/datapath/linux/compat/ip6_tunnel.c
>> b/datapath/linux/compat/ip6_tunnel.c
>> > index 56fd8b4dd342..9f4bae7dd3d1 100644
>> > --- a/datapath/linux/compat/ip6_tunnel.c
>> > +++ b/datapath/linux/compat/ip6_tunnel.c
>> > @@ -355,7 +355,7 @@ static struct ip6_tnl *ip6_tnl_create(struct net
>> *net, struct __ip6_tnl_parm *p)
>> >   if (p->name[0])
>> >   strlcpy(name, p->name, IFNAMSIZ);
>> >   else
>> > - sprintf(name, "ip6tnl%%d");
>> > + strlcpy(name, "ovs-ip6tnl%d", IFNAMSIZ);
>> >
>> >   dev = alloc_netdev(sizeof(*t), name, NET_NAME_UNKNOWN,
>> >  ip6_tnl_dev_setup);
>> > @@ -1410,7 +1410,7 @@ ip6_tnl_parm_to_user(struct ip6_tnl_parm *u,
>> const struct __ip6_tnl_parm *p)
>> >* %SIOCCHGTUNNEL: change tunnel parameters to those given
>> >* %SIOCDELTUNNEL: delete tunnel
>> >*
>> > - *   The fallback device "ip6tnl0", created during module
>> > + *   The fallback device "ovs-ip6tnl0", created during module
>> >*   initialization, can be used for creating other tunnel devices.
>> >*
>> >* Return:
>> > @@ -2093,7 +2093,7 @@ static int __net_init ip6_tnl_init_net(struct net
>> *net)
>> >   ip6n->tnls[1] = ip6n->tnls_r_l;
>> >
>> >   err = -ENOMEM;
>> > - ip6n->fb_tnl_dev = alloc_netdev(sizeof(struct ip6_tnl), "ip6tnl0",
>> > + ip6n->fb_tnl_dev = alloc_netdev(sizeof(struct ip6_tnl),
>> "ovs-ip6tnl0",
>> >   NET_NAME_UNKNOWN,
>> ip6_tnl_dev_setup);
>> >
>> >   if (!ip6n->fb_tnl_dev)
>> > diff --git a/datapath/linux/compat/ip_gre.c
>> b/datapath/linux/compat/ip_gre.c
>> > index 05132ba9494a..b7322c58e420 100644
>> > --- a/datapath/linux/compat/ip_gre.c
>> > +++ b/datapath/linux/compat/ip_gre.c
>> > @@ -1463,7 +1463,7 @@ static struct pernet_operations erspan_net_ops = {
>> >
>> >   static int __net_init ipgre_tap_init_net(struct net *net)
>> >   {
>> > - return ip_tunnel_init_net(net, gre_tap_net_id, _tap_ops,
>> "gretap0");
>> > + return ip_tunnel_init_net(net, gre_tap_net_id, _tap_ops,
>> "ovs-gretap0");
>> >   }
>> >
>> >   static void __net_exit ipgre_tap_exit_net(struct net *net)
>> > diff --git a/datapath/linux/compat/ip_tunnel.c
>> b/datapath/linux/compat/ip_tunnel.c
>> > index d16e60fbfef0..ae5d5a058663 100644
>> > --- a/datapath/linux/compat/ip_tunnel.c
>> > +++ b/datapath/linux/compat/ip_tunnel.c
>> > @@ -130,12 +130,11 @@ static struct net_device
>> *__ip_tunnel_create(struct net *net,
>> >   if

Re: [ovs-dev] [PATCH] ovn: Add DHCP support for option 252.

2018-09-17 Thread Mark Michelson 

Hi folks,

Any chance that this could be a candidate for a 2.10 backport?

On 08/20/2018 04:14 PM, Mark Michelson wrote:

This adds DHCP support for web proxy auto detection.

Signed-off-by: Mark Michelson 
---
  ovn/lib/ovn-l7.h| 2 ++
  ovn/northd/ovn-northd.c | 3 ++-
  ovn/ovn-nb.xml  | 8 
  tests/ovn.at| 6 +++---
  tests/test-ovn.c| 1 +
  5 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/ovn/lib/ovn-l7.h b/ovn/lib/ovn-l7.h
index b8d6683bc..817e9f002 100644
--- a/ovn/lib/ovn-l7.h
+++ b/ovn/lib/ovn-l7.h
@@ -70,6 +70,8 @@ struct gen_opts_map {
  #define DHCP_OPT_T1 DHCP_OPTION("T1", 58, "uint32")
  #define DHCP_OPT_T2 DHCP_OPTION("T2", 59, "uint32")
  
+#define DHCP_OPT_WPAD DHCP_OPTION("wpad", 252, "str")

+
  static inline uint32_t
  gen_opt_hash(char *opt_name)
  {
diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
index ba86bf559..a1cfd4bdf 100644
--- a/ovn/northd/ovn-northd.c
+++ b/ovn/northd/ovn-northd.c
@@ -7186,7 +7186,8 @@ static struct gen_opts_map supported_dhcp_opts[] = {
  DHCP_OPT_MTU,
  DHCP_OPT_LEASE_TIME,
  DHCP_OPT_T1,
-DHCP_OPT_T2
+DHCP_OPT_T2,
+DHCP_OPT_WPAD,
  };
  
  static struct gen_opts_map supported_dhcpv6_opts[] = {

diff --git a/ovn/ovn-nb.xml b/ovn/ovn-nb.xml
index bc60a25dd..441a2deae 100644
--- a/ovn/ovn-nb.xml
+++ b/ovn/ovn-nb.xml
@@ -1991,6 +1991,14 @@
  Microsoft Windows DHCPv4 clients.

  
+
+
+  
+The DHCPv4 option code for this option is 252. This option is used
+as part of web proxy auto discovery to provide a URL for a web
+proxy.
+  
+

  


diff --git a/tests/ovn.at b/tests/ovn.at
index 70c6c50b3..6165d69c0 100644
--- a/tests/ovn.at
+++ b/tests/ovn.at
@@ -1100,9 +1100,9 @@ put_arp(inport, arp.spa, arp.sha);
  # put_dhcp_opts
  reg1[0] = put_dhcp_opts(offerip = 1.2.3.4, router = 10.0.0.1);
  encodes as 
controller(userdata=00.00.00.02.00.00.00.00.00.01.de.10.00.00.00.40.01.02.03.04.03.04.0a.00.00.01,pause)
-reg2[5] = 
put_dhcp_opts(offerip=10.0.0.4,router=10.0.0.1,netmask=255.255.254.0,mtu=1400,domain="ovn.org");
-formats as reg2[5] = put_dhcp_opts(offerip = 10.0.0.4, router = 10.0.0.1, netmask = 
255.255.254.0, mtu = 1400, domain = "ovn.org");
-encodes as 
controller(userdata=00.00.00.02.00.00.00.00.00.01.de.10.00.00.00.25.0a.00.00.04.03.04.0a.00.00.01.01.04.ff.ff.fe.00.1a.02.05.78.0f.07.6f.76.6e.2e.6f.72.67,pause)
+reg2[5] = 
put_dhcp_opts(offerip=10.0.0.4,router=10.0.0.1,netmask=255.255.254.0,mtu=1400,domain="ovn.org",wpad="https://example.org;);
+formats as reg2[5] = put_dhcp_opts(offerip = 10.0.0.4, router = 10.0.0.1, netmask = 
255.255.254.0, mtu = 1400, domain = "ovn.org", wpad = "https://example.org;);
+encodes as 
controller(userdata=00.00.00.02.00.00.00.00.00.01.de.10.00.00.00.25.0a.00.00.04.03.04.0a.00.00.01.01.04.ff.ff.fe.00.1a.02.05.78.0f.07.6f.76.6e.2e.6f.72.67.fc.13.68.74.74.70.73.3a.2f.2f.65.78.61.6d.70.6c.65.2e.6f.72.67,pause)
  reg0[15] = 
put_dhcp_opts(offerip=10.0.0.4,router=10.0.0.1,netmask=255.255.255.0,mtu=1400,ip_forward_enable=1,default_ttl=121,dns_server={8.8.8.8,7.7.7.7},classless_static_route={30.0.0.0/24,10.0.0.4,40.0.0.0/16,10.0.0.6,0.0.0.0/0,10.0.0.1},ethernet_encap=1,router_discovery=0);
  formats as reg0[15] = put_dhcp_opts(offerip = 10.0.0.4, router = 
10.0.0.1, netmask = 255.255.255.0, mtu = 1400, ip_forward_enable = 1, 
default_ttl = 121, dns_server = {8.8.8.8, 7.7.7.7}, classless_static_route = 
{30.0.0.0/24, 10.0.0.4, 40.0.0.0/16, 10.0.0.6, 0.0.0.0/0, 10.0.0.1}, 
ethernet_encap = 1, router_discovery = 0);
  encodes as 
controller(userdata=00.00.00.02.00.00.00.00.00.01.de.10.00.00.00.6f.0a.00.00.04.03.04.0a.00.00.01.01.04.ff.ff.ff.00.1a.02.05.78.13.01.01.17.01.79.06.08.08.08.08.08.07.07.07.07.79.14.18.1e.00.00.0a.00.00.04.10.28.00.0a.00.00.06.00.0a.00.00.01.24.01.01.1f.01.00,pause)
diff --git a/tests/test-ovn.c b/tests/test-ovn.c
index d4a5d599e..5e6d1c3b4 100644
--- a/tests/test-ovn.c
+++ b/tests/test-ovn.c
@@ -182,6 +182,7 @@ create_gen_opts(struct hmap *dhcp_opts, struct hmap 
*dhcpv6_opts,
  dhcp_opt_add(dhcp_opts, "tcp_ttl", 37, "uint8");
  dhcp_opt_add(dhcp_opts, "mtu", 26, "uint16");
  dhcp_opt_add(dhcp_opts, "lease_time",  51, "uint32");
+dhcp_opt_add(dhcp_opts, "wpad", 252, "str");
  
  /* DHCPv6 options. */

  hmap_init(dhcpv6_opts);



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

Re: [ovs-dev] [ovs-discuss] [PATCH v2] [PATCH] QinQ: support more vlan headers.

2018-09-17 Thread Eric Garver 
On Tue, Sep 11, 2018 at 01:10:09AM +, Lilijun (Jerry, Cloud Networking) 
wrote:
> Thanks for your reply.
> 
> In my use case, it's OVS userspace datapath with dpdk.
> 
>  My detail case was a bit complicated as follows:
> 1. Start the OVS userspace datapath with dpdk in my host server. 
> 2. A VM was running and the VNIC's  vhostuser port on the userspace datapath 
> is configured as QinQ  mode, qinq-ethtype 802.1q.
> 3. Another kernel OVS is running in that VM to switch packets of some 
> containers. Then the container's VNIC port on the kernel datapath is also 
> configured as QinQ  Mode, qinq-ethtype=802.1q .
> 4. So when the container sends a packet with VLAN tag,  the OVS running in 
> the host will receive a packet with 2 VLANS from the VM.
> 5. Here the QinQ is not worked when we need 3 VLANs. 
> 
> Yes, VXLAN or PBB can work but we need change our basic  network topology and 
> push/pop for every packets.  That maybe the last choice if QinQ can't support 
> triple VLAN.

There is still a push/pop for the third VLAN tag.

I'm not sure it makes sense to support the extra VLANs in upstream OVS.
This is non-standard and there are alternatives such as VXLAN. If it
wasn't splitting the MPLS labels across cache lines then it would be a
harmless change.

> 
> -Original Message-
> From: Ben Pfaff [mailto:b...@ovn.org] 
> Sent: Tuesday, September 11, 2018 3:33 AM
> To: Eric Garver ; Lilijun (Jerry, Cloud Networking) 
> ; d...@openvswitch.org; ovs-disc...@openvswitch.org
> Subject: Re: [ovs-discuss] [PATCH v2] [ovs-dev] [PATCH] QinQ: support more 
> vlan headers.
> 
> On Mon, Sep 10, 2018 at 03:15:21PM -0400, Eric Garver wrote:
> > On Mon, Sep 10, 2018 at 03:03:19AM +, Lilijun (Jerry, Cloud Networking) 
> > wrote:
> > > Hi Eric,
> > > 
> > > Yes, I agree with that effect. 
> > > But how about this issue of QinQ that we can only support at most 2 VLANs 
> > > ?  Do you have any ideas?
> > 
> > I was not NACKing the idea. Just wanted everyone to understand the 
> > implications of increasing the VLAN field size.
> > 
> > I tried playing with the fields, but didn't come with a reasonable way 
> > to rearrange them to make room for the extra VLANs.
> > 
> > I'm curious what you're use case is for triple VLAN. I wonder if VXLAN 
> > or PBB (802.1ah) is a better solution.
> 
> I'd also like to know what datapath we're talking about.  The Linux kernel 
> datapath only supports 2 VLANs in any case.
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] PLM Software Users List

2018-09-17 Thread emma . stone 




















style="color:rgb(0,32,96)">Hi,


style="color:rgb(0,32,96)"> 


style="color:rgb(0,32,96)">Would

you be interested in acquiring Product
Lifecycle Management Software Users List for marketing or email  
campaign?


style="color:rgb(0,32,96)"> 


style="color:rgb(0,32,96)">We

can segment Industry List  Technology Users List by C-level, VP-level,
Director-Level and Manager Level as per your  
requirements.


style="color:rgb(0,32,96)"> 


style="color:rgb(0,32,96)">We also have other Innovative
users: SAP PLM, Infor PLM, Aras  
PLM, FusePLM, Agile PLM, Siemens

PLM and many more.

style="color:rgb(0,32,96)"> 


style="color:rgb(0,32,96)">Kindly
review and advice or forward this email to the marketing head in your  
company

who are currently working on some requirements.

style="color:rgb(0,32,96)"> 


style="color:rgb(0,32,96)">Awaiting

your response!

style="color:rgb(0,32,96)"> 


style="color:rgb(0,32,96)">Regards,


style="color:rgb(0,32,96)">Emma

Stone

style="color:rgb(0,32,96)">Data

Specialist

style="color:rgb(0,32,96)"> 


style="color:rgb(0,32,96)">   

To opt-out reply in subject line.
href='chrome.google.com/webstore/detail/gsm-mailmerge/fjimadonilpeknihlnnkbgmlmjneodgk'>powered  
by GSM. Free mail merge and email marketing software for Gmail.

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

Re: [ovs-dev] [PATCH v4] gre: Rename fallback devices to avoid udev's interference

2018-09-17 Thread Yifeng Sun 
Hi Greg,

Sure, thanks for the review. I will work on it.

Yifeng

On Mon, Sep 17, 2018 at 8:49 AM Gregory Rose  wrote:

> On 9/15/2018 9:24 PM, Yifeng Sun wrote:
> > On certain kernel versions, when openvswitch kernel module creates
> > a gre0 interface, the kernel’s gre module will jump out and compete
> > to control the gre0 interface. This will cause the failure of
> > openvswitch kernel module loading.
> >
> > This fix renames fallback devices by adding a prefix "ovs-".
> >
> > Signed-off-by: Yifeng Sun 
> > VMware Issue: #2162866
> > ---
> > Please backport this patch to upstream OVS down to 2.9, thanks.
> >
> > v1->v2: Added sanity check for device names, thanks Justin.
> > v2->v3: Fix an indent error.
> > v3->v4: Fix by code review, also fix a potenial bug.
> >
> >   datapath/linux/compat/ip6_gre.c| 5 +++--
> >   datapath/linux/compat/ip6_tunnel.c | 6 +++---
> >   datapath/linux/compat/ip_gre.c | 2 +-
> >   datapath/linux/compat/ip_tunnel.c  | 7 +++
> >   4 files changed, 10 insertions(+), 10 deletions(-)
> >
> > diff --git a/datapath/linux/compat/ip6_gre.c
> b/datapath/linux/compat/ip6_gre.c
> > index 00dbefc9b099..182785273c6f 100644
> > --- a/datapath/linux/compat/ip6_gre.c
> > +++ b/datapath/linux/compat/ip6_gre.c
> > @@ -377,7 +377,7 @@ static struct ip6_tnl *ip6gre_tunnel_locate(struct
> net *net,
> >   if (parms->name[0])
> >   strlcpy(name, parms->name, IFNAMSIZ);
> >   else
> > - strcpy(name, "ip6gre%d");
> > + strlcpy(name, "ovs-ip6gre%d", IFNAMSIZ);
> >
> >   dev = alloc_netdev(sizeof(*t), name, NET_NAME_UNKNOWN,
> >  ip6gre_tunnel_setup);
> > @@ -1712,7 +1712,8 @@ static int __net_init ip6gre_init_net(struct net
> *net)
> >   struct ip6gre_net *ign = net_generic(net, ip6gre_net_id);
> >   int err;
> >
> > - ign->fb_tunnel_dev = alloc_netdev(sizeof(struct ip6_tnl),
> "ip6gre0",
> > + ign->fb_tunnel_dev = alloc_netdev(sizeof(struct ip6_tnl),
> > +   "ovs-ip6gre0",
> > NET_NAME_UNKNOWN,
> > ip6gre_tunnel_setup);
> >   if (!ign->fb_tunnel_dev) {
> > diff --git a/datapath/linux/compat/ip6_tunnel.c
> b/datapath/linux/compat/ip6_tunnel.c
> > index 56fd8b4dd342..9f4bae7dd3d1 100644
> > --- a/datapath/linux/compat/ip6_tunnel.c
> > +++ b/datapath/linux/compat/ip6_tunnel.c
> > @@ -355,7 +355,7 @@ static struct ip6_tnl *ip6_tnl_create(struct net
> *net, struct __ip6_tnl_parm *p)
> >   if (p->name[0])
> >   strlcpy(name, p->name, IFNAMSIZ);
> >   else
> > - sprintf(name, "ip6tnl%%d");
> > + strlcpy(name, "ovs-ip6tnl%d", IFNAMSIZ);
> >
> >   dev = alloc_netdev(sizeof(*t), name, NET_NAME_UNKNOWN,
> >  ip6_tnl_dev_setup);
> > @@ -1410,7 +1410,7 @@ ip6_tnl_parm_to_user(struct ip6_tnl_parm *u, const
> struct __ip6_tnl_parm *p)
> >* %SIOCCHGTUNNEL: change tunnel parameters to those given
> >* %SIOCDELTUNNEL: delete tunnel
> >*
> > - *   The fallback device "ip6tnl0", created during module
> > + *   The fallback device "ovs-ip6tnl0", created during module
> >*   initialization, can be used for creating other tunnel devices.
> >*
> >* Return:
> > @@ -2093,7 +2093,7 @@ static int __net_init ip6_tnl_init_net(struct net
> *net)
> >   ip6n->tnls[1] = ip6n->tnls_r_l;
> >
> >   err = -ENOMEM;
> > - ip6n->fb_tnl_dev = alloc_netdev(sizeof(struct ip6_tnl), "ip6tnl0",
> > + ip6n->fb_tnl_dev = alloc_netdev(sizeof(struct ip6_tnl),
> "ovs-ip6tnl0",
> >   NET_NAME_UNKNOWN,
> ip6_tnl_dev_setup);
> >
> >   if (!ip6n->fb_tnl_dev)
> > diff --git a/datapath/linux/compat/ip_gre.c
> b/datapath/linux/compat/ip_gre.c
> > index 05132ba9494a..b7322c58e420 100644
> > --- a/datapath/linux/compat/ip_gre.c
> > +++ b/datapath/linux/compat/ip_gre.c
> > @@ -1463,7 +1463,7 @@ static struct pernet_operations erspan_net_ops = {
> >
> >   static int __net_init ipgre_tap_init_net(struct net *net)
> >   {
> > - return ip_tunnel_init_net(net, gre_tap_net_id, _tap_ops,
> "gretap0");
> > + return ip_tunnel_init_net(net, gre_tap_net_id, _tap_ops,
> "ovs-gretap0");
> >   }
> >
> >   static void __net_exit ipgre_tap_exit_net(struct net *net)
> > diff --git a/datapath/linux/compat/ip_tunnel.c
> b/datapath/linux/compat/ip_tunnel.c
> > index d16e60fbfef0..ae5d5a058663 100644
> > --- a/datapath/linux/compat/ip_tunnel.c
> > +++ b/datapath/linux/compat/ip_tunnel.c
> > @@ -130,12 +130,11 @@ static struct net_device
> *__ip_tunnel_create(struct net *net,
> >   if (parms->name[0])
> >   strlcpy(name, parms->name, IFNAMSIZ);
> >   else {
> > - if (strlen(ops->kind) > (IFNAMSIZ - 3)) {
> > + err = snprintf(name, IFNAMSIZ - 3, "ovs-%s%%d", ops->kind);
> > + if (err >= IFNAMSIZ - 3)
> >   err = -E2BIG;
> >

Re: [ovs-dev] [dpdk-howl PATCH v2] netdev-dpdk: Upgrade to dpdk v18.08.0

2018-09-17 Thread Eelco Chaudron 

Hi Ophir,

I did some basic PVP testing root vs non-root and it all seems to work 
as expected (did not do any performance comparison).


I do see compiler warnings about usage of deprecated DPDK functions, I 
guess these need to be fixed:



lib/netdev-dpdk.c: In function 'netdev_dpdk_destruct':
lib/netdev-dpdk.c:1336:9: error: 'rte_eth_dev_detach' is deprecated 
(declared at 
/home/root/OVS_dpdk-hwol_DPDK_v18.08/dpdk-stable/x86_64-native-linuxapp-gcc/include/rte_ethdev.h:1451) 
[-Werror=deprecated-declarations]

 if (rte_eth_dev_detach(dev->port_id, devname) < 0) {
 ^
lib/netdev-dpdk.c: In function 'netdev_dpdk_process_devargs':
lib/netdev-dpdk.c:1629:13: error: 'rte_eth_dev_attach' is deprecated 
(declared at 
/home/root/OVS_dpdk-hwol_DPDK_v18.08/dpdk-stable/x86_64-native-linuxapp-gcc/include/rte_ethdev.h:1435) 
[-Werror=deprecated-declarations]

 if (!rte_eth_dev_attach(devargs, _port_id)) {
 ^
lib/netdev-dpdk.c: In function 'netdev_dpdk_detach':
lib/netdev-dpdk.c:3159:5: error: 'rte_eth_dev_detach' is deprecated 
(declared at 
/home/root/OVS_dpdk-hwol_DPDK_v18.08/dpdk-stable/x86_64-native-linuxapp-gcc/include/rte_ethdev.h:1451) 
[-Werror=deprecated-declarations]

 ret = rte_eth_dev_detach(port_id, devname);
 ^

See more comments inline…

//Eelco



On 11 Sep 2018, at 1:04, Ophir Munk wrote:


1. Enable compilation and linkage with dpdk 18.08.0
The following dpdk commits which were introduced after dpdk 17.11.x
require OVS updates to accommodate to the dpdk changes.
- ce17eddefc20 ("ethdev: introduce Rx queue offloads API")
- ab3ce1e0c193 ("ethdev: remove old offload API")
- c06ddf9698e0 ("meter: add configuration profile")
- e58638c32411 ("ethdev: fix TPID handling in flow API")
- cd8c7c7ce241 ("ethdev: replace bus specific struct with generic 
dev")

- ac8d22de2394 ("ethdev: flatten RSS configuration in flow API")

2. Limit configured rss hash functions to only those supported
by the eth device.

3. Update references to DPDK version in Documentation

4. Update DPDK version in travis' linux-build script

Signed-off-by: Ophir Munk 
---
v1:
First version

v2:
Avoid seg faults cases as described in
https://patchwork.ozlabs.org/patch/965451/
by using the patch in:
https://github.com/kevintraynor/ovs-dpdk-master/commit/88f46cc5ab338eb4f3ca5db1eacd0effefe4fa0c

 .travis/linux-build.sh |   2 +-
 Documentation/faq/releases.rst |   2 +-
 lib/netdev-dpdk.c  | 142 
+

 3 files changed, 104 insertions(+), 42 deletions(-)

diff --git a/.travis/linux-build.sh b/.travis/linux-build.sh
index 4b9fc4a..c60ac71 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="18.08.0"
 fi
 install_dpdk $DPDK_VER
 if [ "$CC" = "clang" ]; then
diff --git a/Documentation/faq/releases.rst 
b/Documentation/faq/releases.rst

index 41d41e3..646ae09 100644
--- a/Documentation/faq/releases.rst
+++ b/Documentation/faq/releases.rst
@@ -168,7 +168,7 @@ Q: What DPDK version does each Open vSwitch 
release work with?

 2.7.x16.11.7
 2.8.x17.05.2
 2.9.x17.11.3
-2.10.x   17.11.3
+2.10.x   18.08.0
  ===

 Q: Are all the DPDK releases that OVS versions work with maintained?
diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
index f91aa27..6879e9a 100644
--- a/lib/netdev-dpdk.c
+++ b/lib/netdev-dpdk.c
@@ -168,11 +168,7 @@ static const struct rte_eth_conf port_conf = {
 .rxmode = {
 .mq_mode = ETH_MQ_RX_RSS,
 .split_hdr_size = 0,
-.header_split   = 0, /* Header Split disabled */
-.hw_ip_checksum = 0, /* IP checksum offload disabled */
-.hw_vlan_filter = 0, /* VLAN filtering disabled */
-.jumbo_frame= 0, /* Jumbo Frame Support disabled */
-.hw_strip_crc   = 0,
+.offloads = 0,
 },
 .rx_adv_conf = {
 .rss_conf = {
@@ -364,6 +360,7 @@ struct dpdk_ring {
 struct ingress_policer {
 struct rte_meter_srtcm_params app_srtcm_params;
 struct rte_meter_srtcm in_policer;
+struct rte_meter_srtcm_profile in_prof;
 rte_spinlock_t policer_lock;
 };
@@ -894,6 +891,8 @@ dpdk_eth_dev_port_config(struct netdev_dpdk *dev, 
int n_rxq, int n_txq)

 struct rte_eth_dev_info info;
 uint16_t conf_mtu;
+rte_eth_dev_info_get(dev->port_id, );
+
 /* As of DPDK 17.11.1 a few PMDs require to explicitly enable
  * scatter to support jumbo RX. Checking the offload capabilities
  * is not an option as PMDs are not required yet to report
@@ -901,20 +900,24 @@ dpdk_eth_dev_port_config(struct netdev_dpdk 
*dev, int n_rxq, int n_txq)

  * (testing or code review). Listing all such PMDs feels harder
  * than highlighting the one known not to need scatter */
 if (dev->mtu > ETHER_MTU) {
-

[ovs-dev] Targeted Global B2B Companies Emails List

2018-09-17 Thread alyssa 

Hello,

Hope all is well!

We are a database organization. We provide business executives' contact  
information.


Below, I've included a few examples:

Industry-Specific Lists: Agriculture, Business Services, Chambers of  
Commerce, Cities, Towns & Municipalities, Construction, Consumer Services,  
Cultural, Education, Energy, Utilities & Waste Treatment, Finance,  
Government, Healthcare, Hospitality, Insurance, Law Firms & Legal Services,  
Manufacturing, Media & Internet, Metals & Mining, Organizations, Real  
Estate, Retail, Software, Telecommunications, Transportation, and more!


Technology-Specific Lists: SAP users, PeopleSoft users, SIEBEL customers,  
Oracle Application customers, Microsoft Dynamic users, Sales force users,  
Microsoft Exchange users, QuickBooks, Lawson users, Act users, JD Edward  
users, ASP users, Microsoft GP Applications users, Net Suite users, IBM  
DBMS Application users, McAfee users, MS Dynamics GP (Great Plains), and  
many more.


Title-Specific Lists: C-level executives: CEO, CFO, CIO, CTO, CMO, CISO,  
CSO, COO Key decision-makers: All C-level, VP-level, and Director-level  
executives HR Executives: VP of HR, HR Director & HR Manager, etc.   
Marketing Executives: CMO, VP of Marketing, Director of Marketing,  
Marketing Managers IT Executives: CIO, CTO, CISO, IT-VP, IT-Director, IT  
Manager, MIS Manager, etc.


Please keep me informed for any additional details. I look forward to  
hearing from you.


Regards,
Alyssa
Marketing Executive

If you don't want to include yourself in our mailing list, please reply  
back “Leave Out" in a subject line

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

Re: [ovs-dev] [PATCH v4] gre: Rename fallback devices to avoid udev's interference

2018-09-17 Thread Gregory Rose 

On 9/15/2018 9:24 PM, Yifeng Sun wrote:

On certain kernel versions, when openvswitch kernel module creates
a gre0 interface, the kernel’s gre module will jump out and compete
to control the gre0 interface. This will cause the failure of
openvswitch kernel module loading.

This fix renames fallback devices by adding a prefix "ovs-".

Signed-off-by: Yifeng Sun 
VMware Issue: #2162866
---
Please backport this patch to upstream OVS down to 2.9, thanks.

v1->v2: Added sanity check for device names, thanks Justin.
v2->v3: Fix an indent error.
v3->v4: Fix by code review, also fix a potenial bug.

  datapath/linux/compat/ip6_gre.c| 5 +++--
  datapath/linux/compat/ip6_tunnel.c | 6 +++---
  datapath/linux/compat/ip_gre.c | 2 +-
  datapath/linux/compat/ip_tunnel.c  | 7 +++
  4 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/datapath/linux/compat/ip6_gre.c b/datapath/linux/compat/ip6_gre.c
index 00dbefc9b099..182785273c6f 100644
--- a/datapath/linux/compat/ip6_gre.c
+++ b/datapath/linux/compat/ip6_gre.c
@@ -377,7 +377,7 @@ static struct ip6_tnl *ip6gre_tunnel_locate(struct net *net,
if (parms->name[0])
strlcpy(name, parms->name, IFNAMSIZ);
else
-   strcpy(name, "ip6gre%d");
+   strlcpy(name, "ovs-ip6gre%d", IFNAMSIZ);
  
  	dev = alloc_netdev(sizeof(*t), name, NET_NAME_UNKNOWN,

   ip6gre_tunnel_setup);
@@ -1712,7 +1712,8 @@ static int __net_init ip6gre_init_net(struct net *net)
struct ip6gre_net *ign = net_generic(net, ip6gre_net_id);
int err;
  
-	ign->fb_tunnel_dev = alloc_netdev(sizeof(struct ip6_tnl), "ip6gre0",

+   ign->fb_tunnel_dev = alloc_netdev(sizeof(struct ip6_tnl),
+ "ovs-ip6gre0",
  NET_NAME_UNKNOWN,
  ip6gre_tunnel_setup);
if (!ign->fb_tunnel_dev) {
diff --git a/datapath/linux/compat/ip6_tunnel.c 
b/datapath/linux/compat/ip6_tunnel.c
index 56fd8b4dd342..9f4bae7dd3d1 100644
--- a/datapath/linux/compat/ip6_tunnel.c
+++ b/datapath/linux/compat/ip6_tunnel.c
@@ -355,7 +355,7 @@ static struct ip6_tnl *ip6_tnl_create(struct net *net, 
struct __ip6_tnl_parm *p)
if (p->name[0])
strlcpy(name, p->name, IFNAMSIZ);
else
-   sprintf(name, "ip6tnl%%d");
+   strlcpy(name, "ovs-ip6tnl%d", IFNAMSIZ);
  
  	dev = alloc_netdev(sizeof(*t), name, NET_NAME_UNKNOWN,

   ip6_tnl_dev_setup);
@@ -1410,7 +1410,7 @@ ip6_tnl_parm_to_user(struct ip6_tnl_parm *u, const struct 
__ip6_tnl_parm *p)
   * %SIOCCHGTUNNEL: change tunnel parameters to those given
   * %SIOCDELTUNNEL: delete tunnel
   *
- *   The fallback device "ip6tnl0", created during module
+ *   The fallback device "ovs-ip6tnl0", created during module
   *   initialization, can be used for creating other tunnel devices.
   *
   * Return:
@@ -2093,7 +2093,7 @@ static int __net_init ip6_tnl_init_net(struct net *net)
ip6n->tnls[1] = ip6n->tnls_r_l;
  
  	err = -ENOMEM;

-   ip6n->fb_tnl_dev = alloc_netdev(sizeof(struct ip6_tnl), "ip6tnl0",
+   ip6n->fb_tnl_dev = alloc_netdev(sizeof(struct ip6_tnl), "ovs-ip6tnl0",
NET_NAME_UNKNOWN, ip6_tnl_dev_setup);
  
  	if (!ip6n->fb_tnl_dev)

diff --git a/datapath/linux/compat/ip_gre.c b/datapath/linux/compat/ip_gre.c
index 05132ba9494a..b7322c58e420 100644
--- a/datapath/linux/compat/ip_gre.c
+++ b/datapath/linux/compat/ip_gre.c
@@ -1463,7 +1463,7 @@ static struct pernet_operations erspan_net_ops = {
  
  static int __net_init ipgre_tap_init_net(struct net *net)

  {
-   return ip_tunnel_init_net(net, gre_tap_net_id, _tap_ops, 
"gretap0");
+   return ip_tunnel_init_net(net, gre_tap_net_id, _tap_ops, 
"ovs-gretap0");
  }
  
  static void __net_exit ipgre_tap_exit_net(struct net *net)

diff --git a/datapath/linux/compat/ip_tunnel.c 
b/datapath/linux/compat/ip_tunnel.c
index d16e60fbfef0..ae5d5a058663 100644
--- a/datapath/linux/compat/ip_tunnel.c
+++ b/datapath/linux/compat/ip_tunnel.c
@@ -130,12 +130,11 @@ static struct net_device *__ip_tunnel_create(struct net 
*net,
if (parms->name[0])
strlcpy(name, parms->name, IFNAMSIZ);
else {
-   if (strlen(ops->kind) > (IFNAMSIZ - 3)) {
+   err = snprintf(name, IFNAMSIZ - 3, "ovs-%s%%d", ops->kind);
+   if (err >= IFNAMSIZ - 3)
err = -E2BIG;
+   if (err < 0)
goto failed;
-   }
-   strlcpy(name, ops->kind, IFNAMSIZ);
-   strncat(name, "%d", 2);
}
  
  	ASSERT_RTNL();


Thanks Yifeng for all your work on this.

This looks OK but I'm not sure the additional protections against a 
device name being too long are
really needed.  I think in all cases the parms->name will be filled out 
since OVS is the only user.
Have you tested

Re: [ovs-dev] [PATCH net-next] net: fix return type of ndo_start_xmit function

2018-09-17 Thread David Miller 


Please don't do this.

The hard part of fixing this is not what you are doing, changing the
return type.

The hard part is fixing each and every function to actually return
values which are members of the netdev_tx_t enumeration.

Please fix each and every function properly.

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

[ovs-dev] [PATCH] ovn: Fix IPv6 DAD failure for child ports

2018-09-17 Thread nusiddiq 
From: Numan Siddique 

When a child vlan interface is created inside a VM, the below kernel message
is seen and IPv6 doesn't work on that interface.

[  138.000753] IPv6: vlan4: IPv6 duplicate address  detected!

When a child port sends a broadcast packet, OVN delivers the same
packet back to the child port (and hence the DAD check fails).
This is because 'MLF_ALLOW_LOOPBACK_BIT' is set in REG10 in table 0 when
the packet is received from any child port and table 'OFTABLE_CHECK_LOOPBACK'
doesn't drop the packet.

This patch fixes the issue by using a new register bit 
(MLF_NESTED_CONTAINER_BIT)
instead of 'MLF_ALLOW_LOOPBACK_BIT' and sets it in REG10 for the packets 
received
from child ports.

Signed-off-by: Numan Siddique 
---
 ovn/controller/ofctrl.c   | 29 -
 ovn/controller/ofctrl.h   |  5 +
 ovn/controller/physical.c | 38 --
 ovn/lib/logical-fields.h  |  4 
 tests/ovn.at  | 11 +++
 5 files changed, 72 insertions(+), 15 deletions(-)

diff --git a/ovn/controller/ofctrl.c b/ovn/controller/ofctrl.c
index 96c57f143..2f2b185ae 100644
--- a/ovn/controller/ofctrl.c
+++ b/ovn/controller/ofctrl.c
@@ -630,9 +630,11 @@ ofctrl_recv(const struct ofp_header *oh, enum ofptype type)
  *
  * The caller should initialize its own hmap to hold the flows. */
 void
-ofctrl_add_flow(struct hmap *desired_flows,
-uint8_t table_id, uint16_t priority, uint64_t cookie,
-const struct match *match, const struct ofpbuf *actions)
+ofctrl_check_and_add_flow(struct hmap *desired_flows,
+  uint8_t table_id, uint16_t priority, uint64_t cookie,
+  const struct match *match,
+  const struct ofpbuf *actions,
+  bool log_duplicate_flow)
 {
 struct ovn_flow *f = xmalloc(sizeof *f);
 f->table_id = table_id;
@@ -644,13 +646,14 @@ ofctrl_add_flow(struct hmap *desired_flows,
 f->cookie = cookie;
 
 if (ovn_flow_lookup(desired_flows, f)) {
-static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(5, 5);
-if (!VLOG_DROP_DBG()) {
-char *s = ovn_flow_to_string(f);
-VLOG_DBG("dropping duplicate flow: %s", s);
-free(s);
+if (log_duplicate_flow) {
+static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(5, 5);
+if (!VLOG_DROP_DBG()) {
+char *s = ovn_flow_to_string(f);
+VLOG_DBG("dropping duplicate flow: %s", s);
+free(s);
+}
 }
-
 ovn_flow_destroy(f);
 return;
 }
@@ -658,6 +661,14 @@ ofctrl_add_flow(struct hmap *desired_flows,
 hmap_insert(desired_flows, >hmap_node, f->hmap_node.hash);
 }
 
+void
+ofctrl_add_flow(struct hmap *desired_flows,
+uint8_t table_id, uint16_t priority, uint64_t cookie,
+const struct match *match, const struct ofpbuf *actions)
+{
+ofctrl_check_and_add_flow(desired_flows, table_id, priority, cookie,
+  match, actions, true);
+}
 
 /* ovn_flow. */
 
diff --git a/ovn/controller/ofctrl.h b/ovn/controller/ofctrl.h
index e3fc95b05..ae0cfa513 100644
--- a/ovn/controller/ofctrl.h
+++ b/ovn/controller/ofctrl.h
@@ -55,4 +55,9 @@ void ofctrl_add_flow(struct hmap *desired_flows, uint8_t 
table_id,
  uint16_t priority, uint64_t cookie,
  const struct match *, const struct ofpbuf *ofpacts);
 
+void ofctrl_check_and_add_flow(struct hmap *desired_flows, uint8_t table_id,
+   uint16_t priority, uint64_t cookie,
+   const struct match *,
+   const struct ofpbuf *ofpacts,
+   bool log_duplicate_flow);
 #endif /* ovn/ofctrl.h */
diff --git a/ovn/controller/physical.c b/ovn/controller/physical.c
index c38d7b09f..d781ae459 100644
--- a/ovn/controller/physical.c
+++ b/ovn/controller/physical.c
@@ -189,7 +189,8 @@ get_zone_ids(const struct sbrec_port_binding *binding,
 
 static void
 put_local_common_flows(uint32_t dp_key, uint32_t port_key,
-   bool nested_container, const struct zone_ids *zone_ids,
+   uint32_t parent_port_key,
+   const struct zone_ids *zone_ids,
struct ofpbuf *ofpacts_p, struct hmap *flow_table)
 {
 struct match match;
@@ -253,7 +254,7 @@ put_local_common_flows(uint32_t dp_key, uint32_t port_key,
 ofpbuf_clear(ofpacts_p);
 match_set_metadata(, htonll(dp_key));
 match_set_reg(, MFF_LOG_OUTPORT - MFF_REG0, port_key);
-if (!nested_container) {
+if (!parent_port_key) {
 match_set_reg_masked(, MFF_LOG_FLAGS - MFF_REG0,
  MLF_ALLOW_LOOPBACK, MLF_ALLOW_LOOPBACK);
 }
@@ -264,6 +265,25 @@ put_local_common_flows(uint32_t dp_key, uint32_t port_key,
 put_stack(MFF_IN_PORT,

[ovs-dev] [PATCH] dpif-netdev: Fix "execute" packet length check.

2018-09-17 Thread wangyunjian 
From: Yunjian Wang 

The length check is wrong for immediate arguments to "execute" packet.
The ethernet header length should be considered.

Signed-off-by: Yunjian Wang 
---
 lib/dpif-netdev.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index 9fb82cc..6522f27 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -3632,9 +3632,11 @@ dpif_netdev_execute(struct dpif *dpif, struct 
dpif_execute *execute)
 struct dp_netdev *dp = get_dp_netdev(dpif);
 struct dp_netdev_pmd_thread *pmd;
 struct dp_packet_batch pp;
+int n_vlan = flow_count_vlan_headers(execute->flow);
 
 if (dp_packet_size(execute->packet) < ETH_HEADER_LEN ||
-dp_packet_size(execute->packet) > UINT16_MAX) {
+dp_packet_size(execute->packet) > UINT16_MAX +
+ETH_HEADER_LEN + VLAN_HEADER_LEN * n_vlan) {
 return EINVAL;
 }
 
-- 
1.8.3.1


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