Re: [ovs-dev] [PATCH v5 00/21] Daemon mode for ovn-nbctl

[Ben Pfaff]

On Thu, Jul 19, 2018 at 03:51:05PM +0200, Jakub Sitnicki wrote:
> This series extends ovn-nbctl tool with support for the daemon mode, where
> ovn-nbctl acts a long-lived process that accepts commands over a UNIX socket.
> The daemon can be started the same way as any other OVS/OVN server:
> 
>   ovn-nbctl --detach --pidfile --log-file

Thanks a lot.  I applied this series to master.

Would you mind sending an additional patch to add an appropriate item to
NEWS?

I'm going to play with some ideas for tests.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] ofproto: Return error codes for Rule insertions

[Aravind Prasad]

> Currently, rule_insert() API does not have return value. There are some
possible
> scenarios where rule insertions can fail at run-time even though the
static
> checks during rule_construct() had passed previously.
> Some possible scenarios for failure of rule insertions:
> **) Rule insertions can fail dynamically in Hybrid mode (both Openflow and
> Normal switch functioning coexist) where the CAM space could get suddenly
> filled up by Normal switch functioning and Openflow gets devoid of
> available space.
> **) Some deployments could have separate independent layers for HW rule
> insertions and application layer to interact with OVS. HW layer
> could face any dynamic issue during rule handling which application could
> not have predicted/captured in rule-construction phase.
> Rule-insert errors for bundles are handled too in this pull-request.
>
> Signed-off-by: Aravind Prasad S 

>Which switches does this help?

>Hi Ben,
>These type of errors are possible in actual Hardware implementations
>of OVS. It is possible that ofproto and netdev providers be
>implemented for an actual HW/NPU. Usually, in such cases, in the rule
>construct phase, all the static checks like verifying the qualifiers/
>actions, CAM full checks could be done and the other related
>verifications.
>But during the rule insert phase, it is possible that
>the rule insertion may get failed in HW (runtime errors,
>HW errors and so on). Also, since HW switches may support Hybrid
>mode (coexistence of Normal and Openflow functioning), the
>possibility of this issue could be even more. Further, when
>rule-insertion fails, it results in a stale state where the
>Controller and Switch Flow-DB differ.
>Hence, we need a way to rollback for rule-insert phase also.
>Kindly let me know your views.
>And sorry for re-sending the review requests many times over.
>Will avoid in future.

Hi Ben/All,

Kindly let me know your views.


On Sat, Jul 21, 2018 at 9:22 AM, Aravind Prasad  wrote:

>
> > Currently, rule_insert() API does not have return value. There are some 
> > possible
> > scenarios where rule insertions can fail at run-time even though the static
> > checks during rule_construct() had passed previously.
> > Some possible scenarios for failure of rule insertions:
> > **) Rule insertions can fail dynamically in Hybrid mode (both Openflow and
> > Normal switch functioning coexist) where the CAM space could get suddenly
> > filled up by Normal switch functioning and Openflow gets devoid of
> > available space.
> > **) Some deployments could have separate independent layers for HW rule
> > insertions and application layer to interact with OVS. HW layer
> > could face any dynamic issue during rule handling which application could
> > not have predicted/captured in rule-construction phase.
> > Rule-insert errors for bundles are handled too in this pull-request.
> >
> > Signed-off-by: Aravind Prasad S 
>
> >Which switches does this help?
>
> Hi Ben, These type of errors are possible in actual Hardware
> implementations of OVS. It is possible that ofproto and netdev providers be
> implemented for an actual HW/NPU. Usually, in such cases, in the rule
> construct phase, all the static checks like verifying the qualifiers/
> actions, CAM full checks could be done and the other related verifications.
> But during the rule insert phase, it is possible that the rule insertion
> may get failed in HW (runtime errors, HW errors and so on). Also, since HW
> switches may support Hybrid mode (coexistence of Normal and Openflow
> functioning), the possibility of this issue could be even more. Further,
> when rule-insertion fails, it results in a stale state where the Controller
> and Switch Flow-DB differ. Hence, we need a way to rollback for rule-insert
> phase also. Kindly let me know your views. And sorry for re-sending the
> review requests many times over. Will avoid in future.
>
>
> On Fri, Jul 20, 2018 at 10:20 PM, Ben Pfaff  wrote:
>
> On Thu, Jul 12, 2018 at 06:04:47PM +, Aravind Prasad S wrote:
>> > Currently, rule_insert() API does not have return value. There are some
>> possible
>> > scenarios where rule insertions can fail at run-time even though the
>> static
>> > checks during rule_construct() had passed previously.
>> > Some possible scenarios for failure of rule insertions:
>> > **) Rule insertions can fail dynamically in Hybrid mode (both Openflow
>> and
>> > Normal switch functioning coexist) where the CAM space could get
>> suddenly
>> > filled up by Normal switch functioning and Openflow gets devoid of
>> > available space.
>> > **) Some deployments could have separate independent layers for HW rule
>> > insertions and application layer to interact with OVS. HW layer
>> > could face any dynamic issue during rule handling which application
>> could
>> > not have predicted/captured in rule-construction phase.
>> > Rule-insert errors for bundles are handled too in this pull-request.
>> >
>> > Signed-off-by: Aravind Prasad S 
>>
>> Which 

Re: [ovs-dev] [PATCH v5 08/14] dp-packet: Handle multi-seg mbufs in resize__().

[Darrell Ball]

On Fri, Jul 20, 2018 at 10:09 AM, Lam, Tiago  wrote:

