Re: [ovs-dev] [PATCH v4 2/2] Eliminate use of term "slave" in bond, LACP, and bundle contexts.

[0-day Robot]

Bleep bloop.  Greetings Ben Pfaff, I am a robot and I have tried out your patch.
Thanks for your contribution.

I encountered some error that I wasn't expecting.  See the details below.


checkpatch:
WARNING: Line is 80 characters long (recommended limit is 79)
#405 FILE: include/openvswitch/ofp-actions.h:381:
 * member = { members[i] such that weights[i] >= weights[j] for all j != i }

WARNING: Line is 189 characters long (recommended limit is 79)
#2357 FILE: lib/ovs-actions.xml:792:
  bundle(fields, 
basis, algorithm, ofport, 
members:port...)

WARNING: Line is 223 characters long (recommended limit is 79)
#2358 FILE: lib/ovs-actions.xml:793:
  bundle_load(fields, 
basis, algorithm, ofport, 
dst, 
members:port...)

WARNING: Line is 155 characters long (recommended limit is 79)
#2396 FILE: lib/ovs-actions.xml:871:
member = { i such that weights[i] 
= weights[j] for all j != i }

WARNING: Line is 81 characters long (recommended limit is 79)
#2614 FILE: ofproto/bond.c:168:
static struct bond_member *bond_member_lookup(struct bond *, const void 
*member_)

WARNING: Line is 82 characters long (recommended limit is 79)
#2836 FILE: ofproto/bond.c:583:
hmap_insert(>members, >hmap_node, hash_pointer(member_, 
0));

WARNING: Line is 80 characters long (recommended limit is 79)
#3120 FILE: ofproto/bond.c:870:
verdict = (member->enabled || member->may_enable) ? BV_ACCEPT : BV_DROP;

WARNING: Comment with 'xxx' marker
#3419 FILE: ofproto/bond.c:1288:
 * XXX This is O(n**2) in the number of members but it could be O(n lg n)

WARNING: Line is 80 characters long (recommended limit is 79)
#3457 FILE: ofproto/bond.c:1323:
 * 'e' to be migrated to another member in this rebalancing run, and

WARNING: Line is 80 characters long (recommended limit is 79)
#3843 FILE: ofproto/bond.c:1822:
ovs_list_insert(>bond->enabled_members, >list_node);

WARNING: Line is 80 characters long (recommended limit is 79)
#4208 FILE: ofproto/bond.h:123:
 *  recirc_id=, dp_hash=<[0..255]>/0xff, actions: output

WARNING: Line is 80 characters long (recommended limit is 79)
#4417 FILE: ofproto/ofproto-dpif.c:3565:
bond_member_set_may_enable(bundle->bond, port, port->up.may_enable);

WARNING: Line is 80 characters long (recommended limit is 79)
#4510 FILE: ofproto/ofproto-provider.h:1712:
 * and, if there is more than one member, a bonding configuration.  If 'aux'

WARNING: Line is 81 characters long (recommended limit is 79)
#4575 FILE: ofproto/ofproto.h:459:
struct lacp_member_settings *lacp_members; /* Array of n_members elements. 
*/

Lines checked: 6143, Warnings: 14, Errors: 0


Please check this out.  If you feel there has been an error, please email 
acon...@redhat.com

Thanks,
0-day Robot
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v3 3/4] conntrack: Rename "master" connection to "primary" connection.

[Ben Pfaff]

On Fri, Jul 10, 2020 at 12:46:47PM +, Alin Serdean wrote:
> From: Ben Pfaff
> Sent: Tuesday, July 7, 2020 7:26 PM
> To: d...@openvswitch.org
> Cc: Ben Pfaff
> Subject: [ovs-dev] [PATCH v3 3/4] conntrack: Rename "master" connection to 
> "primary" connection.
> 
> Signed-off-by: Ben Pfaff 
> ---
> 
> As discussed offline, your suggestion of switching to “parent” connection 
> instead of “primary”, sounds better
> in my opinion.

I made that change in v4.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v3 1/4] Eliminate use of term "slave" in bond, LACP, and bundle contexts.

[Ben Pfaff]

On Fri, Jul 10, 2020 at 12:52:12PM +, Alin Serdean wrote:
> From: Ben Pfaff
> Sent: Tuesday, July 7, 2020 7:29 PM
> To: d...@openvswitch.org
> Cc: Ben Pfaff
> Subject: [ovs-dev] [PATCH v3 1/4] Eliminate use of term "slave" in bond, 
> LACP, and bundle contexts.
> 
> Most of these changes should not change user-visible behavior.  One
> place where they do is in "ovs-ofctl dump-flows", which will now output
> "subs:..." inside "bundle" actions instead of "slaves:...".  I don't
> expect this to cause real problems in most systems.  The old syntax
> is still supported on input for backward compatibility.
> 
> Signed-off-by: Ben Pfaff 
> ---
> As discussed offline instead of the term “sub-interface” maybe use “member”.
> 
> Leaving the link for the MSFT naming convention:
> https://docs.microsoft.com/en-us/powershell/module/netlbfo/add-netlbfoteammember?view=win10-ps

