All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Ilya Maximets <i.maximets@ovn.org>
Cc: Eric Garver <eric@garver.life>, Aaron Conole <aconole@redhat.com>,
	netdev@vger.kernel.org, dev@openvswitch.org,
	Paolo Abeni <pabeni@redhat.com>,
	Eric Dumazet <edumazet@google.com>,
	"David S. Miller" <davem@davemloft.net>,
	Adrian Moreno <amorenoz@redhat.com>,
	Eelco Chaudron <echaudro@redhat.com>
Subject: Re: [ovs-dev] [PATCH net-next 2/2] net: openvswitch: add drop action
Date: Mon, 10 Jul 2023 10:01:10 -0700	[thread overview]
Message-ID: <20230710100110.52ce3d4c@kernel.org> (raw)
In-Reply-To: <096871e8-3c0b-d5d7-8e68-833ba26b3882@ovn.org>

On Mon, 10 Jul 2023 18:51:19 +0200 Ilya Maximets wrote:
> Makes sense.  I wasn't sure that's a good solution from a kernel perspective
> either.  It's better than defining all these reasons, IMO, but it's not good
> enough to be considered acceptable, I agree.
> 
> How about we define just 2 reasons, e.g. OVS_DROP_REASON_EXPLICIT_ACTION and
> OVS_DROP_REASON_EXPLICIT_ACTION_WITH_ERROR (exact names can be different) ?
> One for an explicit drop action with a zero argument and one for an explicit
> drop with non-zero argument.
> 
> The exact reason for the error can be retrieved by other means, i.e by looking
> at the datapath flow dump or OVS logs/traces.
> 
> This way we can give a user who is catching packet drop traces a signal that
> there was something wrong with an OVS flow and they can look up exact details
> from the userspace / flow dump.
> 
> The point being, most of the flows will have a zero as a drop action argument,
> i.e. a regular explicit packet drop.  It will be hard to figure out which flow
> exactly we're hitting without looking at the full flow dump.  And if the value
> is non-zero, then it should be immediately obvious which flow is to blame from
> the dump, as we should not have a lot of such flows.
> 
> This would still allow us to avoid a maintenance burden of defining every case,
> which are fairly meaningless for the kernel itself, while having 99% of the
> information we may need.
> 
> Jakub, do you think this will be acceptable?

As far as I understand what you're proposing, yes :)

> Eric, Adrian, Aaron, do you see any problems with such implementation?
> 
> P.S. There is a plan to add more drop reasons for other places in openvswitch
>      module to catch more regular types of drops like memory issues or upcall
>      failures.  So, the drop reason subsystem can be extended later.
>      The explicit drop action is a bit of an odd case here.

If you have more than ~4 OvS specific reasons, I wonder if it still
makes sense to create a reason group/subsystem for OvS (a'la WiFi)?

  reply	other threads:[~2023-07-10 17:01 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-29 20:30 [PATCH net-next 0/2] net: openvswitch: add drop action Eric Garver
2023-06-29 20:30 ` [PATCH net-next 1/2] net: openvswitch: add drop reasons Eric Garver
2023-06-29 20:30 ` [PATCH net-next 2/2] net: openvswitch: add drop action Eric Garver
2023-06-29 22:46   ` kernel test robot
2023-06-29 22:56   ` kernel test robot
2023-06-30  9:47   ` Simon Horman
2023-06-30 12:29     ` Eric Garver
2023-06-30 13:25       ` [ovs-dev] " Simon Horman
2023-07-06 12:54   ` Aaron Conole
2023-07-06 13:57     ` Eric Garver
2023-07-07 10:30       ` Ilya Maximets
2023-07-07 15:00         ` Jakub Kicinski
2023-07-07 15:29           ` Ilya Maximets
2023-07-07 16:04             ` Ilya Maximets
2023-07-07 22:06               ` Jakub Kicinski
2023-07-10 16:51                 ` Ilya Maximets
2023-07-10 17:01                   ` Jakub Kicinski [this message]
2023-07-10 18:39                     ` Ilya Maximets
2023-07-10 19:02                       ` Jakub Kicinski
2023-07-10 18:21                   ` Eric Garver
2023-07-11 20:46                     ` Aaron Conole
2023-07-12  7:53                       ` Adrian Moreno

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230710100110.52ce3d4c@kernel.org \
    --to=kuba@kernel.org \
    --cc=aconole@redhat.com \
    --cc=amorenoz@redhat.com \
    --cc=davem@davemloft.net \
    --cc=dev@openvswitch.org \
    --cc=echaudro@redhat.com \
    --cc=edumazet@google.com \
    --cc=eric@garver.life \
    --cc=i.maximets@ovn.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.