> On 18/07/2018 23:53, Darrell Ball wrote:
> > sorry, several distractions delayed response.
> >
> > On Mon, Jul 16, 2018 at 1:37 AM, Lam, Tiago  > > wrote:
> >
> > On 13/07/2018 18:54, Darrell Ball wrote:
> > > Thanks for the patch.
> > >
> > > A few queries inline.
> > >
> >
> > Hi Darrell,
> >
> > Thanks for your inputs. I've replied in-line as well.
> >
> > > On Wed, Jul 11, 2018 at 11:23 AM, Tiago Lam  
> > > >> wrote:
> > >
> > > When enabled with DPDK OvS relies on mbufs allocated by
> mempools to
> > > receive and output data on DPDK ports. Until now, each OvS
> dp_packet has
> > > had only one mbuf associated, which is allocated with the
> maximum
> > > possible size, taking the MTU into account. This approach,
> however,
> > > doesn't allow us to increase the allocated size in an mbuf, if
> needed,
> > > since an mbuf is allocated and initialised upon mempool
> creation. Thus,
> > > in the current implementatin this is dealt with by calling
> > > OVS_NOT_REACHED() and terminating OvS.
> > >
> > > To avoid this, and allow the (already) allocated space to be
> better
> > > used, dp_packet_resize__() now tries to use the available
> room, both the
> > > tailroom and the headroom, to make enough space for the new
> data. Since
> > > this happens for packets of source DPBUF_DPDK, the
> single-segment mbuf
> > > case mentioned above is also covered by this new aproach in
> resize__().
> > >
> > > Signed-off-by: Tiago Lam  tiago@intel.com>
> > > >>
> > > Acked-by: Eelco Chaudron  > 
> > > >>
> > > ---
> > >  lib/dp-packet.c | 48
> > ++--
> > >  1 file changed, 46 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/lib/dp-packet.c b/lib/dp-packet.c
> > > index d6e19eb..87af459 100644
> > > --- a/lib/dp-packet.c
> > > +++ b/lib/dp-packet.c
> > > @@ -237,9 +237,51 @@ dp_packet_resize__(struct dp_packet *b,
> > size_t
> > > new_headroom, size_t new_tailroom
> > >  new_allocated = new_headroom + dp_packet_size(b) +
> > new_tailroom;
> > >
> > >  switch (b->source) {
> > > +/* When resizing mbufs, both a single mbuf and
> multi-segment
> > > mbufs (where
> > > + * data is not contigously held in memory), both the
> headroom
> > > and the
> > > + * tailroom available will be used to make more space for
> > where
> > > data needs
> > > + * to be inserted. I.e if there's not enough headroom,
> > data may
> > > be shifted
> > > + * right if there's enough tailroom.
> > > + * However, this is not bulletproof and in some cases the
> > space
> > > available
> > > + * won't be enough - in those cases, an error should be
> > > returned and the
> > > + * packet dropped. */
> > >  case DPBUF_DPDK:
> > > -OVS_NOT_REACHED();
> > >
> > >
> > > Previously, it was a coding error to call this function for a DPDK
> > mbuf
> > > case, which is pretty
> > > clear. But with this patch, presumably that is not longer the case
> and
> > > the calling the API is
> > > now ok for DPDK mbufs.
> > >
> >
> > As it stands, it will still be an error to call dp_packet_resize__()
> for
> > any DPDK packet, or by extension any of the other functions that call
> > it, such as dp_packet_prealloc_tailroom() and
> > dp_packet_prealloc_headroom().
> >
> >
> >
> > yep, the existing code fails in a very clear way; i.e. whenever it is
> > called for a dpdk packet.
> > So the user would need to handle in some other way, which is not being
> > done today, I know.
> >
> >
> >
> > This patch only tries to alleviate that
> > by accommodating space from the headroom or tailroom, if possible,
> and
> > create just enough space for the new data.
> >
> >
> > The new code will fail is some yet undefined way, occasionally working
> > and failing
> > in the "other" cases.
> >
> >
> >
> > My preferred approach would
> > be to return an error if not possible, but since the API doesn't deal
> > with errors as is, the previous behavior of manually asserting was
> left
> > as is. As reported in [1] (I comment more on that below), the
> behavior
> >
> > of manually asserting can lead to undesired behavior in some use
> cases.
> >
> >
> >
> > I am familiar 

Re: [ovs-dev] [PATCH v5 08/14] dp-packet: Handle multi-seg mbufs in resize__().

[Darrell Ball]

On Fri, Jul 20, 2018 at 10:10 AM, Lam, Tiago  wrote:

> On 19/07/2018 00:02, Darrell Ball wrote:
> >
> >
> > On Tue, Jul 17, 2018 at 12:59 AM, Lam, Tiago  > > wrote:
> >
> > On 16/07/2018 09:37, Lam, Tiago wrote:
> > > On 13/07/2018 18:54, Darrell Ball wrote:
> > >> Thanks for the patch.
> > >>
> > >> A few queries inline.
> > >>
> > >
> > > Hi Darrell,
> > >
> > > Thanks for your inputs. I've replied in-line as well.
> > >
> > >> On Wed, Jul 11, 2018 at 11:23 AM, Tiago Lam  > 
> > >> >> wrote:
> > >>
> > >> When enabled with DPDK OvS relies on mbufs allocated by
> > mempools to
> > >> receive and output data on DPDK ports. Until now, each OvS
> > dp_packet has
> > >> had only one mbuf associated, which is allocated with the
> maximum
> > >> possible size, taking the MTU into account. This approach,
> > however,
> > >> doesn't allow us to increase the allocated size in an mbuf,
> > if needed,
> > >> since an mbuf is allocated and initialised upon mempool
> > creation. Thus,
> > >> in the current implementatin this is dealt with by calling
> > >> OVS_NOT_REACHED() and terminating OvS.
> > >>
> > >> To avoid this, and allow the (already) allocated space to be
> > better
> > >> used, dp_packet_resize__() now tries to use the available
> > room, both the
> > >> tailroom and the headroom, to make enough space for the new
> > data. Since
> > >> this happens for packets of source DPBUF_DPDK, the
> > single-segment mbuf
> > >> case mentioned above is also covered by this new aproach in
> > resize__().
> > >>
> > >> Signed-off-by: Tiago Lam  > 
> > >> >>
> > >> Acked-by: Eelco Chaudron  > 
> > >> >>
> > >> ---
> > >>  lib/dp-packet.c | 48
> > ++--
> > >>  1 file changed, 46 insertions(+), 2 deletions(-)
> > >>
> > >> diff --git a/lib/dp-packet.c b/lib/dp-packet.c
> > >> index d6e19eb..87af459 100644
> > >> --- a/lib/dp-packet.c
> > >> +++ b/lib/dp-packet.c
> > >> @@ -237,9 +237,51 @@ dp_packet_resize__(struct dp_packet *b,
> > size_t
> > >> new_headroom, size_t new_tailroom
> > >>  new_allocated = new_headroom + dp_packet_size(b) +
> > new_tailroom;
> > >>
> > >>  switch (b->source) {
> > >> +/* When resizing mbufs, both a single mbuf and
> multi-segment
> > >> mbufs (where
> > >> + * data is not contigously held in memory), both the
> > headroom
> > >> and the
> > >> + * tailroom available will be used to make more space
> > for where
> > >> data needs
> > >> + * to be inserted. I.e if there's not enough headroom,
> > data may
> > >> be shifted
> > >> + * right if there's enough tailroom.
> > >> + * However, this is not bulletproof and in some cases
> > the space
> > >> available
> > >> + * won't be enough - in those cases, an error should be
> > >> returned and the
> > >> + * packet dropped. */
> > >>  case DPBUF_DPDK:
> > >> -OVS_NOT_REACHED();
> > >>
> > >>
> > >> Previously, it was a coding error to call this function for a
> > DPDK mbuf
> > >> case, which is pretty
> > >> clear. But with this patch, presumably that is not longer the
> > case and
> > >> the calling the API is
> > >> now ok for DPDK mbufs.
> > >>
> > >
> > > As it stands, it will still be an error to call
> > dp_packet_resize__() for
> > > any DPDK packet, or by extension any of the other functions that
> call
> > > it, such as dp_packet_prealloc_tailroom() and
> > > dp_packet_prealloc_headroom(). This patch only tries to alleviate
> that
> > > by accommodating space from the headroom or tailroom, if possible,
> and
> > > create just enough space for the new data. My preferred approach
> would
> > > be to return an error if not possible, but since the API doesn't
> deal
> > > with errors as is, the previous behavior of manually asserting was
> > left
> > > as is. As reported in [1] (I comment more on that below), the
> behavior
> > > of manually asserting can lead to undesired behavior in some use
> > cases.
> > >
> > >>
> > >>
> > >> +{
> > >> +size_t miss_len;
> > >> +
> > >> +if (new_headroom == dp_packet_headroom(b)) {

Re: [ovs-dev] [PATCH 10/11] ovn-nbctl: Remove pointless "return; " at ends of functions.

[Ben Pfaff]

On Tue, Jul 17, 2018 at 03:34:14PM +0200, Jakub Sitnicki wrote:
> Fix fall-out from applying a semantic patch that converts ctl_fatal()
> calls to use ctl_error().
> 
> Signed-off-by: Jakub Sitnicki 

Oh, you fixed that up later ;-).  Ha, I'll revert it to your way
instead, never mind.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 08/11] ovn-nbctl: Propagate error thru the context.

[Ben Pfaff]

On Tue, Jul 17, 2018 at 03:34:12PM +0200, Jakub Sitnicki wrote:
> Instead of dying let the main loop handle the error.
> This will allow us to report errors when running in daemon mode.
> 
> This is a result of applying the following semantic patch:
> 
> @@
> identifier F;
> identifier C;
> identifier E;
> @@
>   static void F(struct ctl_context *C) {
> <...
>   if (E) {
> - ctl_fatal("%s", E);
> + C->error = E;
> + return;
>   }
> ...>
>   }
> 
> Signed-off-by: Jakub Sitnicki 

Thanks.

I adjusted this to change a couple of instances of:

return;
}

by deleting the "return;".
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 08/11] ovn-nbctl: Propagate error thru the context.

[Ben Pfaff]

On Tue, Jul 17, 2018 at 03:34:12PM +0200, Jakub Sitnicki wrote:
> Instead of dying let the main loop handle the error.
> This will allow us to report errors when running in daemon mode.
> 
> This is a result of applying the following semantic patch:
> 
> @@
> identifier F;
> identifier C;
> identifier E;
> @@
>   static void F(struct ctl_context *C) {
> <...
>   if (E) {
> - ctl_fatal("%s", E);
> + C->error = E;
> + return;
>   }
> ...>
>   }
> 
> Signed-off-by: Jakub Sitnicki 

It's too bad that this generates code like this:

 char *error = ls_by_name_or_uuid(ctx, ctx->argv[1], false, );
 if (error) {
ctx->error = error;
return;
 }

instead of the simpler:

 ctx->error = ls_by_name_or_uuid(ctx, ctx->argv[1], false, );
 if (ctx->error) {
return;
 }

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

Re: [ovs-dev] [PATCH 06/11] ovn-nbctl: Don't die in parse_direction().

[Ben Pfaff]

On Tue, Jul 17, 2018 at 03:34:10PM +0200, Jakub Sitnicki wrote:
> Let the caller handle the error. This prepares us for reporting errors
> in daemon mode.
> 
> Signed-off-by: Jakub Sitnicki 

I got a lot of "possibly uninitialized" warnings from GCC for this one:

../ovn/utilities/ovn-nbctl.c: In function ‘nbctl_qos_del’:
../ovn/utilities/ovn-nbctl.c:2068:17: error: ‘direction’ may be used 
uninitialized in this function [-Werror=maybe-uninitialized]
 if (strcmp(direction, ls->qos_rules[i]->direction)) {
 ^~
../ovn/utilities/ovn-nbctl.c: In function ‘nbctl_acl_add’:
../ovn/utilities/ovn-nbctl.c:1739:5: error: ‘direction’ may be used 
uninitialized in this function [-Werror=maybe-uninitialized]
 nbrec_acl_set_direction(acl, direction);
 ^~~
../ovn/utilities/ovn-nbctl.c: In function ‘nbctl_acl_del’:
../ovn/utilities/ovn-nbctl.c:1829:17: error: ‘direction’ may be used 
uninitialized in this function [-Werror=maybe-uninitialized]
 if (strcmp(direction, acls[i]->direction)) {
 ^
../ovn/utilities/ovn-nbctl.c: In function ‘nbctl_qos_add’:
../ovn/utilities/ovn-nbctl.c:1994:5: error: ‘direction’ may be used 
uninitialized in this function [-Werror=maybe-uninitialized]
 nbrec_qos_set_direction(qos, direction);
 ^~~
../ovn/utilities/ovn-nbctl.c: At top level:

I think it's wrong but the following incremental solved it so I folded
it in:

diff --git a/ovn/utilities/ovn-nbctl.c b/ovn/utilities/ovn-nbctl.c
index c18fa28256af..a4a533740cb9 100644
--- a/ovn/utilities/ovn-nbctl.c
+++ b/ovn/utilities/ovn-nbctl.c
@@ -1680,6 +1680,7 @@ parse_direction(const char *arg, const char **direction_p)
 } else if (arg[0] == 'f') {
 *direction_p = "from-lport";
 } else {
+*direction_p = NULL;
 return xasprintf("%s: direction must be \"to-lport\" or "
  "\"from-lport\"", arg);
 }

Thanks,

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

Re: [ovs-dev] [PATCH] netlink-conntrack: undef the correct macro

[Yi-Hung Wei]

On Mon, Jul 23, 2018 at 1:40 PM, Aaron Conole  wrote:
> Fixes: 6830a0c0e6bf ("netlink-conntrack: New module.")
> Cc: Daniele Di Proietto 
> Signed-off-by: Aaron Conole 
> ---
>  lib/netlink-conntrack.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/netlink-conntrack.c b/lib/netlink-conntrack.c
> index e5a5fc118..42be1d9ce 100644
> --- a/lib/netlink-conntrack.c
> +++ b/lib/netlink-conntrack.c
> @@ -660,7 +660,7 @@ ip_ct_tcp_flags_to_dpif(uint8_t flags)
>  #define CT_DPIF_TCP_FLAG(FLAG) \
>  ret |= (flags & IP_CT_TCP_FLAG_##FLAG) ? CT_DPIF_TCPF_##FLAG : 0;
>  CT_DPIF_TCP_FLAGS
> -#undef CT_DPIF_STATUS_FLAG
> +#undef CT_DPIF_TCP_FLAG
>  return ret;
>  #endif
>  }
> --
Thanks for the fix.

Acked-by: Yi-Hung Wei 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] The “overlay” mode issue while setting up OVS with DPDK

[Guru Shetty]

Yes.

On 23 July 2018 at 13:43, Sandeep Adapala 
wrote:

> So you are saying just do the overlay part in this doc ?
> http://docs.openvswitch.org/en/latest/howto/docker/#the-overlay-mode
>
> On Mon, Jul 23, 2018 at 4:35 PM, Guru Shetty  wrote:
>
>> May I suggest that you get OVN working with containers without DPDK
>> first? Once you are confident about what needs to be done for OVN, you can
>> concentrate more on DPDK.
>>
>> On 23 July 2018 at 13:15, Sandeep Adapala 
>> wrote:
>>
>>> I have configured the grub as
>>>
>>> GRUB_CMDLINE_LINUX_DEFAULT="default_hugepagesz=1G hugepagesz=1G 
>>> hugepages=16 hugepagesz=2M hugepages=2048 iommu=pt intel_iommu=on"
>>>
>>>
>>> I didn't isolate any cores so if I want to use core 2 or 3 what will be the 
>>> dpdk-lcore-mask and pod-cpu-mask?
>>>
>>>
>>> On Mon, Jul 23, 2018 at 4:11 PM, Sandeep Adapala <
>>> sandeepadapal...@gmail.com> wrote:
>>>
 I have tried that already Guru but I got the same error always. Let me
 ask one more question.

 What do I need to configure here?

 sudo ovs-vsctl -no-wait set Open_vSwitch .
 other_config:dpdk-lcore-mask=0xfbe.
 sudo ovs-vsctl -no-wait set Open_vSwitch .
 other_config:dpdk-socket-mem="1024,1024"
 sudo ovs-vsctl set Open_vSwitch . other_config:pmd-cpu-mask=0x82


 I am very new to ovs so I am still learning things. So can you explain
 me what I should configure in lcore-mask and cpu-mask

 I have a 28 core with 10G intel NIC's

 Regards
 Sandeep

 On Mon, Jul 23, 2018 at 3:49 PM, Guru Shetty  wrote:

> 1. Use the same IP address for both CENTRAL_IP and LOCAL_IP. And this
> should be the IP of your host.
> 2. ENCAP_TYPE="geneve".
>
> On 23 July 2018 at 12:41, Sandeep Adapala 
> wrote:
>
>> Hello All,
>>
>> I am trying to use this doc to setup the containers using OVS-DPDK (
>> https://software.intel.com/en-us/articles/using-docker-conta
>> iners-with-open-vswitch-and-dpdk-on-ubuntu-1710)
>> but when I try to configure the ovs on overlay mode I am little
>> confused on
>> this configuration. I don't have a remote server I want everything to
>> be
>> installed in same server. so can you please help me out what should I
>> remove and replace in the below config
>>
>> ovs-vsctl set Open_vSwitch . \
>> external_ids:ovn-remote="tcp:$CENTRAL_IP:6642" \
>> external_ids:ovn-nb="tcp:$CENTRAL_IP:6641" \
>> external_ids:ovn-encap-ip=$LOCAL_IP \
>> external_ids:ovn-encap-type="$ENCAP_TYPE"
>>
>>
>> like what is CENTRAL_IP? ENCAP_TYPE and all?
>>
>> Regards,
>> Sandeep
>> ___
>> dev mailing list
>> d...@openvswitch.org
>> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>>
>
>

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

Re: [ovs-dev] The “overlay” mode issue while setting up OVS with DPDK

[Sandeep Adapala]

So you are saying just do the overlay part in this doc ?
http://docs.openvswitch.org/en/latest/howto/docker/#the-overlay-mode

On Mon, Jul 23, 2018 at 4:35 PM, Guru Shetty  wrote:

> May I suggest that you get OVN working with containers without DPDK first?
> Once you are confident about what needs to be done for OVN, you can
> concentrate more on DPDK.
>
> On 23 July 2018 at 13:15, Sandeep Adapala 
> wrote:
>
>> I have configured the grub as
>>
>> GRUB_CMDLINE_LINUX_DEFAULT="default_hugepagesz=1G hugepagesz=1G hugepages=16 
>> hugepagesz=2M hugepages=2048 iommu=pt intel_iommu=on"
>>
>>
>> I didn't isolate any cores so if I want to use core 2 or 3 what will be the 
>> dpdk-lcore-mask and pod-cpu-mask?
>>
>>
>> On Mon, Jul 23, 2018 at 4:11 PM, Sandeep Adapala <
>> sandeepadapal...@gmail.com> wrote:
>>
>>> I have tried that already Guru but I got the same error always. Let me
>>> ask one more question.
>>>
>>> What do I need to configure here?
>>>
>>> sudo ovs-vsctl -no-wait set Open_vSwitch . other_config:dpdk-lcore-mask=0
>>> xfbe.
>>> sudo ovs-vsctl -no-wait set Open_vSwitch . other_config:dpdk-socket-mem="
>>> 1024,1024"
>>> sudo ovs-vsctl set Open_vSwitch . other_config:pmd-cpu-mask=0x82
>>>
>>>
>>> I am very new to ovs so I am still learning things. So can you explain
>>> me what I should configure in lcore-mask and cpu-mask
>>>
>>> I have a 28 core with 10G intel NIC's
>>>
>>> Regards
>>> Sandeep
>>>
>>> On Mon, Jul 23, 2018 at 3:49 PM, Guru Shetty  wrote:
>>>
 1. Use the same IP address for both CENTRAL_IP and LOCAL_IP. And this
 should be the IP of your host.
 2. ENCAP_TYPE="geneve".

 On 23 July 2018 at 12:41, Sandeep Adapala 
 wrote:

> Hello All,
>
> I am trying to use this doc to setup the containers using OVS-DPDK (
> https://software.intel.com/en-us/articles/using-docker-conta
> iners-with-open-vswitch-and-dpdk-on-ubuntu-1710)
> but when I try to configure the ovs on overlay mode I am little
> confused on
> this configuration. I don't have a remote server I want everything to
> be
> installed in same server. so can you please help me out what should I
> remove and replace in the below config
>
> ovs-vsctl set Open_vSwitch . \
> external_ids:ovn-remote="tcp:$CENTRAL_IP:6642" \
> external_ids:ovn-nb="tcp:$CENTRAL_IP:6641" \
> external_ids:ovn-encap-ip=$LOCAL_IP \
> external_ids:ovn-encap-type="$ENCAP_TYPE"
>
>
> like what is CENTRAL_IP? ENCAP_TYPE and all?
>
> Regards,
> Sandeep
> ___
> 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] [PATCH] netlink-conntrack: undef the correct macro

[Aaron Conole]

Fixes: 6830a0c0e6bf ("netlink-conntrack: New module.")
Cc: Daniele Di Proietto 
Signed-off-by: Aaron Conole 
---
 lib/netlink-conntrack.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/netlink-conntrack.c b/lib/netlink-conntrack.c
index e5a5fc118..42be1d9ce 100644
--- a/lib/netlink-conntrack.c
+++ b/lib/netlink-conntrack.c
@@ -660,7 +660,7 @@ ip_ct_tcp_flags_to_dpif(uint8_t flags)
 #define CT_DPIF_TCP_FLAG(FLAG) \
 ret |= (flags & IP_CT_TCP_FLAG_##FLAG) ? CT_DPIF_TCPF_##FLAG : 0;
 CT_DPIF_TCP_FLAGS
-#undef CT_DPIF_STATUS_FLAG
+#undef CT_DPIF_TCP_FLAG
 return ret;
 #endif
 }
-- 
2.14.3

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

Re: [ovs-dev] The “overlay” mode issue while setting up OVS with DPDK

[Guru Shetty]

May I suggest that you get OVN working with containers without DPDK first?
Once you are confident about what needs to be done for OVN, you can
concentrate more on DPDK.

On 23 July 2018 at 13:15, Sandeep Adapala 
wrote:

> I have configured the grub as
>
> GRUB_CMDLINE_LINUX_DEFAULT="default_hugepagesz=1G hugepagesz=1G hugepages=16 
> hugepagesz=2M hugepages=2048 iommu=pt intel_iommu=on"
>
>
> I didn't isolate any cores so if I want to use core 2 or 3 what will be the 
> dpdk-lcore-mask and pod-cpu-mask?
>
>
> On Mon, Jul 23, 2018 at 4:11 PM, Sandeep Adapala <
> sandeepadapal...@gmail.com> wrote:
>
>> I have tried that already Guru but I got the same error always. Let me
>> ask one more question.
>>
>> What do I need to configure here?
>>
>> sudo ovs-vsctl -no-wait set Open_vSwitch . other_config:dpdk-lcore-mask=0
>> xfbe.
>> sudo ovs-vsctl -no-wait set Open_vSwitch . other_config:dpdk-socket-mem="
>> 1024,1024"
>> sudo ovs-vsctl set Open_vSwitch . other_config:pmd-cpu-mask=0x82
>>
>>
>> I am very new to ovs so I am still learning things. So can you explain me
>> what I should configure in lcore-mask and cpu-mask
>>
>> I have a 28 core with 10G intel NIC's
>>
>> Regards
>> Sandeep
>>
>> On Mon, Jul 23, 2018 at 3:49 PM, Guru Shetty  wrote:
>>
>>> 1. Use the same IP address for both CENTRAL_IP and LOCAL_IP. And this
>>> should be the IP of your host.
>>> 2. ENCAP_TYPE="geneve".
>>>
>>> On 23 July 2018 at 12:41, Sandeep Adapala 
>>> wrote:
>>>
 Hello All,

 I am trying to use this doc to setup the containers using OVS-DPDK (
 https://software.intel.com/en-us/articles/using-docker-conta
 iners-with-open-vswitch-and-dpdk-on-ubuntu-1710)
 but when I try to configure the ovs on overlay mode I am little
 confused on
 this configuration. I don't have a remote server I want everything to be
 installed in same server. so can you please help me out what should I
 remove and replace in the below config

 ovs-vsctl set Open_vSwitch . \
 external_ids:ovn-remote="tcp:$CENTRAL_IP:6642" \
 external_ids:ovn-nb="tcp:$CENTRAL_IP:6641" \
 external_ids:ovn-encap-ip=$LOCAL_IP \
 external_ids:ovn-encap-type="$ENCAP_TYPE"


 like what is CENTRAL_IP? ENCAP_TYPE and all?

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

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

Re: [ovs-dev] The “overlay” mode issue while setting up OVS with DPDK

[Sandeep Adapala]

I have configured the grub as

GRUB_CMDLINE_LINUX_DEFAULT="default_hugepagesz=1G hugepagesz=1G
hugepages=16 hugepagesz=2M hugepages=2048 iommu=pt intel_iommu=on"


I didn't isolate any cores so if I want to use core 2 or 3 what will
be the dpdk-lcore-mask and pod-cpu-mask?


On Mon, Jul 23, 2018 at 4:11 PM, Sandeep Adapala  wrote:

> I have tried that already Guru but I got the same error always. Let me ask
> one more question.
>
> What do I need to configure here?
>
> sudo ovs-vsctl -no-wait set Open_vSwitch . other_config:dpdk-lcore-mask=0
> xfbe.
> sudo ovs-vsctl -no-wait set Open_vSwitch . other_config:dpdk-socket-mem="
> 1024,1024"
> sudo ovs-vsctl set Open_vSwitch . other_config:pmd-cpu-mask=0x82
>
>
> I am very new to ovs so I am still learning things. So can you explain me
> what I should configure in lcore-mask and cpu-mask
>
> I have a 28 core with 10G intel NIC's
>
> Regards
> Sandeep
>
> On Mon, Jul 23, 2018 at 3:49 PM, Guru Shetty  wrote:
>
>> 1. Use the same IP address for both CENTRAL_IP and LOCAL_IP. And this
>> should be the IP of your host.
>> 2. ENCAP_TYPE="geneve".
>>
>> On 23 July 2018 at 12:41, Sandeep Adapala 
>> wrote:
>>
>>> Hello All,
>>>
>>> I am trying to use this doc to setup the containers using OVS-DPDK (
>>> https://software.intel.com/en-us/articles/using-docker-conta
>>> iners-with-open-vswitch-and-dpdk-on-ubuntu-1710)
>>> but when I try to configure the ovs on overlay mode I am little confused
>>> on
>>> this configuration. I don't have a remote server I want everything to be
>>> installed in same server. so can you please help me out what should I
>>> remove and replace in the below config
>>>
>>> ovs-vsctl set Open_vSwitch . \
>>> external_ids:ovn-remote="tcp:$CENTRAL_IP:6642" \
>>> external_ids:ovn-nb="tcp:$CENTRAL_IP:6641" \
>>> external_ids:ovn-encap-ip=$LOCAL_IP \
>>> external_ids:ovn-encap-type="$ENCAP_TYPE"
>>>
>>>
>>> like what is CENTRAL_IP? ENCAP_TYPE and all?
>>>
>>> Regards,
>>> Sandeep
>>> ___
>>> dev mailing list
>>> d...@openvswitch.org
>>> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>>>
>>
>>
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] The “overlay” mode issue while setting up OVS with DPDK

