Re: [ovs-dev] [ovn] ovn-controller high memory consumption with sbrec_server_has_##table##_table - enabled codepath

2023-07-24 Thread Vladislav Odintsov
Hi Dumitru,

I just wanted to ask wether you need any help (maybe, testing) in this?
I’m ready to check this on my dataset if you were successful to implement a fix.

> On 12 Jul 2023, at 12:15, Dumitru Ceara  wrote:
> 
> On 7/12/23 00:01, Ilya Maximets wrote:
>> On 7/11/23 19:01, Dumitru Ceara wrote:
>>> On 7/11/23 18:33, Vladislav Odintsov wrote:
 Hi Dumitru,
 
 The system on which I reproduced this issue is running 22.09.x version. 
 I’ve tried to upgrade ovn-controller to main branch + your patch. Please, 
 note that it has test error: [1].
 After two minutes after upgrade it still consumed 3.3G.
 
>>> 
>>> Ack, I need to re-think the patch then.  Maybe a hard deadline to run
>>> malloc_trim() at least once every X seconds.  I'll see what I can come
>>> up with.
>>> 
 I tried to backport your patch to 22.09, it required to backport also this 
 commit: [2] and it failed some tests: [3].
 
 But I’ve got general question: prior to commit that I mentioned in initial 
 mail, ovn-controller even didn’t try load such amount of data. And now it 
 does and IIUC, your patch just releases memory that was freed after 
 ovn-controller fully loaded.
 I’m wonder wether it should load that excess data at all? Seems like it 
 did.
 