Good suggestion.  In v4 I changed all of these to "member".
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v3 1/4] Eliminate use of term "slave" in bond, LACP, and bundle contexts.

[Ben Pfaff]

On Mon, Jul 13, 2020 at 07:35:30PM +, Jeff Squyres (jsquyres) wrote:
> On Jul 10, 2020, at 8:52 AM, Alin Serdean  
> wrote:
> > 
> > Most of these changes should not change user-visible behavior.  One
> > place where they do is in "ovs-ofctl dump-flows", which will now output
> > "subs:..." inside "bundle" actions instead of "slaves:...".  I don't
> > expect this to cause real problems in most systems.  The old syntax
> > is still supported on input for backward compatibility.
> > 
> > Signed-off-by: Ben Pfaff 
> > ---
> > As discussed offline instead of the term “sub-interface” maybe use “member”.
> > 
> > Leaving the link for the MSFT naming convention:
> > https://docs.microsoft.com/en-us/powershell/module/netlbfo/add-netlbfoteammember?view=win10-ps
> 
> I see that there is still some discussion ongoing regarding these four 
> inclusive-language patches.
> 
> What's the probability that these patches will be included in the upcoming 
> v2.14 release?

Well, I guess it didn't happen ;-)
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH v4 0/2] Use more sensitive terminology.

[Ben Pfaff]

There's no value in risking turning people away from OVS due to
insensitive terminology choices.  We can do better.

v1->v2: Rebase.
v2->v3: Fix some new instances of "slave" that had crept in (thanks
  Ilya!).  Drop a patch that I had accidentally appended in v2.
v3->v4: Apply two of the patches that had been reviewed by Alin.
  Update the other two patches based on suggestions: "primary"
  connection becomes "parent", "sub-interfaces" become "members"
  (also suggested by Alin).

Ben Pfaff (2):
  conntrack: Rename "master" connection to "parent" connection.
  Eliminate use of term "slave" in bond, LACP, and bundle contexts.

 Documentation/topics/bonding.rst  | 167 +++---
 Documentation/topics/porting.rst  |   4 +-
 NEWS  |   4 +-
 debian/changelog  |   2 +-
 debian/ifupdown.sh|   4 +-
 include/openvswitch/meta-flow.h   |  14 +-
 include/openvswitch/ofp-actions.h |  28 +-
 lib/bundle.c  | 101 ++--
 lib/bundle.h  |   4 +-
 lib/cfm.c |   4 +-
 lib/conntrack-private.h   |  10 +-
 lib/conntrack.c   |  74 +--
 lib/ct-dpif.c |   6 +-
 lib/ct-dpif.h |   2 +-
 lib/dpif-netdev.c |  42 +-
 lib/dpif-provider.h   |   4 +-
 lib/dpif.c|   4 +-
 lib/dpif.h|   2 +-
 lib/lacp.c| 547 +--
 lib/lacp.h|  25 +-
 lib/lldp/lldp-const.h |  16 +-
 lib/lldp/lldpd-structs.h  |  10 +-
 lib/mac-learning.c|   4 +-
 lib/mac-learning.h|   2 +-
 lib/meta-flow.xml |   2 +-
 lib/netdev-linux.c|  22 +-
 lib/netlink-conntrack.c   |   6 +-
 lib/ofp-actions.c | 108 ++--
 lib/ovs-actions.xml   |  35 +-
 lib/rtnetlink.c   |  16 +-
 lib/rtnetlink.h   |   6 +-
 lib/unixctl.c |   6 +-
 ofproto/bond.c| 839 +++---
 ofproto/bond.h|  29 +-
 ofproto/ofproto-dpif-rid.h|   4 +-
 ofproto/ofproto-dpif-sflow.c  |   2 +-
 ofproto/ofproto-dpif-xlate.c  |  22 +-
 ofproto/ofproto-dpif.c|  47 +-
 ofproto/ofproto-dpif.h|   2 +-
 ofproto/ofproto-provider.h|  12 +-
 ofproto/ofproto.c |   7 +-
 ofproto/ofproto.h |  11 +-
 tests/bundle.at   |  48 +-
 tests/lacp.at | 146 +++---
 tests/ofp-actions.at  |  28 +-
 tests/ofproto-dpif.at | 106 ++--
 tests/ofproto.at  |   4 +-
 tests/ovs-ofctl.at|  56 +-
 tests/system-traffic.at   |   6 +-
 tests/test-bundle.c   | 112 ++--
 vswitchd/bridge.c |  35 +-
 vswitchd/ovs-vswitchd.8.in|  42 +-
 vswitchd/vswitch.xml  |  37 +-
 53 files changed, 1457 insertions(+), 1419 deletions(-)

-- 
2.26.2

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

[ovs-dev] [PATCH v4 1/2] conntrack: Rename "master" connection to "parent" connection.

[Ben Pfaff]

Signed-off-by: Ben Pfaff 
---
 include/openvswitch/meta-flow.h | 14 +++
 lib/conntrack-private.h | 10 ++---
 lib/conntrack.c | 74 -
 lib/ct-dpif.c   |  6 +--
 lib/ct-dpif.h   |  2 +-
 lib/meta-flow.xml   |  2 +-
 lib/netlink-conntrack.c |  6 +--
 tests/ofproto-dpif.at   |  6 +--
 tests/system-traffic.at |  6 +--
 9 files changed, 63 insertions(+), 63 deletions(-)

diff --git a/include/openvswitch/meta-flow.h b/include/openvswitch/meta-flow.h
index d529a9f0d21c..95e52e3587ee 100644
--- a/include/openvswitch/meta-flow.h
+++ b/include/openvswitch/meta-flow.h
@@ -852,7 +852,7 @@ enum OVS_PACKED_ENUM mf_field_id {
 /* "ct_nw_proto".
  *
  * The "protocol" byte in the IPv4 or IPv6 header for the original
- * direction conntrack tuple, or of the master conntrack entry, if the
+ * direction conntrack tuple, or of the parent conntrack entry, if the
  * current connection is a related connection.
  *
  * The value is initially zero and populated by the CT action.  The value
@@ -873,7 +873,7 @@ enum OVS_PACKED_ENUM mf_field_id {
 /* "ct_nw_src".
  *
  * IPv4 source address of the original direction tuple of the conntrack
- * entry, or of the master conntrack entry, if the current connection is a
+ * entry, or of the parent conntrack entry, if the current connection is a
  * related connection.
  *
  * The value is populated by the CT action.
@@ -892,7 +892,7 @@ enum OVS_PACKED_ENUM mf_field_id {
 /* "ct_nw_dst".
  *
  * IPv4 destination address of the original direction tuple of the
- * conntrack entry, or of the master conntrack entry, if the current
+ * conntrack entry, or of the parent conntrack entry, if the current
  * connection is a related connection.
  *
  * The value is populated by the CT action.
@@ -911,7 +911,7 @@ enum OVS_PACKED_ENUM mf_field_id {
 /* "ct_ipv6_src".
  *
  * IPv6 source address of the original direction tuple of the conntrack
- * entry, or of the master conntrack entry, if the current connection is a
+ * entry, or of the parent conntrack entry, if the current connection is a
  * related connection.
  *
  * The value is populated by the CT action.
@@ -930,7 +930,7 @@ enum OVS_PACKED_ENUM mf_field_id {
 /* "ct_ipv6_dst".
  *
  * IPv6 destination address of the original direction tuple of the
- * conntrack entry, or of the master conntrack entry, if the current
+ * conntrack entry, or of the parent conntrack entry, if the current
  * connection is a related connection.
  *
  * The value is populated by the CT action.
@@ -949,7 +949,7 @@ enum OVS_PACKED_ENUM mf_field_id {
 /* "ct_tp_src".
  *
  * Transport layer source port of the original direction tuple of the
- * conntrack entry, or of the master conntrack entry, if the current
+ * conntrack entry, or of the parent conntrack entry, if the current
  * connection is a related connection.
  *
  * The value is populated by the CT action.
@@ -967,7 +967,7 @@ enum OVS_PACKED_ENUM mf_field_id {
 /* "ct_tp_dst".
  *
  * Transport layer destination port of the original direction tuple of the
- * conntrack entry, or of the master conntrack entry, if the current
+ * conntrack entry, or of the parent conntrack entry, if the current
  * connection is a related connection.
  *
  * The value is populated by the CT action.
diff --git a/lib/conntrack-private.h b/lib/conntrack-private.h
index 3434753016f0..789af82ff77d 100644
--- a/lib/conntrack-private.h
+++ b/lib/conntrack-private.h
@@ -71,13 +71,13 @@ struct alg_exp_node {
 /* Key of data connection to be created. */
 struct conn_key key;
 /* Corresponding key of the control connection. */
-struct conn_key master_key;
+struct conn_key parent_key;
 /* The NAT replacement address to be used by the data connection. */
 union ct_addr alg_nat_repl_addr;
-/* The data connection inherits the master control
+/* The data connection inherits the parent control
  * connection label and mark. */
-ovs_u128 master_label;
-uint32_t master_mark;
+ovs_u128 parent_label;
+uint32_t parent_mark;
 /* True if for NAT application, the alg replaces the dest address;
  * otherwise, the source address is replaced.  */
 bool nat_rpl_dst;
@@ -92,7 +92,7 @@ struct conn {
 /* Immutable data. */
 struct conn_key key;
 struct conn_key rev_key;
-struct conn_key master_key; /* Only used for orig_tuple support. */
+struct conn_key parent_key; /* Only used for orig_tuple support. */
 struct ovs_list exp_node;
 struct cmap_node cm_node;
 struct nat_action_info_t *nat_info;
diff --git a/lib/conntrack.c b/lib/conntrack.c
index f42ba4b601c7..930ed0be6186 100644
--- a/lib/conntrack.c
+++ 

Re: [ovs-dev] [PATCH v3 4/4] Eliminate "whitelist" and "blacklist" terms.

[Ben Pfaff]

On Fri, Jul 10, 2020 at 12:41:59PM +, Alin Serdean wrote:
> From: Ben Pfaff
> Sent: Tuesday, July 7, 2020 7:25 PM
> To: d...@openvswitch.org
> Cc: Ben Pfaff
> Subject: [ovs-dev] [PATCH v3 4/4] Eliminate "whitelist" and "blacklist" terms.
> 
> There is one remaining use under datapath.  That change should happen
> upstream in Linux first according to our usual policy.
> 
> Signed-off-by: Ben Pfaff 
> ---
> 
> Acked-by: Alin Gabriel Serdean aserd...@ovn.org

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

[ovs-dev] Excel Intermedio

[Herramientas de validación de datos y fórmulas]

Me da mucho gusto saludarte.
 
Es, para mí, un placer poder invitarte a nuestro Curso en Línea "Excel 
Intermedio", que se estará
llevando a cabo los días 7, 14 y 21 de Noviembre con un horario de 10:00 a 
14:00 hrs.(hora del centro de México), con
un total de 12 hrs.
 
Con este curso de Excel Intermedio puedes aprender a construir fórmulas 
utilizando de base las diferentes categorías de funciones 
y herramientas de validación de datos y fórmulas que ofrece Excel combinándolas 
con el uso de gráficos.

Temario:
 
- Fórmulas.
- Auditoría de Fórmulas.
- Organizando Datos.
- Gráficas
 
Para mayor información, responder sobre este correo con la palabra Excel + los 
siguientes datos:

NOMBRE:
TELÉFONO:
EMPRESA:
CORREO ALTERNO: 

Para información inmediata llamar al:
(+52) 55 15 54 66 30 - (+52) 55 30 16 70 85
O puede enviarnos un mensaje vía whatsapp 

Innova Learn México - innovalearn. mx - Mérida, Yucatán, México


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

[ovs-dev] The Laws are Changing and this may be your last chance...Get CCW Certified Now!

[Certifiedccw Offer]

Having trouble viewing this email? Please follow this link to see the messaged 
emailed to you. 

Product Image

Product Image

Product Image

Product Image






(Unsubscribe Instructions Here)
(Unsubscribe Instructions Here)
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net v3] net: openvswitch: fix to make sure flow_lookup() is not preempted

[Jakub Kicinski]

On Thu, 15 Oct 2020 19:09:33 +0200 Eelco Chaudron wrote:
> The flow_lookup() function uses per CPU variables, which must be called
> with BH disabled. However, this is fine in the general NAPI use case
> where the local BH is disabled. But, it's also called from the netlink
> context. The below patch makes sure that even in the netlink path, the
> BH is disabled.
> 
> In addition, u64_stats_update_begin() requires a lock to ensure one writer
> which is not ensured here. Making it per-CPU and disabling NAPI (softirq)
> ensures that there is always only one writer.
> 
> Fixes: eac87c413bf9 ("net: openvswitch: reorder masks array based on usage")
> Reported-by: Juri Lelli 
> Signed-off-by: Eelco Chaudron 

Hi Eelco, looks like this doesn't apply after the 5.10 merges.

Please respin on top of the current net.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] OvS Processes