[Sandeep Adapala]

I have tried that already Guru but I got the same error always. Let me ask
one more question.

What do I need to configure here?

sudo ovs-vsctl -no-wait set Open_vSwitch . other_config:dpdk-lcore-mask=
0xfbe.
sudo ovs-vsctl -no-wait set Open_vSwitch . other_config:dpdk-socket-mem="
1024,1024"
sudo ovs-vsctl set Open_vSwitch . other_config:pmd-cpu-mask=0x82


I am very new to ovs so I am still learning things. So can you explain me
what I should configure in lcore-mask and cpu-mask

I have a 28 core with 10G intel NIC's

Regards
Sandeep

On Mon, Jul 23, 2018 at 3:49 PM, Guru Shetty  wrote:

> 1. Use the same IP address for both CENTRAL_IP and LOCAL_IP. And this
> should be the IP of your host.
> 2. ENCAP_TYPE="geneve".
>
> On 23 July 2018 at 12:41, Sandeep Adapala 
> wrote:
>
>> Hello All,
>>
>> I am trying to use this doc to setup the containers using OVS-DPDK (
>> https://software.intel.com/en-us/articles/using-docker-conta
>> iners-with-open-vswitch-and-dpdk-on-ubuntu-1710)
>> but when I try to configure the ovs on overlay mode I am little confused
>> on
>> this configuration. I don't have a remote server I want everything to be
>> installed in same server. so can you please help me out what should I
>> remove and replace in the below config
>>
>> ovs-vsctl set Open_vSwitch . \
>> external_ids:ovn-remote="tcp:$CENTRAL_IP:6642" \
>> external_ids:ovn-nb="tcp:$CENTRAL_IP:6641" \
>> external_ids:ovn-encap-ip=$LOCAL_IP \
>> external_ids:ovn-encap-type="$ENCAP_TYPE"
>>
>>
>> like what is CENTRAL_IP? ENCAP_TYPE and all?
>>
>> Regards,
>> Sandeep
>> ___
>> dev mailing list
>> d...@openvswitch.org
>> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>>
>
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] The “overlay” mode issue while setting up OVS with DPDK

[Guru Shetty]

1. Use the same IP address for both CENTRAL_IP and LOCAL_IP. And this
should be the IP of your host.
2. ENCAP_TYPE="geneve".

On 23 July 2018 at 12:41, Sandeep Adapala 
wrote:

> Hello All,
>
> I am trying to use this doc to setup the containers using OVS-DPDK (
> https://software.intel.com/en-us/articles/using-docker-
> containers-with-open-vswitch-and-dpdk-on-ubuntu-1710)
> but when I try to configure the ovs on overlay mode I am little confused on
> this configuration. I don't have a remote server I want everything to be
> installed in same server. so can you please help me out what should I
> remove and replace in the below config
>
> ovs-vsctl set Open_vSwitch . \
> external_ids:ovn-remote="tcp:$CENTRAL_IP:6642" \
> external_ids:ovn-nb="tcp:$CENTRAL_IP:6641" \
> external_ids:ovn-encap-ip=$LOCAL_IP \
> external_ids:ovn-encap-type="$ENCAP_TYPE"
>
>
> like what is CENTRAL_IP? ENCAP_TYPE and all?
>
> Regards,
> Sandeep
> ___
> 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] The “overlay” mode issue while setting up OVS with DPDK

[Sandeep Adapala]

Hello All,

I am trying to use this doc to setup the containers using OVS-DPDK (
https://software.intel.com/en-us/articles/using-docker-containers-with-open-vswitch-and-dpdk-on-ubuntu-1710)
but when I try to configure the ovs on overlay mode I am little confused on
this configuration. I don't have a remote server I want everything to be
installed in same server. so can you please help me out what should I
remove and replace in the below config

ovs-vsctl set Open_vSwitch . \
external_ids:ovn-remote="tcp:$CENTRAL_IP:6642" \
external_ids:ovn-nb="tcp:$CENTRAL_IP:6641" \
external_ids:ovn-encap-ip=$LOCAL_IP \
external_ids:ovn-encap-type="$ENCAP_TYPE"


like what is CENTRAL_IP? ENCAP_TYPE and all?

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

Re: [ovs-dev] [PATCH] compat: Initialize IPv4 reassembly secret timer

[Yi-Hung Wei]

>>> --- a/datapath/linux/compat/ip_fragment.c
>>> +++ b/datapath/linux/compat/ip_fragment.c
>>> @@ -812,6 +812,9 @@ int __init rpl_ipfrag_init(void)
>>>   #ifdef HAVE_INET_FRAGS_WITH_FRAGS_WORK
>>>  ip4_frags.frags_cache_name = ip_frag_cache_name;
>>>   #endif
>>> +#if RHEL_RELEASE_CODE < RHEL_RELEASE_VERSION(8,0)
>>> +   ip4_frags.secret_interval = 10 * 60 * HZ;
>>> +#endif
>>
>> This is a great catch!  Looks like we remove the secret_interval in
>> net-next commit
>> e3a57d18b061 ("inet: frag: remove periodic secret rebuild timer")
>> But somehow RHEL kernel still retain this field, and the
>> secret_interval was set to 10 * 60 * HZ.
>>
>> I would recommend to set 'secret_interval' by grepping this filed in
>> 'struct inet_frags' rather than by kernel version. So that if RHEL 8
>> kernel still have this field, your fix will apply.
>
>
> That's a good point to raise.
>
> My thinking was to specifically call it out for RHEL 7 because it hasn't
> been in the kernel since 3.16
> and this bug is RHEL 7 specific. That's a long way back and I'm sure it will
> not be there in
> the RHEL 8 kernel.  This makes it clear that it is only for RHEL 7 and
> nothing else.
>
> However, if you and others feel strongly about it I don't mind making the
> change.

I do not have a strong opinion no this. I think current solution also work.

Thanks,

Acked-by: Yi-Hung Wei 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCHv2] netdev-dpdk: Fix failure to configure flow control at netdev-init.