>>> 
>>> Looking again at 1b0dbde94070 ("ovn-controller: Only set monitor
>>> conditions on available tables.") it's kind of expected indeed:
>>> 
>>> Initially all tables are "unavailable" because we didn't get the schema
>>> so we don't set any condition for any table.
>>> 
>>> After ovn-controller connects to the SB for the first time it will
>>> determine that the SB tables are in the schema so it will explicitly add
>>> them to the monitor condition and restrict the SB data it is interested in.
>>> 
>>> Maybe we need to change the IDL/CS modules to wait with the
>>> monitor_cond/monitor_cond_since until instructed by the client
>>> (ovn-controller).  Ilya do you have any thoughts on this matter?
>> 
>> So, AFAICT, the issue is that we're running with 
>> 'monitor_everything_by_default'
>> option, the default condition is 'true' and the monitor request for the main
>> database is sent out immediately after receiving the schema, so the 
>> application
>> has no time to react.
>> 
>> I think, there are few possible solutions for this:
>> 
>> 1. Introduce a new state in the CS state machine, e.g.
>>   CS_S_SERVER_SCHEMA_RCEIVED, and move out from this state in the run()
>>   callback.  This way the application will have a chance to set up conditions
>>   before they are sent.  Slightly not intuitive.
>> 
>> 2. A variation on what you suggested, i.e. enter the 
>> CS_S_SERVER_SCHEMA_RCEIVED
>>   state and wait for some sort of the signal from the application to proceed.
>>   Sounds a bit counter-intuitive for an IDL user.
>> 
>> 3. Introduce an application callback that can be called from the
>>   ovsdb_idl_compose_monitor_request() the same way as this function is 
>> getting
>>   called form the ovsdb_cs_send_monitor_request().  An application will be
>>   able to influence conditions before they are sent.
>>   Might be tricky due to new->req->ack state transition.
>> 
>> 4. Make the default condition configurable, e.g. by an additional argument
>>   'default_condition' = true/false for an ovsdb_idl_create().  This way the
>>   application will not get any data until conditions are actually set.
>> 
>> 5. Or it maybe just a separate config function that will set default 
>> conditions
>>   to 'false' and will need to be called before the first run().
>> 
>> 6. Change behavior of 'monitor_everything_by_default' argument.  Make it
>>   actually add all the tables to the monitor, but with the 'false' condition.
>>   Result should technically be the same.  Might be tricky to get right though
>>   with all the backward compatibility.
>> 
>> Option 5 might be the better option of these.
>> 
>> What do you think?
>> 
> 
> I think option 5 sounds the simplest to implement indeed.  It also
> doesn't induce any compatibility issues as you mentioned.
> 
> The only "issue" is we'd probably want this backported to stable OVN
> releases so it means we need to bump the submodule version to an
> unreleased version of OVS.  But that's an OVN problem and we discussed
> similar instances of it before.
> 
> I'll prepare a patch soon.
> 
> Best regards,
> Dumitru


Regards,
Vladislav Odintsov

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


Re: [ovs-dev] [PATCH ovn] fix missing documentation of ovn-ic arguments

2023-07-24 Thread 0-day Robot
Bleep bloop.  Greetings Felix Huettner, 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 lacks whitespace around operator
WARNING: Line lacks whitespace around operator
WARNING: Line lacks whitespace around operator
#21 FILE: ic/ovn-ic.c:109:
  --ic-nb-db=DATABASE   connect to ovn-ic-nb database at DATABASE\n\

WARNING: Line lacks whitespace around operator
WARNING: Line lacks whitespace around operator
WARNING: Line lacks whitespace around operator
#23 FILE: ic/ovn-ic.c:111:
  --ic-sb-db=DATABASE   connect to ovn-ic-sb database at DATABASE\n\

Lines checked: 38, Warnings: 6, 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


[ovs-dev] [PATCH ovn] northd: support binding remote ports in ovn-northd

2023-07-24 Thread Lorenzo Bianconi
ovn supports creating remote logical ports. An user
can set requested-chassis option for a logical switch port
to the remote chassis and ovn-northd can bind it to that chassis.
This is required for OVN IC in ovn-k8s. Right now ovn-k8s
ovnkube-controller after creating a remote logical port, sets the
chassis column of the corresponding port binding in SB DB to the
remote chassis. This process can be authomized in ovn-northd.

Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=2217930
Signed-off-by: Lorenzo Bianconi 
---
 ic/ovn-ic.c | 42 +++---
 northd/northd.c | 21 -
 tests/ovn-ic.at |  2 ++
 tests/ovn-northd.at | 20 
 tests/ovn.at| 27 +++
 5 files changed, 72 insertions(+), 40 deletions(-)

diff --git a/ic/ovn-ic.c b/ic/ovn-ic.c
index 6f31037ec..c12e345ed 100644
--- a/ic/ovn-ic.c
+++ b/ic/ovn-ic.c
@@ -506,20 +506,6 @@ get_lrp_address_for_sb_pb(struct ic_context *ctx,
 return peer->n_mac ? *peer->mac : NULL;
 }
 
-static const struct sbrec_chassis *
-find_sb_chassis(struct ic_context *ctx, const char *name)
-{
-const struct sbrec_chassis *key =
-sbrec_chassis_index_init_row(ctx->sbrec_chassis_by_name);
-sbrec_chassis_index_set_name(key, name);
-
-const struct sbrec_chassis *chassis =
-sbrec_chassis_index_find(ctx->sbrec_chassis_by_name, key);
-sbrec_chassis_index_destroy_row(key);
-
-return chassis;
-}
-
 static void
 sync_lsp_tnl_key(const struct nbrec_logical_switch_port *lsp,
  int64_t isb_tnl_key)
@@ -622,13 +608,10 @@ sync_local_port(struct ic_context *ctx,
 
 /* For each remote port:
  *   - Sync from ISB to NB
- *   - Sync gateway from ISB to SB
  */
 static void
-sync_remote_port(struct ic_context *ctx,
- const struct icsbrec_port_binding *isb_pb,
- const struct nbrec_logical_switch_port *lsp,
- const struct sbrec_port_binding *sb_pb)
+sync_remote_port(const struct icsbrec_port_binding *isb_pb,
+ const struct nbrec_logical_switch_port *lsp)
 {
 /* Sync address from ISB to NB */
 if (isb_pb->address[0]) {
@@ -645,25 +628,6 @@ sync_remote_port(struct ic_context *ctx,
 
 /* Sync tunnel key from ISB to NB */
 sync_lsp_tnl_key(lsp, isb_pb->tunnel_key);
-
-/* Sync gateway from ISB to SB */
-if (isb_pb->gateway[0]) {
-if (!sb_pb->chassis || strcmp(sb_pb->chassis->name, isb_pb->gateway)) {
-const struct sbrec_chassis *chassis =
-find_sb_chassis(ctx, isb_pb->gateway);
-if (!chassis) {
-VLOG_DBG("Chassis %s is not found in SB, syncing from ISB "
- "to SB skipped for logical port %s.",
- isb_pb->gateway, lsp->name);
-return;
-}
-sbrec_port_binding_set_chassis(sb_pb, chassis);
-}
-} else {
-if (sb_pb->chassis) {
-sbrec_port_binding_set_chassis(sb_pb, NULL);
-}
-}
 }
 
 static void
@@ -813,7 +777,7 @@ port_binding_run(struct ic_context *ctx,
 if (!sb_pb) {
 continue;
 }
-sync_remote_port(ctx, isb_pb, lsp, sb_pb);
+sync_remote_port(isb_pb, lsp);
 }
 } else {
 VLOG_DBG("Ignore lsp %s on ts %s with type %s.",
diff --git a/northd/northd.c b/northd/northd.c
index b9605862e..618c79c61 100644
--- a/northd/northd.c
+++ b/northd/northd.c
@@ -3773,11 +3773,30 @@ ovn_port_update_sbrec(struct ovsdb_idl_txn *ovnsb_txn,
 sbrec_port_binding_set_tunnel_key(op->sb, op->tunnel_key);
 }
 
+bool up = false;
+/* ovn-northd is supposed to set port_binding for remote ports
+ * if requested chassis is marked as remote
+ */
+if (op->nbsp && lsp_is_remote(op->nbsp)) {
+const struct sbrec_chassis *chassis_sb = NULL;
+const char *requested_chassis = smap_get(
+>nbsp->options, "requested-chassis");
+if (requested_chassis) {
+chassis_sb = chassis_lookup(
+sbrec_chassis_by_name, sbrec_chassis_by_hostname,
+requested_chassis);
+if (chassis_sb) {
+up = smap_get_bool(_sb->other_config,
+   "is-remote", false);
+}
+}
+sbrec_port_binding_set_chassis(op->sb, chassis_sb);
+}
+
 /* ovn-controller will update 'Port_Binding.up' only if it was explicitly
  * set to 'false'.
  */
 if (!op->sb->n_up) {
-bool up = false;
 sbrec_port_binding_set_up(op->sb, , 1);
 }
 }
diff --git a/tests/ovn-ic.at b/tests/ovn-ic.at
index ceee45092..05c9b2825 100644
--- a/tests/ovn-ic.at
+++ b/tests/ovn-ic.at
@@ -337,6 +337,7 @@ ovn-nbctl lsp-set-addresses lsp-ts1-lr1 router
 ovn-nbctl lsp-set-type lsp-ts1-lr1 router
 ovn-nbctl 

[ovs-dev] [PATCH ovn] fix missing documentation of ovn-ic arguments

2023-07-24 Thread Felix Huettner via dev
the arguments for the interconnect database where missing.

Signed-off-by: Felix Huettner 
---
 ic/ovn-ic.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/ic/ovn-ic.c b/ic/ovn-ic.c
index 6f31037ec..db7e86bc1 100644
--- a/ic/ovn-ic.c
+++ b/ic/ovn-ic.c
@@ -106,11 +106,16 @@ Options:\n\
 (default: %s)\n\
   --ovnsb-db=DATABASE   connect to ovn-sb database at DATABASE\n\
 (default: %s)\n\
+  --ic-nb-db=DATABASE   connect to ovn-ic-nb database at DATABASE\n\
+(default: %s)\n\
+  --ic-sb-db=DATABASE   connect to ovn-ic-sb database at DATABASE\n\
+(default: %s)\n\
   --unixctl=SOCKET  override default control socket name\n\
   -h, --helpdisplay this help message\n\
   -o, --options list available options\n\
   -V, --version display version information\n\
-", program_name, program_name, default_nb_db(), default_sb_db());
+", program_name, program_name, default_nb_db(), default_sb_db(),
+default_ic_nb_db(), default_ic_sb_db());
 daemon_usage();
 vlog_usage();
 stream_usage("database", true, true, false);
--
2.41.0

Diese E Mail enthält möglicherweise vertrauliche Inhalte und ist nur für die 
Verwertung durch den vorgesehenen Empfänger bestimmt.
Sollten Sie nicht der vorgesehene Empfänger sein, setzen Sie den Absender bitte 
unverzüglich in Kenntnis und löschen diese E Mail.

Hinweise zum Datenschutz finden Sie hier.


This e-mail may contain confidential content and is intended only for the 
specified recipient/s.
If you are not the intended recipient, please inform the sender immediately and 
delete this e-mail.

Information on data protection can be found 
here.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH net-next 4/7] net: openvswitch: add misc error drop reasons

2023-07-24 Thread Aaron Conole
Adrian Moreno  writes:

> Use drop reasons from include/net/dropreason-core.h when a reasonable
> candidate exists.
>
> Signed-off-by: Adrian Moreno 
> ---
>  net/openvswitch/actions.c   | 17 ++---
>  net/openvswitch/conntrack.c |  3 ++-
>  net/openvswitch/drop.h  |  6 ++
>  3 files changed, 18 insertions(+), 8 deletions(-)
>
> diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c
> index 9279bb186e9f..42fa1e7eb912 100644
> --- a/net/openvswitch/actions.c
> +++ b/net/openvswitch/actions.c

Did you consider putting in a drop reason when one of the actions fails
setting err?  For example, if dec_ttl fails with some error other than
EHOSTUNREACH, it will drop into the kfree_skb() case... maybe we should
have an action_failed drop reason that can be passed there.

> @@ -782,7 +782,7 @@ static int ovs_vport_output(struct net *net, struct sock 
> *sk,
>   struct vport *vport = data->vport;
>  
>   if (skb_cow_head(skb, data->l2_len) < 0) {
> - kfree_skb(skb);
> + kfree_skb_reason(skb, SKB_DROP_REASON_NOMEM);
>   return -ENOMEM;
>   }
>  
> @@ -853,6 +853,7 @@ static void ovs_fragment(struct net *net, struct vport 
> *vport,
>struct sk_buff *skb, u16 mru,
>struct sw_flow_key *key)
>  {
> + enum ovs_drop_reason reason;
>   u16 orig_network_offset = 0;
>  
>   if (eth_p_mpls(skb->protocol)) {
> @@ -862,6 +863,7 @@ static void ovs_fragment(struct net *net, struct vport 
> *vport,
>  
>   if (skb_network_offset(skb) > MAX_L2_LEN) {
>   OVS_NLERR(1, "L2 header too long to fragment");
> + reason = OVS_DROP_FRAG_L2_TOO_LONG;
>   goto err;
>   }
>  
> @@ -902,12 +904,13 @@ static void ovs_fragment(struct net *net, struct vport 
> *vport,
>   WARN_ONCE(1, "Failed fragment ->%s: eth=%04x, MRU=%d, MTU=%d.",
> ovs_vport_name(vport), ntohs(key->eth.type), mru,
> vport->dev->mtu);
> + reason = OVS_DROP_FRAG_INVALID_PROTO;
>   goto err;
>   }
>  
>   return;
>  err:
> - kfree_skb(skb);
> + kfree_skb_reason(skb, reason);
>  }
>  
>  static void do_output(struct datapath *dp, struct sk_buff *skb, int out_port,
> @@ -934,10 +937,10 @@ static void do_output(struct datapath *dp, struct 
> sk_buff *skb, int out_port,
>  
>   ovs_fragment(net, vport, skb, mru, key);
>   } else {
> - kfree_skb(skb);
> + kfree_skb_reason(skb, SKB_DROP_REASON_PKT_TOO_BIG);
>   }
>   } else {
> - kfree_skb(skb);
> + kfree_skb_reason(skb, SKB_DROP_REASON_DEV_READY);
>   }
>  }
>  
> @@ -1011,7 +1014,7 @@ static int dec_ttl_exception_handler(struct datapath 
> *dp, struct sk_buff *skb,
>   return clone_execute(dp, skb, key, 0, nla_data(actions),
>nla_len(actions), true, false);
>  
> - consume_skb(skb);
> + kfree_skb_reason(skb, OVS_DROP_IP_TTL);
>   return 0;
>  }
>  
> @@ -1564,7 +1567,7 @@ static int clone_execute(struct datapath *dp, struct 
> sk_buff *skb,
>   /* Out of per CPU action FIFO space. Drop the 'skb' and
>* log an error.
>*/
> - kfree_skb(skb);
> + kfree_skb_reason(skb, OVS_DROP_DEFERRED_LIMIT);
>  
>   if (net_ratelimit()) {
>   if (actions) { /* Sample action */
> @@ -1616,7 +1619,7 @@ int ovs_execute_actions(struct datapath *dp, struct 
> sk_buff *skb,
>   if (unlikely(level > OVS_RECURSION_LIMIT)) {
>   net_crit_ratelimited("ovs: recursion limit reached on datapath 
> %s, probable configuration error\n",
>ovs_dp_name(dp));
> - kfree_skb(skb);
> + kfree_skb_reason(skb, OVS_DROP_RECURSION_LIMIT);
>   err = -ENETDOWN;
>   goto out;
>   }
> diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
> index fa955e892210..b03ebd4a8fae 100644
> --- a/net/openvswitch/conntrack.c
> +++ b/net/openvswitch/conntrack.c
> @@ -29,6 +29,7 @@
>  #include 
>  
>  #include "datapath.h"
> +#include "drop.h"
>  #include "conntrack.h"
>  #include "flow.h"
>  #include "flow_netlink.h"
> @@ -1035,7 +1036,7 @@ int ovs_ct_execute(struct net *net, struct sk_buff *skb,
>  
>   skb_push_rcsum(skb, nh_ofs);
>   if (err)
> - kfree_skb(skb);
> + kfree_skb_reason(skb, OVS_DROP_CONNTRACK);
>   return err;
>  }
>  
> diff --git a/net/openvswitch/drop.h b/net/openvswitch/drop.h
> index 2440c836727f..744b8d1b93a3 100644
> --- a/net/openvswitch/drop.h
> +++ b/net/openvswitch/drop.h
> @@ -12,6 +12,12 @@
>   R(OVS_DROP_EXPLICIT_ACTION) \
>   R(OVS_DROP_EXPLICIT_ACTION_ERROR)   \
>   R(OVS_DROP_METER)   \
> + 

Re: [ovs-dev] [PATCH net-next 7/7] selftests: openvswitch: add explicit drop testcase

2023-07-24 Thread Aaron Conole
Adrian Moreno  writes:

> Make ovs-dpctl.py support explicit drops as:
> "drop" -> implicit empty-action drop
> "drop(0)" -> explicit non-error action drop
> "drop(42)" -> explicit error action drop
>
> Signed-off-by: Adrian Moreno 
> ---
>  .../selftests/net/openvswitch/openvswitch.sh  | 25 +++
>  .../selftests/net/openvswitch/ovs-dpctl.py| 18 ++---
>  2 files changed, 39 insertions(+), 4 deletions(-)
>
> diff --git a/tools/testing/selftests/net/openvswitch/openvswitch.sh 
> b/tools/testing/selftests/net/openvswitch/openvswitch.sh
> index a10c345f40ef..398a69f1c923 100755
> --- a/tools/testing/selftests/net/openvswitch/openvswitch.sh
> +++ b/tools/testing/selftests/net/openvswitch/openvswitch.sh
> @@ -217,6 +217,31 @@ test_drop_reason() {
>   return 1
>   fi
>  
> + # Drop UDP 6000 traffic with an explicit action and an error code.
> + ovs_add_flow "test_drop_reason" dropreason \
> + 
> "in_port(1),eth(),eth_type(0x0800),ipv4(src=172.31.110.10,proto=17),udp(dst=6000)"
>  \
> +'drop(42)'
> + # Drop UDP 7000 traffic with an explicit action with no error code.
> + ovs_add_flow "test_drop_reason" dropreason \
> + 
> "in_port(1),eth(),eth_type(0x0800),ipv4(src=172.31.110.10,proto=17),udp(dst=7000)"
>  \
> +'drop(0)'
> +
> + ovs_drop_record_and_run \
> +"test_drop_reason" ip netns exec client nc -i 1 -zuv 
> 172.31.110.20 6000
> + ovs_drop_reason_count 0x30003 # OVS_DROP_EXPLICIT_ACTION_ERROR
> + if [[ "$?" -ne "1" ]]; then
> + info "Did not detect expected explicit error drops: $?"
> + return 1
> + fi
> +
> + ovs_drop_record_and_run \
> +"test_drop_reason" ip netns exec client nc -i 1 -zuv 
> 172.31.110.20 7000
> + ovs_drop_reason_count 0x30002 # OVS_DROP_EXPLICIT_ACTION
> + if [[ "$?" -ne "1" ]]; then
> + info "Did not detect expected explicit drops: $?"
> + return 1
> + fi
> +
>   return 0
>  }
>  
> diff --git a/tools/testing/selftests/net/openvswitch/ovs-dpctl.py 
> b/tools/testing/selftests/net/openvswitch/ovs-dpctl.py
> index 0bc944f36e02..de6db59ab115 100644
> --- a/tools/testing/selftests/net/openvswitch/ovs-dpctl.py
> +++ b/tools/testing/selftests/net/openvswitch/ovs-dpctl.py
> @@ -448,7 +448,7 @@ class ovsactions(nla):
>  elif field[0] == "OVS_ACTION_ATTR_TRUNC":
>  print_str += "trunc(%d)" % int(self.get_attr(field[0]))
>  elif field[0] == "OVS_ACTION_ATTR_DROP":
> -print_str += "drop"
> +print_str += "drop(%d)" % int(self.get_attr(field[0]))
>  elif field[1] == "flag":
>  if field[0] == "OVS_ACTION_ATTR_CT_CLEAR":
>  print_str += "ct_clear"
> @@ -470,9 +470,19 @@ class ovsactions(nla):
>  parsed = False
>  while len(actstr) != 0:
>  if actstr.startswith("drop"):
> -# for now, drops have no explicit action, so we
> -# don't need to set any attributes.  The final
> -# act of the processing chain will just drop the packet
> +# If no reason is provided, the implicit drop is used (i.e no
> +# action). If some reason is given, an explicit action is 
> used.
> +actstr, reason = parse_extract_field(
> +actstr,
> +"drop(",
> +"([0-9]+)",
> +lambda x: int(x, 0),
> +False,
> +None,
> +)
> +if reason is not None:
> +self["attrs"].append(["OVS_ACTION_ATTR_DROP", reason])
> +
>  return

If we decide to validate that drop() action is the last one, we can
probably also remove this return.

>  
>  elif parse_starts_block(actstr, "^(\d+)", False, True):

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


Re: [ovs-dev] [PATCH net-next 2/7] net: openvswitch: add explicit drop action

2023-07-24 Thread Aaron Conole
Adrian Moreno  writes:

> From: Eric Garver 
>
> This adds an explicit drop action. This is used by OVS to drop packets
> for which it cannot determine what to do. An explicit action in the
> kernel allows passing the reason _why_ the packet is being dropped or
> zero to indicate no particular error happened (i.e: OVS intentionally
> dropped the packet).
>
> Since the error codes coming from userspace mean nothing for the kernel,
> we squash all of them into only two drop reasons:
> - OVS_DROP_EXPLICIT_ACTION_ERROR to indicate a non-zero value was passed
> - OVS_DROP_EXPLICIT_ACTION to indicate a zero value was passed (no
>   error)
>
> e.g. trace all OVS dropped skbs
>
>  # perf trace -e skb:kfree_skb --filter="reason >= 0x3"
>  [..]
>  106.023 ping/2465 skb:kfree_skb(skbaddr: 0xa0e8765f2000, \
>   location:0xc0d9b462, protocol: 2048, reason: 196610)
>
> reason: 196610 --> 0x30002 (OVS_DROP_EXPLICIT_ACTION)
>
> Signed-off-by: Eric Garver 
> Signed-off-by: Adrian Moreno 
> ---
>  include/uapi/linux/openvswitch.h | 2 ++
>  net/openvswitch/actions.c| 9 +
>  net/openvswitch/drop.h   | 2 ++
>  net/openvswitch/flow_netlink.c   | 8 +++-
>  tools/testing/selftests/net/openvswitch/ovs-dpctl.py | 3 +++
>  5 files changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/include/uapi/linux/openvswitch.h 
> b/include/uapi/linux/openvswitch.h
> index e94870e77ee9..efc82c318fa2 100644
> --- a/include/uapi/linux/openvswitch.h
> +++ b/include/uapi/linux/openvswitch.h
> @@ -965,6 +965,7 @@ struct check_pkt_len_arg {
>   * start of the packet or at the start of the l3 header depending on the 
> value
>   * of l3 tunnel flag in the tun_flags field of OVS_ACTION_ATTR_ADD_MPLS
>   * argument.
> + * @OVS_ACTION_ATTR_DROP: Explicit drop action.
>   *
>   * Only a single header can be set with a single %OVS_ACTION_ATTR_SET.  Not 
> all
>   * fields within a header are modifiable, e.g. the IPv4 protocol and fragment
> @@ -1002,6 +1003,7 @@ enum ovs_action_attr {
>   OVS_ACTION_ATTR_CHECK_PKT_LEN, /* Nested OVS_CHECK_PKT_LEN_ATTR_*. */
>   OVS_ACTION_ATTR_ADD_MPLS, /* struct ovs_action_add_mpls. */
>   OVS_ACTION_ATTR_DEC_TTL,  /* Nested OVS_DEC_TTL_ATTR_*. */
> + OVS_ACTION_ATTR_DROP, /* u32 error code. */
>  
>   __OVS_ACTION_ATTR_MAX,/* Nothing past this will be accepted
>  * from userspace. */
> diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c
> index af676dcac2b4..194379d58b62 100644
> --- a/net/openvswitch/actions.c
> +++ b/net/openvswitch/actions.c
> @@ -1485,6 +1485,15 @@ static int do_execute_actions(struct datapath *dp, 
> struct sk_buff *skb,
>   return dec_ttl_exception_handler(dp, skb,
>key, a);
>   break;
> +
> + case OVS_ACTION_ATTR_DROP: {
> + enum ovs_drop_reason reason = nla_get_u32(a)
> + ? OVS_DROP_EXPLICIT_ACTION_ERROR
> + : OVS_DROP_EXPLICIT_ACTION;
> +
> + kfree_skb_reason(skb, reason);
> + return 0;
> + }
>   }
>  
>   if (unlikely(err)) {
> diff --git a/net/openvswitch/drop.h b/net/openvswitch/drop.h
> index cdd10629c6be..f9e9c1610f6b 100644
> --- a/net/openvswitch/drop.h
> +++ b/net/openvswitch/drop.h
> @@ -9,6 +9,8 @@
>  
>  #define OVS_DROP_REASONS(R)  \
>   R(OVS_DROP_FLOW)\
> + R(OVS_DROP_EXPLICIT_ACTION) \
> + R(OVS_DROP_EXPLICIT_ACTION_ERROR)   \
>   /* deliberate comment for trailing \ */
>  
>  enum ovs_drop_reason {
> diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c
> index 41116361433d..244280922a14 100644
> --- a/net/openvswitch/flow_netlink.c
> +++ b/net/openvswitch/flow_netlink.c
> @@ -38,6 +38,7 @@
>  #include 
>  #include 
>  
> +#include "drop.h"
>  #include "flow_netlink.h"
>  
>  struct ovs_len_tbl {
> @@ -61,6 +62,7 @@ static bool actions_may_change_flow(const struct nlattr 
> *actions)
>   case OVS_ACTION_ATTR_RECIRC:
>   case OVS_ACTION_ATTR_TRUNC:
>   case OVS_ACTION_ATTR_USERSPACE:
> + case OVS_ACTION_ATTR_DROP:
>   break;
>  
>   case OVS_ACTION_ATTR_CT:
> @@ -2394,7 +2396,7 @@ static void ovs_nla_free_nested_actions(const struct 
> nlattr *actions, int len)
>   /* Whenever new actions are added, the need to update this
>* function should be considered.
>*/
> - BUILD_BUG_ON(OVS_ACTION_ATTR_MAX != 23);
> + BUILD_BUG_ON(OVS_ACTION_ATTR_MAX != 24);
>  
>   if (!actions)
>   return;
> @@ -3182,6 +3184,7 @@ static int __ovs_nla_copy_actions(struct net *net, 
> const struct 

Re: [ovs-dev] [PATCH net-next 0/7] openvswitch: add drop reasons

2023-07-24 Thread Aaron Conole
Adrian Moreno  writes:

> There is currently a gap in drop visibility in the openvswitch module.
> This series tries to improve this by adding a new drop reason subsystem
> for OVS.
>
> Apart from adding a new drop reasson subsystem and some common drop
> reasons, this series takes Eric's preliminary work [1] on adding an
> explicit drop action and integrates it into the same subsystem.
>
> This series also adds some selftests and so it requires [2] to be
> applied first.
>
> A limitation of this series is that it does not report upcall errors.
> The reason is that there could be many sources of upcall drops and the
> most common one, which is the netlink buffer overflow, cannot be
> reported via kfree_skb() because the skb is freed in the netlink layer
> (see [3]). Therefore, using a reason for the rare events and not the
> common one would be even more misleading. I'd propose we add (in a
> follow up patch) a tracepoint to better report upcall errors.

I guess you meant to add RFC tag to this, since it depends on other
series that aren't accepted yet.

If it's okay, I will pull in your patch 5/7 when I re-post my flow
additions series, since it will need to be added there at some point
anyway.

> [1] https://lore.kernel.org/netdev/202306300609.tdrdzscy-...@intel.com/T/
> [2] 
> https://lore.kernel.org/all/9375ccbc-dd40-9998-dde5-c94e4e28f...@redhat.com/T/
>  
> [3] commit 1100248a5c5c ("openvswitch: Fix double reporting of drops in 
> dropwatch")
>
> Adrian Moreno (6):
>   net: openvswitch: add datapath flow drop reason
>   net: openvswitch: add meter drop reason
>   net: openvswitch: add misc error drop reasons
>   selftests: openvswitch: support key masks
>   selftests: openvswitch: add drop reason testcase
>   selftests: openvswitch: add explicit drop testcase
>
> Eric Garver (1):
>   net: openvswitch: add explicit drop action
>
>  include/net/dropreason.h  |   6 +
>  include/uapi/linux/openvswitch.h  |   2 +
>  net/openvswitch/actions.c |  40 --
>  net/openvswitch/conntrack.c   |   3 +-
>  net/openvswitch/datapath.c|  16 +++
>  net/openvswitch/drop.h|  33 +
>  net/openvswitch/flow_netlink.c|   8 +-
>  .../selftests/net/openvswitch/openvswitch.sh  |  92 +-
>  .../selftests/net/openvswitch/ovs-dpctl.py| 115 --
>  9 files changed, 267 insertions(+), 48 deletions(-)
>  create mode 100644 net/openvswitch/drop.h

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


Re: [ovs-dev] [PATCH] netdev-tc-offload: Fix ip protocols not offloaded in ip rewrite

2023-07-24 Thread Faicker Mo via dev
About the second change,
A large part of ip protocols do not need the checksum recalculation of themself.
There are only 6 protocols in tc csum action except for the ip header.
If a protocol need the recalculation of the checksum, may be it should add the 
special handling in TC,
because each has the different checksum calculation.



From: Ilya Maximets 
Date: 2023-07-21 22:20:55
To:  Aaron Conole ,ovs-dev 
Cc:  simon.hor...@corigine.com,pa...@nvidia.com,Faicker Mo 
,i.maxim...@ovn.org
Subject: Re: [ovs-dev] [PATCH] netdev-tc-offload: Fix ip protocols not 
offloaded in ip rewrite>On 7/20/23 17:32, Aaron Conole wrote:
>> Faicker Mo via dev  writes:
>> 
>>> The warning message is
>>> |1|tc(handler4)|WARN|can't offload rewrite of IP/IPV6 with ip_proto: X.
>>>
>>> Some ip protocols like ipip, gre and so on do not need the recalculation of
>>> the checksum of themself except for the ip header checksum recalculation
>>> in the ip header rewrite case.
>>> The tc csum action also supports IGMP, UDPLITE and SCTP.
>>> Enable the offload of the ip protocols besides the TCP, UDP and ICMP.
>>>
>>> Fixes: d6118e628988 ("netdev-tc-offloads: Verify csum flags on dump from 
>>> tc")
>>> Signed-off-by: Faicker Mo 
>>> ---
>> 
>> Hi Faicker,
>> 
>>>  lib/tc.c | 17 +++-
>>>  tests/system-offloads-traffic.at | 34 
>>>  2 files changed, 41 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/lib/tc.c b/lib/tc.c
>>> index f49048cda..501c7ceb8 100644
>>> --- a/lib/tc.c
>>> +++ b/lib/tc.c
>>> @@ -2967,22 +2967,19 @@ csum_update_flag(struct tc_flower *flower,
>>>  case TCA_PEDIT_KEY_EX_HDR_TYPE_IP6:
>>>  case TCA_PEDIT_KEY_EX_HDR_TYPE_TCP:
>>>  case TCA_PEDIT_KEY_EX_HDR_TYPE_UDP:
>>> +flower->needs_full_ip_proto_mask = true;
>>>  if (flower->key.ip_proto == IPPROTO_TCP) {
>>> -flower->needs_full_ip_proto_mask = true;
>>>  flower->csum_update_flags |= TCA_CSUM_UPDATE_FLAG_TCP;
>>>  } else if (flower->key.ip_proto == IPPROTO_UDP) {
>>> -flower->needs_full_ip_proto_mask = true;
>>>  flower->csum_update_flags |= TCA_CSUM_UPDATE_FLAG_UDP;
>>> -} else if (flower->key.ip_proto == IPPROTO_ICMP) {
>>> -flower->needs_full_ip_proto_mask = true;
>>>  } else if (flower->key.ip_proto == IPPROTO_ICMPV6) {
>>> -flower->needs_full_ip_proto_mask = true;
>>>  flower->csum_update_flags |= TCA_CSUM_UPDATE_FLAG_ICMP;
>>> -} else {
>>> -VLOG_WARN_RL(_rl,
>>> - "can't offload rewrite of IP/IPV6 with ip_proto: 
>>> %d",
>>> - flower->key.ip_proto);
>>> -break;
>>> +} else if (flower->key.ip_proto == IPPROTO_IGMP) {
>>> +flower->csum_update_flags |= TCA_CSUM_UPDATE_FLAG_IGMP;
>>> +} else if (flower->key.ip_proto == IPPROTO_UDPLITE) {
>>> +flower->csum_update_flags |= TCA_CSUM_UPDATE_FLAG_UDPLITE;
>>> +} else if (flower->key.ip_proto == IPPROTO_SCTP) {
>>> +flower->csum_update_flags |= TCA_CSUM_UPDATE_FLAG_SCTP;
>> 
>> This seems like two changes to me.
>> 
>> First change is adding additional support for these other csum update
>> flags.  This could be argued as feature.
>
>Sounds like a feature to me.
>
>> 
>> Second change is dropping the WARN message and always setting
>> needs_full_ip_proto_mask.
>
>I'm not really sure we can do this second change.
>There are protocols that require L4 checksum recalculation on IP header
>changes.  These are not only well known TCP/UDP.  For example, the DCCP
>seems to be such a protocol.  And who knows what other protocols need
>that as well.  So, we should not blindly allow all the protocols.  We
>should only allow ones that are known to not require any special handling,
>or ones for which the special handling is supported by TC.
>
>Best regards, Ilya Maximets.
>
>> 
>>>  }
>>>  /* Fall through. */
>>>  case TCA_PEDIT_KEY_EX_HDR_TYPE_ETH:
>>> diff --git a/tests/system-offloads-traffic.at 
>>> b/tests/system-offloads-traffic.at
>>> index 7215e36e2..49b145e82 100644
>>> --- a/tests/system-offloads-traffic.at
>>> +++ b/tests/system-offloads-traffic.at
>>> @@ -855,3 +855,37 @@ AT_CHECK([ovs-appctl dpctl/dump-flows 
>>> type=tc,offloaded | grep "eth_type(0x0800)
>>>  OVS_TRAFFIC_VSWITCHD_STOP
>>>  AT_CLEANUP
>>>  
>>> +AT_SETUP([offloads - fix ip protocols not offloaded in ip rewrite - 
>>> offloads enabled])
>>> +OVS_TRAFFIC_VSWITCHD_START([], [], [-- set Open_vSwitch . 
>>> other_config:hw-offload=true])
>>> +
>>> +AT_CHECK([ovs-ofctl add-flow br0 "priority=0 actions=normal"])
>>> +
>>> +ADD_NAMESPACES(at_ns0, at_ns1)
>>> +
>>> +ADD_VETH(p0, at_ns0, br0, "10.1.1.1/24")
>>> +ADD_VETH(p1, at_ns1, br0, "10.1.1.2/24")
>>> +
>>> +dnl Set up the ip field modify flow.
>>> +AT_CHECK([ovs-ofctl add-flow br0 "priority=100 
>>> in_port=ovs-p0,ip,nw_dst=10.1.1.2