[Ilya Maximets]

On 10/16/20 11:23 PM, Filipe Lemos wrote:
> Hello everyone,
> I tried to learn more about each process created by running OvS while my
> bridge runs as a SDN switch connected to a controller. I can see that there
> are 4 processes with ovs in the name, as shown in the attached screenshot.

Hi, Filipe.

The mailing list is filtering attachments, so your screenshot was lost.
Could you write down the names and command lines of the processes you want
to ask about in text form?

> What does each one of them do? There is any documentation explaining them?
> 
> Thank you,
> 

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

[ovs-dev] Democrats hate this website so much: Concealed Carry Permit Certifications 100% online

[Certifiedccw Info]

Having trouble viewing this email? Please follow this link to see the messaged 
emailed to you. 

Product Image

Product Image

Product Image

Product Image






(Unsubscribe Instructions Here)
(Unsubscribe Instructions Here)

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

[ovs-dev] OvS Processes

[Filipe Lemos]

Hello everyone,
I tried to learn more about each process created by running OvS while my
bridge runs as a SDN switch connected to a controller. I can see that there
are 4 processes with ovs in the name, as shown in the attached screenshot.
What does each one of them do? There is any documentation explaining them?

Thank you,

-- 

*Filipe Augusto da Luz Lemos* M.Sc.

*PhD Graduate Student | Networks and Distributed Systems | Federal
University of Technology Paraná*

*Forensic Sciences* |* Syracuse University*


*Electrical Engineering | Federal University of Technology Paraná*

fadal...@syr.edu *|* http://forensics.syr.edu/

*fle...@alunos.utfpr.edu.br
 | http://utfpr.edu.br  *
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH ovn v2 2/3] actions: Add new OVN logical fields 'ip.src' and ip.dst'.

[Han Zhou]

On Thu, Oct 15, 2020 at 1:38 PM Mark Michelson  wrote:
>
> On 10/14/20 8:38 AM, Numan Siddique wrote:
> > On Wed, Oct 14, 2020 at 5:51 PM Dumitru Ceara  wrote:
> >>
> >> On 10/14/20 2:13 PM, Numan Siddique wrote:
> >>> On Wed, Oct 14, 2020 at 5:34 PM Dumitru Ceara 
wrote:
> 
>  On 10/14/20 1:54 PM, Numan Siddique wrote:
> > On Wed, Oct 14, 2020 at 4:40 PM Dumitru Ceara 
wrote:
> >>
> >> On 10/14/20 12:50 PM, Numan Siddique wrote:
> >>> On Wed, Oct 14, 2020 at 3:50 PM Dumitru Ceara 
wrote:
> 
>  On 10/14/20 11:15 AM, num...@ovn.org wrote:
> > From: Numan Siddique 
> >
> > Thee new fields are version independent and these can be used
in any
> 
>  Hi Numan,
> 
>  Nit: s/Thee/These
> 
> > OVN action. Right now the usage of these fields are restricted
to
> > exchanging the IP source and destination fields.
> >
> > Eg. reject {... ip.src <-> ip.dst ... };
> >
> > "ip.src <-> ip.dst" translates to controller action with
"pause" flag set.
> > When pinctrl thread receives the packet in, it checks the IP
version of the
> > packet and either does - "ip4.src <-> ip4.dst" or "ip6.src <->
ip6.dst" and
> > resumes the packet to continue with the pipeline.
> >
> > Upcoming patch will make use of these fields.
> >
> > Signed-off-by: Numan Siddique 
> > ---
> >   controller/pinctrl.c |  49 +++
> >   include/ovn/actions.h|   4 ++
> >   include/ovn/logical-fields.h |  18 ++
> >   lib/actions.c| 118
+++
> >   lib/logical-fields.c |  10 +++
> >   ovn-sb.xml   |  37 +++
> >   tests/ovn.at |  27 
> >   utilities/ovn-trace.c|  28 +
> >   8 files changed, 291 insertions(+)
> >
> > diff --git a/controller/pinctrl.c b/controller/pinctrl.c
> > index 631d058458..bc16a82404 100644
> > --- a/controller/pinctrl.c
> > +++ b/controller/pinctrl.c
> > @@ -233,6 +233,11 @@ static void
pinctrl_handle_put_icmp_frag_mtu(struct rconn *swconn,
> >struct
ofputil_packet_in *pin,
> >struct ofpbuf
*userdata,
> >struct ofpbuf
*continuation);
> > +static void pinctrl_handle_swap_src_dst_ip(struct rconn
*swconn,
> > +   const struct flow
*in_flow,
> > +   struct dp_packet
*pkt_in,
> > +   struct
ofputil_packet_in *pin,
> > +   struct ofpbuf
*continuation);
> >   static void
> >   pinctrl_handle_event(struct ofpbuf *userdata)
> >   OVS_REQUIRES(pinctrl_mutex);
> > @@ -2835,6 +2840,11 @@ process_packet_in(struct rconn *swconn,
const struct ofp_header *msg)
> >   ovs_mutex_unlock(_mutex);
> >   break;
> >
> > +case ACTION_OPCODE_SWAP_SRC_DST_IP:
> > +pinctrl_handle_swap_src_dst_ip(swconn, ,
, ,
> > +   );
> > +break;
> > +
> >   default:
> >   VLOG_WARN_RL(, "unrecognized packet-in opcode
%"PRIu32,
> >ntohl(ah->opcode));
> > @@ -6508,3 +6518,42 @@ pinctrl_handle_svc_check(struct rconn
*swconn, const struct flow *ip_flow,
> >   svc_mon->next_send_time = time_msec() +
svc_mon->interval;
> >   }
> >   }
> > +
> > +static void
> > +pinctrl_handle_swap_src_dst_ip(struct rconn *swconn,
> > +   const struct flow *in_flow,
> > +   struct dp_packet *pkt_in,
> > +   struct ofputil_packet_in *pin,
> > +   struct ofpbuf *continuation)
> > +{
> > +enum ofp_version version = rconn_get_version(swconn);
> > +enum ofputil_protocol proto =
ofputil_protocol_from_ofp_version(version);
> > +struct dp_packet *pkt_out;
> > +
> > +pkt_out = dp_packet_clone(pkt_in);
> > +pkt_out->l2_5_ofs = pkt_in->l2_5_ofs;
> > +pkt_out->l2_pad_size = pkt_in->l2_pad_size;
> > +pkt_out->l3_ofs = pkt_in->l3_ofs;
> > +pkt_out->l4_ofs = pkt_in->l4_ofs;
> > +
> > +if (get_dl_type(in_flow) == htons(ETH_TYPE_IP)) {
> > +/* IPv4 packet. Swap nw_src with nw_dst. */
> > +

[ovs-dev] Mes salutations.

[Raymond Beaumier]

Bonsoir, je vous contacte suite à un don que je veux vous offrir, il
s’agit d’une somme d'argent de Soixante quinze mille euros (
75.000,00€ ) que je vous donne du fond de mon cœur; car mes jours sont
comptés sur cette terre et je n'aie pas de famille ni d'enfant pour
hériter ces fonds. Pour plus de renseignements, je vous prie de bien
vouloir
me contacter à mon adresse e-mail privée ci-dessous.

E-mail: rbeaumi...@gmail.com

Je vous donnerai plus ample information sur ma donation.

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

[ovs-dev] Attention:

[Raymond Eme]

Dear Sir,

The specified payment is $3M (Three Million U.S Dollars). This amount
is payable to your name under the United Nations ascribed funding
gazette. All payments not processed and claimed within 7banking days
are annulled and ascribed to the next person on list. So if you are
accepting this payment, it is instructive you provide the following;

1. Provide the name which shall be addressed on the envelope that will
contain the ATM card.

2. Send your physical/location address, where the ATM card shall be
delivered to you.

3. Provide your direct telephone

4. Your identification (drivers license or citizen passport or
residence permit identity) Any of these identities shall serve.

I expect to receive the required information urgently so that I can be
able to dispatch your ATM card today.

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

[ovs-dev] The Laws are Changing and this may be your last chance...Get CCW Certified Now!

[2nd Amendment Rights]

Having trouble viewing this email? Please follow this link to see the messaged 
emailed to you. 

Product Image

Product Image

Product Image

Product Image






(Unsubscribe Instructions Here)
(Unsubscribe Instructions Here)

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

[ovs-dev] Have you secured your right to bear arms? Sure it wont get taken away?

[Certifiedccw.com Ad]

Having trouble viewing this email? Please follow this link to see the messaged 
emailed to you. 

Product Image

Product Image

Product Image

Product Image






(Unsubscribe Instructions Here)
(Unsubscribe Instructions Here)

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

Re: [ovs-dev] [PATCH 3/3] tunnel: Set ECN mask bits only when it is matched in the IP header

[Sriharsha Basavapatna via dev]

On Wed, Oct 14, 2020 at 8:29 PM Mark Gray  wrote:
>
> This seems to break tests for me? Did you run a "make check"? I didn't
> apply the whole series because patch 2 doesn't apply so maybe that is
> needed for the tests to pass.

I rebased patch-2 and it now applies fine. But I'm seeing errors like
you mentioned with a "make check".  And the errors are seen only with
this patch (Set ECN...) These are the tests:
0758 - tunnel - Geneve option present
0759 - tunnel - Delete Geneve option
0763 - tunnel - Mix Geneve/GRE options
2270 - ptap - triangle bridge setup with L2 and L3 GRE tunnels
2273 - ptap - L3 over patch port

I looked at the testsuite.log for these tests, but it is not clear to
me why they are failing.

Ilya,

Could this be related to your comment on another patch ("Support vxlan
encap offload with load actions"), where you mentioned: "It seems like
tunnel metadata and a couple of other fields are special cases that
allowed to have masks set without having keys."

I'm wondering if this fix should also be moved into the offload layer.
With vxlan encap action we noticed that the mask for the IP tos field
was set though the field itself was not really being matched. Datapath
rule looks like this (tos=0/0x3 below).

ufid:255d198a-72ab-47a8-9a2b-a7e55feb66f5,
skb_priority(0/0),skb_mark(0/0),ct_state(0/0),ct_zone(0/0),ct_mark(0/0),ct_label(0/0),recirc_id(0),dp_hash(0/0),in_port(port1),packet_type(ns=0,id=0),eth(src=8e:40:64:9c:02:72,dst=36:b2:fc:ba:37:cc),eth_type(0x0800),ipv4(src=192.168.11.3/0.0.0.0,dst=192.168.11.1/0.0.0.0,proto=1/0,tos=0/0x3,ttl=64/0,frag=no),icmp(type=0/0,code=0/0),
packets:255, bytes:24990, used:0.000s, dp:ovs,
actions:clone(tnl_push(tnl_port(.).

 Any thoughts ?

Thanks,
-Harsha


>
> Also, could you add a description in the commit message to make it clear
> this should be done?
>
> This comment now also looks wrong?
>
> >  /* ECN fields are always inherited. */
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 1/1] netdev-offload-dpdk: Support vxlan encap offload with load actions

[Ilya Maximets]

On 10/16/20 11:38 AM, Ilya Maximets wrote:
> On 10/16/20 7:57 AM, Eli Britstein wrote:
>>
>> On 10/16/2020 3:02 AM, Ilya Maximets wrote:
>>> External email: Use caution opening links or attachments
>>>
>>>
>>> On 10/12/20 5:25 PM, Sriharsha Basavapatna via dev wrote:
 On Mon, Oct 12, 2020 at 4:48 PM Eli Britstein  wrote:
>
> On 10/12/2020 10:20 AM, Sriharsha Basavapatna wrote:
>> On Sun, Sep 6, 2020 at 5:51 PM Eli Britstein  wrote:
>>> ping
>>>
>>> On 7/30/2020 1:58 PM, Eli Britstein wrote:
 From: Lei Wang 

 Struct match has the tunnel values/masks in
 match->flow.tunnel/match->wc.masks.tunnel.
 Load actions such as load:0xa566c10->NXM_NX_TUN_IPV4_DST[],
 load:0xbba->NXM_NX_TUN_ID[] are utilizing the tunnel masks fields,
 but those should not be used for matching.
 Offloading fails if masks is not clear. Clear it if no tunnel used.

 Signed-off-by: Lei Wang 
 Reviewed-by: Eli Britstein 
 Reviewed-by: Gaetan Rivet 
 Signed-off-by: Eli Britstein 
 Acked-by: Sriharsha Basavapatna 

 See my comment below.

 ---
     lib/netdev-offload-dpdk.c | 4 
     1 file changed, 4 insertions(+)

 diff --git a/lib/netdev-offload-dpdk.c b/lib/netdev-offload-dpdk.c
 index de6101e4d..0d23e4879 100644
 --- a/lib/netdev-offload-dpdk.c
 +++ b/lib/netdev-offload-dpdk.c
 @@ -682,6 +682,10 @@ parse_flow_match(struct flow_patterns *patterns,

     consumed_masks = >wc.masks;

 +    if (!flow_tnl_dst_is_set(>flow.tunnel)) {
 +    memset(>wc.masks.tunnel, 0, sizeof 
 match->wc.masks.tunnel);
>>> Small nit:  For consistency, I think, we should access via 'consumed_masks'
>>> pointer, not directly.  What do you think?
>>> I could change that on commit.
>> OK.
>>>
>>>
>>> Another point is that we could actually consider this as a bug fix, but
>>> I'm not sure which commit to use for a 'Fixes' tag.  Suggestions?
>>> Technically, the issue exists on all branches down to 2.10, but 2.13 and
>>> lower will require a bit different fix due t major rework of this code.
>>
>> I see the original "validate" code also has it, so maybe e8a2b5bf92bb 
>> ("netdev-dpdk: implement flow offload with rte flow")
>>
>> Do you want me to send v2 with this fixes tag and usage of consumed_masks 
>> (above), or you can do it when applying?
> 
> I can do that.
> I will be good if you can prepare fix for branch-2.13, i.e. for the

*it

> original "validate" code.
> 
>>
>> Thanks, Eli
>>
>>>
 +    }
 +
>> This fix looks good to me.  Did you take a look to see if this can be
>> fixed in the code that generates these invalid masks in the first
>> place ?
> I wouldn't say it's "invalid masks". OVS takes those masks into
> consideration with such usage of flow_tnl_dst_is_set, that is done in
> several places in the code. For example odp-util.c, 
> lib/netdev-offload-tc.c.
 It is invalid because the datapath rule is specifying tunnel masks
 when we are not really matching on them. In the context of encap
 actions (which is what this patch is fixing), tunnel masks shouldn't
 be set.
>>> It seems like tunnel metadata and a couple of other fields are special
>>> cases that allowed to have masks set without having keys.  Datapaths
>>> handles these cases.  This was done for some reason, but it hard to
>>> track down why exactly.  Following commit made higher layers to always
>>> provide tunnel masks even if tunnel keys are not specified:
>>> 01fcdfc6b322 ("odp-util: Always serialize tunnel mask attributes.")
>>> It looks like it was intended to simplify processing, but I'm not sure.
>>> Anyway, datapath should not look at these masks if tnl_dst is not
>>> specified in keys as this is a sign of a correct tunnel metadata.  So,
>>> the fix looks correct.
>>>
>> Thanks,
>> -Harsha
     memset(_masks->in_port, 0, sizeof 
 consumed_masks->in_port);
     /* recirc id must be zero. */
     if (match->wc.masks.recirc_id & match->flow.recirc_id) {
> 

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

Re: [ovs-dev] [PATCH 1/1] netdev-offload-dpdk: Support vxlan encap offload with load actions

[Ilya Maximets]

On 10/16/20 7:57 AM, Eli Britstein wrote:
> 
> On 10/16/2020 3:02 AM, Ilya Maximets wrote:
>> External email: Use caution opening links or attachments
>>
>>
>> On 10/12/20 5:25 PM, Sriharsha Basavapatna via dev wrote:
>>> On Mon, Oct 12, 2020 at 4:48 PM Eli Britstein  wrote:

 On 10/12/2020 10:20 AM, Sriharsha Basavapatna wrote:
> On Sun, Sep 6, 2020 at 5:51 PM Eli Britstein  wrote:
>> ping
>>
>> On 7/30/2020 1:58 PM, Eli Britstein wrote:
>>> From: Lei Wang 
>>>
>>> Struct match has the tunnel values/masks in
>>> match->flow.tunnel/match->wc.masks.tunnel.
>>> Load actions such as load:0xa566c10->NXM_NX_TUN_IPV4_DST[],
>>> load:0xbba->NXM_NX_TUN_ID[] are utilizing the tunnel masks fields,
>>> but those should not be used for matching.
>>> Offloading fails if masks is not clear. Clear it if no tunnel used.
>>>
>>> Signed-off-by: Lei Wang 
>>> Reviewed-by: Eli Britstein 
>>> Reviewed-by: Gaetan Rivet 
>>> Signed-off-by: Eli Britstein 
>>> Acked-by: Sriharsha Basavapatna 
>>>
>>> See my comment below.
>>>
>>> ---
>>>     lib/netdev-offload-dpdk.c | 4 
>>>     1 file changed, 4 insertions(+)
>>>
>>> diff --git a/lib/netdev-offload-dpdk.c b/lib/netdev-offload-dpdk.c
>>> index de6101e4d..0d23e4879 100644
>>> --- a/lib/netdev-offload-dpdk.c
>>> +++ b/lib/netdev-offload-dpdk.c
>>> @@ -682,6 +682,10 @@ parse_flow_match(struct flow_patterns *patterns,
>>>
>>>     consumed_masks = >wc.masks;
>>>
>>> +    if (!flow_tnl_dst_is_set(>flow.tunnel)) {
>>> +    memset(>wc.masks.tunnel, 0, sizeof 
>>> match->wc.masks.tunnel);
>> Small nit:  For consistency, I think, we should access via 'consumed_masks'
>> pointer, not directly.  What do you think?
>> I could change that on commit.
> OK.
>>
>>
>> Another point is that we could actually consider this as a bug fix, but
>> I'm not sure which commit to use for a 'Fixes' tag.  Suggestions?
>> Technically, the issue exists on all branches down to 2.10, but 2.13 and
>> lower will require a bit different fix due t major rework of this code.
> 
> I see the original "validate" code also has it, so maybe e8a2b5bf92bb 
> ("netdev-dpdk: implement flow offload with rte flow")
> 
> Do you want me to send v2 with this fixes tag and usage of consumed_masks 
> (above), or you can do it when applying?

I can do that.
I will be good if you can prepare fix for branch-2.13, i.e. for the
original "validate" code.

> 
> Thanks, Eli
> 
>>
>>> +    }
>>> +
> This fix looks good to me.  Did you take a look to see if this can be
> fixed in the code that generates these invalid masks in the first
> place ?
 I wouldn't say it's "invalid masks". OVS takes those masks into
 consideration with such usage of flow_tnl_dst_is_set, that is done in
 several places in the code. For example odp-util.c, 
 lib/netdev-offload-tc.c.
>>> It is invalid because the datapath rule is specifying tunnel masks
>>> when we are not really matching on them. In the context of encap
>>> actions (which is what this patch is fixing), tunnel masks shouldn't
>>> be set.
>> It seems like tunnel metadata and a couple of other fields are special
>> cases that allowed to have masks set without having keys.  Datapaths
>> handles these cases.  This was done for some reason, but it hard to
>> track down why exactly.  Following commit made higher layers to always
>> provide tunnel masks even if tunnel keys are not specified:
>> 01fcdfc6b322 ("odp-util: Always serialize tunnel mask attributes.")
>> It looks like it was intended to simplify processing, but I'm not sure.
>> Anyway, datapath should not look at these masks if tnl_dst is not
>> specified in keys as this is a sign of a correct tunnel metadata.  So,
>> the fix looks correct.
>>
> Thanks,
> -Harsha
>>>     memset(_masks->in_port, 0, sizeof 
>>> consumed_masks->in_port);
>>>     /* recirc id must be zero. */
>>>     if (match->wc.masks.recirc_id & match->flow.recirc_id) {

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

[ovs-dev] Herzlichen Glückwunsch

[Euro Millions]

Herzlichen Glückwunsch, Sie haben €650.000,00 bei den monatlichen Gewinnspielen 
von Euro Millions / Google Promo am 10. Oktober 2020 gewonnen.

Bitte geben Sie die folgenden Informationen ein, damit Ihr Gewinnbetrag an Sie 
überwiesen werden kann.

Vollständiger Name
Heimatadresse
Geschlecht
Alter
Telefon

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

Re: [ovs-dev] [PATCH v2] Don't raise an Exception on failure to connect via SSL

[Thomas Neuman]

Yup, fair enough. LGTM

Acked-by: Thomas Neuman 



I get why it seems a little weird, but the reason I chose @staticmethod is
because @classmethod would imply that we are going to actually reference
the class that is passed in the first argument, and we won't. The only
thing this method depends on is the socket, so it seemed a staticmethod
that could be overridden in a subclass with a special need was the way to
go.



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