[Sugesh Chandran]

Configuring flow control at ixgbe netdev-init is throwing error in port
start.

For eg: without this fix, user cannot configure flow control on ixgbe dpdk
port as below,

"
ovs-vsctl add-port br0 dpdk0 -- set Interface dpdk0 type=dpdk \
options:dpdk-devargs=:05:00.1 options:rx-flow-ctrl=true
"

Instead,  it must be configured as two different commands,

"
ovs-vsctl add-port br0 dpdk0 -- set Interface dpdk0 type=dpdk \
   options:dpdk-devargs=:05:00.1
ovs-vsctl set Interface dpdk0 options:rx-flow-ctrl=true
"

The DPDK ixgbe driver is now validating all the 'rte_eth_fc_conf' fields before
trying to configuring the dpdk ethdev. Hence OVS can no longer set the
'dont care' fields to just '0' as before. This commit make sure all the
'rte_eth_fc_conf' fields are populated with default values before the dev
init.

Signed-off-by: Sugesh Chandran 
---
V1 -> V2
Read DPDK port flow-control parameters only when reconfiguration is
required. This will avoid flow control read error on unsupported ports.

---
 lib/netdev-dpdk.c | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
index bb4d60f..11eebe3 100644
--- a/lib/netdev-dpdk.c
+++ b/lib/netdev-dpdk.c
@@ -1065,14 +1065,6 @@ dpdk_eth_dev_init(struct netdev_dpdk *dev)
 
 mbp_priv = rte_mempool_get_priv(dev->dpdk_mp->mp);
 dev->buf_size = mbp_priv->mbuf_data_room_size - RTE_PKTMBUF_HEADROOM;
