Re: [ovs-discuss] [openvswitch 2.14.0] system-kmod-testsuite: 29 78 130 failed / system-userspace-testsuite: 130 failed

2021-09-30 Thread Gregory Rose 



On 9/30/2021 10:30 AM, Eric Sender wrote:

Greg, thank you for this. I ran the cherry-pick command and the code is in
place. Now, I am still getting the following errors (attached)

Subject: [openvswitch 2.14.0] system-kmod-testsuite: 29 78 130 faile /
system-userspace-testsuite: 130 failed


Hi Eric,

Let's not drop the list.

A few make check errors will not generally be an issue unless those
make check errors are directly related to what you're trying to
do.  The system-userspace-testsuite is not always up to date for
older branches.

If you're building packages such as RPMs you can build them without
the make check this way:

make rpm-fedora RPMBUILD_OPT="--without check"

- Greg



On Thu, Sep 30, 2021 at 9:25 AM Gregory Rose  wrote:




On 9/29/2021 6:36 PM, Eric Sender wrote:

Hello,

I think my issue is two fold:

 1. In order to get OVS to compile, I needed to make a few changes to

the

 code. Namely, to change skb->l4_rxhash to skb->l4_hash?
- I feel I shouldn't have needed to do that in order to compile

2. Not sure if its related, but I found 4 errors which I have
 attached.
- Any thoughts on those errors?