-
-/* Get the Flow control configuration for DPDK-ETH */
-diag = rte_eth_dev_flow_ctrl_get(dev->port_id, >fc_conf);
-if (diag) {
-VLOG_DBG("cannot get flow control parameters on port "DPDK_PORT_ID_FMT
- ", err=%d", dev->port_id, diag);
-}
-
 return 0;
 }
 
@@ -1776,6 +1768,12 @@ netdev_dpdk_set_config(struct netdev *netdev, const 
struct smap *args,
 if (dev->fc_conf.mode != fc_mode || autoneg != dev->fc_conf.autoneg) {
 dev->fc_conf.mode = fc_mode;
 dev->fc_conf.autoneg = autoneg;
+/* Get the Flow control configuration for DPDK-ETH */
+err = rte_eth_dev_flow_ctrl_get(dev->port_id, >fc_conf);
+if (err) {
+VLOG_INFO("cannot get flow control parameters on port "
+DPDK_PORT_ID_FMT", err=%d", dev->port_id, err);
+}
 dpdk_eth_flow_ctrl_setup(dev);
 }
 
-- 
2.7.4

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

[ovs-dev] [PATCH] ofproto-dpif: Fix typo in registered command

[Alin Gabriel Serdean]

Also split line at 79 characters.

Found by inspection.

Signed-off-by: Alin Gabriel Serdean 
---
 ofproto/ofproto-dpif.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/ofproto/ofproto-dpif.c b/ofproto/ofproto-dpif.c
index ad1e8af43..d0d564de1 100644
--- a/ofproto/ofproto-dpif.c
+++ b/ofproto/ofproto-dpif.c
@@ -5813,7 +5813,8 @@ ofproto_unixctl_init(void)
  NULL);
 unixctl_command_register("dpif/show-dp-features", "bridge", 1, 1,
  ofproto_unixctl_dpif_show_dp_features, NULL);
-unixctl_command_register("dpif/dump-flows", "[-m] [--names | --no-nmaes] 
bridge", 1, INT_MAX,
+unixctl_command_register("dpif/dump-flows",
+ "[-m] [--names | --no-names] bridge", 1, INT_MAX,
  ofproto_unixctl_dpif_dump_flows, NULL);
 unixctl_command_register("dpif/set-dp-features", "bridge", 1, 3 ,
  ofproto_unixctl_dpif_set_dp_features, NULL);
-- 
2.16.1.windows.1

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

[ovs-dev] Contribution

[kumaraparameshwaran rathinavel]

Hi All,

I would like to start contributing to Open-vSwitch. Is there any file that
maintains TODO list or the bugs to be resolved. Would like to start by
looking into that.

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

[ovs-dev] GRE over IPsec tunnel

[Alvaro Jimenez]

Hi everyone,

Does anyone know how to set up a GRE over IPsec tunnel? I found this
command:

ovs-vsctl add-port br0 gre1
ovs-vsctl set interface gre1 type=ipsec_gre \
options:remote_ip= \
options:pmtud=false \
options:psk=test \
options:certificate=cert.pem

Do i have to create a GRE tunnel with ip tunnel command first? Im a newbie
at networking and OpenFlow so any help would be appreciated.

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