Here is a diff of the following changes I needed to make (basically a
ctrl-F replace of l4_rxhash to l4_hash.

*diff --git a/acinclude.m4 b/acinclude.m4*
index 84f344da0..b14fab8f3 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -874,7 +874,7 @@ AC_DEFUN([OVS_CHECK_LINUX_COMPAT], [
 OVS_GREP_IFELSE([$KSRC/include/linux/skbuff.h], [skb_clear_hash])
 OVS_GREP_IFELSE([$KSRC/include/linux/skbuff.h], [int.skb_zerocopy(],
 [OVS_DEFINE([HAVE_SKB_ZEROCOPY])])
-  OVS_GREP_IFELSE([$KSRC/include/linux/skbuff.h], [u8.*l4_rxhash],
+  OVS_GREP_IFELSE([$KSRC/include/linux/skbuff.h], [u8.*l4_hash],
 [OVS_DEFINE([HAVE_L4_RXHASH])])
 OVS_GREP_IFELSE([$KSRC/include/linux/skbuff.h],

[skb_ensure_writable])

 OVS_GREP_IFELSE([$KSRC/include/linux/skbuff.h], [skb_vlan_pop])



Hi Eric,

you're missing this commit:
f365b41f9dff ('compat: Fix build issue on RHEL 7.7.')

It's not in branch 2.14.  You can cherry pick it from master
or you could just update to branch 2.15.

Regards,

- Greg



*diff --git a/datapath/datapath.c b/datapath/datapath.c*
index 05c1e4274..0796c199c 100644
--- a/datapath/datapath.c
+++ b/datapath/datapath.c
@@ -533,7 +533,7 @@ static int queue_userspace_packet(struct datapath

*dp,

struct sk_buff *skb,
   #endif

   #ifdef HAVE_L4_RXHASH
- if (skb->l4_rxhash)
+ if (skb->l4_hash)
   #else
if (skb->l4_hash)
   #endif


*diff --git a/datapath/linux/compat/include/linux/skbuff.h*
b/datapath/linux/compat/include/linux/skbuff.h
index 6d248b3ed..328a631d8 100644
--- a/datapath/linux/compat/include/linux/skbuff.h
+++ b/datapath/linux/compat/include/linux/skbuff.h
@@ -279,7 +279,7 @@ static inline void skb_clear_hash(struct sk_buff

*skb)

skb->rxhash = 0;
   #endif
   #if defined(HAVE_L4_RXHASH) && !defined(HAVE_RHEL_OVS_HOOK)
- skb->l4_rxhash = 0;
+ skb->l4_hash = 0;
   #endif
   }
   #endif
@@ -371,7 +371,7 @@ static inline void skb_pop_mac_header(struct sk_buff
*skb)
   #ifndef HAVE_SKB_CLEAR_HASH_IF_NOT_L4
   static inline void skb_clear_hash_if_not_l4(struct sk_buff *skb)
   {
- if (!skb->l4_rxhash)
+ if (!skb->l4_hash)
skb_clear_hash(skb);
   }
   #endif
@@ -466,7 +466,7 @@ __skb_set_hash(struct sk_buff *skb, __u32 hash, bool
is_sw, bool is_l4)
skb->hash = hash;
   #endif
   #if defined(HAVE_L4_RXHASH)
- skb->l4_rxhash = is_l4;
+ skb->l4_hash = is_l4;
   #else
skb->l4_hash = is_l4;
   #endif

Essentially, I needed to change all references to skb->l4_rxhash to
skb->l4_hash because of the following errors during make:

$ make
...
/root/build/datapath/linux/datapath.c: In function

‘queue_userspace_packet’:

/root/build/datapath/linux/datapath.c:536:9: error: ‘struct sk_buff’ has

no

member named ‘l4_rxhash’
if (skb->l4_rxhash)
   ^
...
make[5]: *** [/root/build/datapath/linux/datapath.o] Error 1
make[4]: *** [_module_/root/build/datapath/linux] Error 2
make[4]: Leaving directory `/usr/src/kernels/3.10.0-1160.36.2.el7.x86_64'
make[3]: *** [default] Error 2
make[3]: Leaving directory `/root/build/datapath/linux'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/root/build/datapath'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/root/build'
make: *** [all] Error 2


Thank you,
Eric


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss






___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] ovn-controller: unable to reach metadata service after boot

2021-09-30 Thread Frode Nordahl 
On Thu, Sep 30, 2021 at 8:32 AM Frode Nordahl
 wrote:
>
> On Mon, Sep 27, 2021 at 2:05 PM Benjamin Reichel  
> wrote:
> >
> > Hi everyone,
> >
> > We are using OVN together with Openstack(Ussuri) with one of the late 
> > master versions of ovn (83296a42e) and we see the following issue. After 
> > booting a VM it is not possible to reach the metadata service in the 
> > corresponding network namespace of the neutron-ovn-metadata-agent.service.
> >
> > It also turned out that a recompute of the rules on the ovn-controller 
> > fixes the issue. After more debugging we could identify the change that 
> > introduced this situation:
> >
> > commit d4bca93c0851c2f0b739411cd49ce32e3b8263bb "controller: Don't allocate 
> > zone ids for non-VIF port bindings."
> >
> > diff --git a/controller/ovn-controller.c b/controller/ovn-controller.c
> > index 678419ab3..739048cf8 100644
> > --- a/controller/ovn-controller.c
> > +++ b/controller/ovn-controller.c
> > @@ -1919,6 +1919,11 @@ ct_zones_runtime_data_handler(struct engine_node 
> > *node, void *data)
> >  struct shash_node *shash_node;
> >  SHASH_FOR_EACH (shash_node, &tdp->lports) {
> >  struct tracked_lport *t_lport = shash_node->data;
> > +if (strcmp(t_lport->pb->type, "")) {
> > +/* We allocate zone-id's only to VIF lports. */
> > +continue;
> > +}
> > +
> >  if (t_lport->tracked_type == TRACKED_RESOURCE_NEW) {
> >  if (!simap_contains(&ct_zones_data->current,
> >  t_lport->pb->logical_port)) {
> >
> > Anyone has an idea how to fix it?
>
> Thank you for reporting this issue, I see the same thing here. Adding
> "localport" to the approved list of lport types in the above mentioned
> check resolves this specific issue:
>
> diff --git a/controller/ovn-controller.c b/controller/ovn-controller.c
> index a719beb0e..4202f32cc 100644
> --- a/controller/ovn-controller.c
> +++ b/controller/ovn-controller.c
> @@ -1919,8 +1919,9 @@ ct_zones_runtime_data_handler(struct engine_node
> *node, void *data)
>  struct shash_node *shash_node;
>  SHASH_FOR_EACH (shash_node, &tdp->lports) {
>  struct tracked_lport *t_lport = shash_node->data;
> -if (strcmp(t_lport->pb->type, "")) {
> -/* We allocate zone-id's only to VIF lports. */
> +if (strcmp(t_lport->pb->type, "")
> +&& strcmp(t_lport->pb->type, "localport")) {
> +/* We allocate zone-id's only to VIF and localport lports. */
>  continue;
>  }
>
> But it makes me wonder if other types should be on that list as well,
> I added the authors of the two last changes in this area to Cc to see
> if they have any insights and will also have a look at comparing the
> output of the old and new implementation.

Posted a formal patch here:
https://mail.openvswitch.org/pipermail/ovs-dev/2021-September/388199.html

-- 
Frode Nordahl

> --
> Frode Nordahl
>
> > Regards,
> > Benjamin
> >
> > ___
> > discuss mailing list
> > disc...@openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] query on using promiscuous mode dpdk application with ovs

2021-09-30 Thread Prakash Sahni via discuss 
I have a DPDK forwarding application which runs in promiscuous mode copying 
packets from both of its ports to the other port, it also spoofs source mac 
addresses while forwarding, i.e. it never uses its source mac address.Currently 
this runs on bare metal Linux on physical ports connected to real switches.

I want to run this in a VM now.

1. Can I run this DPDK application on a VM with the non-DPDK version of 
openvswitch  ?2. I want openvswitch to pass this all the traffic received on 
the physical port and other virtual ports hosted on the  ovs switch, destined 
to the spoofed source mac addresses sent by this vm and no other address. (This 
is how the application works on the real switch). How do I configure ovs to do 
this ? I could achieve this with sr-iov, the only problem is it gets all the 
addresses from the physical and virtual ports and not just the spoofed mac 
addresses it forwards.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [openvswitch 2.14.0] system-kmod-testsuite: 29 78 130 failed / system-userspace-testsuite: 130 failed

2021-09-30 Thread Gregory Rose 



On 9/29/2021 6:36 PM, Eric Sender wrote:

Hello,

I think my issue is two fold:

1. In order to get OVS to compile, I needed to make a few changes to the
code. Namely, to change skb->l4_rxhash to skb->l4_hash?
   - I feel I shouldn't have needed to do that in order to compile

   2. Not sure if its related, but I found 4 errors which I have
attached.
   - Any thoughts on those errors?


Here is a diff of the following changes I needed to make (basically a
ctrl-F replace of l4_rxhash to l4_hash.

*diff --git a/acinclude.m4 b/acinclude.m4*
index 84f344da0..b14fab8f3 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -874,7 +874,7 @@ AC_DEFUN([OVS_CHECK_LINUX_COMPAT], [
OVS_GREP_IFELSE([$KSRC/include/linux/skbuff.h], [skb_clear_hash])
OVS_GREP_IFELSE([$KSRC/include/linux/skbuff.h], [int.skb_zerocopy(],
[OVS_DEFINE([HAVE_SKB_ZEROCOPY])])
-  OVS_GREP_IFELSE([$KSRC/include/linux/skbuff.h], [u8.*l4_rxhash],
+  OVS_GREP_IFELSE([$KSRC/include/linux/skbuff.h], [u8.*l4_hash],
[OVS_DEFINE([HAVE_L4_RXHASH])])
OVS_GREP_IFELSE([$KSRC/include/linux/skbuff.h], [skb_ensure_writable])
OVS_GREP_IFELSE([$KSRC/include/linux/skbuff.h], [skb_vlan_pop])



Hi Eric,

you're missing this commit:
f365b41f9dff ('compat: Fix build issue on RHEL 7.7.')

It's not in branch 2.14.  You can cherry pick it from master
or you could just update to branch 2.15.

Regards,

- Greg



*diff --git a/datapath/datapath.c b/datapath/datapath.c*
index 05c1e4274..0796c199c 100644
--- a/datapath/datapath.c
+++ b/datapath/datapath.c
@@ -533,7 +533,7 @@ static int queue_userspace_packet(struct datapath *dp,
struct sk_buff *skb,
  #endif

  #ifdef HAVE_L4_RXHASH
- if (skb->l4_rxhash)
+ if (skb->l4_hash)
  #else
   if (skb->l4_hash)
  #endif


*diff --git a/datapath/linux/compat/include/linux/skbuff.h*
b/datapath/linux/compat/include/linux/skbuff.h
index 6d248b3ed..328a631d8 100644
--- a/datapath/linux/compat/include/linux/skbuff.h
+++ b/datapath/linux/compat/include/linux/skbuff.h
@@ -279,7 +279,7 @@ static inline void skb_clear_hash(struct sk_buff *skb)
   skb->rxhash = 0;
  #endif
  #if defined(HAVE_L4_RXHASH) && !defined(HAVE_RHEL_OVS_HOOK)
- skb->l4_rxhash = 0;
+ skb->l4_hash = 0;
  #endif
  }
  #endif
@@ -371,7 +371,7 @@ static inline void skb_pop_mac_header(struct sk_buff
*skb)
  #ifndef HAVE_SKB_CLEAR_HASH_IF_NOT_L4
  static inline void skb_clear_hash_if_not_l4(struct sk_buff *skb)
  {
- if (!skb->l4_rxhash)
+ if (!skb->l4_hash)
   skb_clear_hash(skb);
  }
  #endif
@@ -466,7 +466,7 @@ __skb_set_hash(struct sk_buff *skb, __u32 hash, bool
is_sw, bool is_l4)
   skb->hash = hash;
  #endif
  #if defined(HAVE_L4_RXHASH)
- skb->l4_rxhash = is_l4;
+ skb->l4_hash = is_l4;
  #else
   skb->l4_hash = is_l4;
  #endif

Essentially, I needed to change all references to skb->l4_rxhash to
skb->l4_hash because of the following errors during make:

$ make
...
/root/build/datapath/linux/datapath.c: In function ‘queue_userspace_packet’:
/root/build/datapath/linux/datapath.c:536:9: error: ‘struct sk_buff’ has no
member named ‘l4_rxhash’
   if (skb->l4_rxhash)
  ^
...
make[5]: *** [/root/build/datapath/linux/datapath.o] Error 1
make[4]: *** [_module_/root/build/datapath/linux] Error 2
make[4]: Leaving directory `/usr/src/kernels/3.10.0-1160.36.2.el7.x86_64'
make[3]: *** [default] Error 2
make[3]: Leaving directory `/root/build/datapath/linux'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/root/build/datapath'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/root/build'
make: *** [all] Error 2


Thank you,
Eric


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] Action to learn macs for openflow

2021-09-30 Thread George Shuklin 

Hello.

We have an asymmetric setup - traffic in one direction is following a 
simple 'output' action (to one specific port), and traffic from that 
port is 'actions: normal'.


I wounder if the 'output' action inserts anything into FDB (I suspect 
it's not), and if it's not, than, how to insert data into FDB for 
'normal' to work.


Let's say I have a flow and I want to update FDB entry. How to do this?


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss