Intel-Wired-Lan Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Abeni <pabeni@redhat.com>
To: Alexander Lobakin <aleksander.lobakin@intel.com>
Cc: netdev@vger.kernel.org, intel-wired-lan@lists.osuosl.org,
	Andrii Staikov <andrii.staikov@intel.com>
Subject: Re: [Intel-wired-lan] [PATCH iwl-next v2] ice: Add support for packet mirroring using hardware in switchdev mode
Date: Tue, 12 Sep 2023 18:43:22 +0200	[thread overview]
Message-ID: <a4ebf8016d35fd7a64be65e79025a384ee4b105d.camel@redhat.com> (raw)
In-Reply-To: <ad50a349-11be-36bc-fed4-94f5aab3eabd@intel.com>

On Tue, 2023-09-12 at 16:41 +0200, Alexander Lobakin wrote:
> From: Paolo Abeni <pabeni@redhat.com>
> Date: Tue, 12 Sep 2023 11:56:15 +0200
> 
> > Hi all,
> > 
> > On Tue, 2023-09-12 at 11:29 +0200, Andrii Staikov wrote:
> > > Switchdev mode allows to add mirroring rules to mirror
> > > incoming and outgoing packets to the interface's port
> > > representor. Previously, this was available only using
> > > software functionality. Add possibility to offload this
> > > functionality to the NIC hardware.
> > > 
> > > Introduce ICE_MIRROR_PACKET filter action to the
> > > ice_sw_fwd_act_type enum to identify the desired action
> > > and pass it to the hardware as well as the VSI to mirror.
> > > 
> > > Example of tc mirror command using hardware:
> > > tc filter add dev ens1f0np0 ingress protocol ip prio 1 flower
> > > src_mac b4:96:91:a5:c7:a7 skip_sw action mirred egress mirror dev eth1
> > > 
> > > ens1f0np0 - PF
> > > b4:96:91:a5:c7:a7 - source MAC address
> > > eth1 - PR of a VF to mirror to
> > > 
> > > Signed-off-by: Andrii Staikov <andrii.staikov@intel.com>
> > 
> > The amount of patches that IMHO should land only into intel-specific
> > MLs and instead reaches also netdev, recently increased.
> 
> Let's clarify what you mean by "intel-specific MLs".
> Do you mean our internal MLs and review or the open one, IWL?
> 
> IWL is mostly rudimentary. It's open, but almost nobody outside of Intel
> sits there, which means 2/3 of patches doesn't get enough attention and
> reviews. It's used by our validation as well, but that's it.
> Our internal ML for Ethernet patches works as usually. I realize roughly
> half of all patches pass it without a Reviewed-by tag and it's something
> we're actively working on. If all goes well, no patches without a proper
> review will go outside Intel's internal Ethernet MLs.
> Now, the second part,
> 
> > 
> > Please try harder to apply proper constraints to your traffic, netdev
> > is already busy enough!
> 
> Do you want us to stop CCing netdev when we send patches to the outer
> review to IWL?
> This would mean they will once again start missing enough attention from
> the outside. I hope you don't want our patches to be reviewed *only* by
> Intel folks, right? I don't feel this a good idea.
> That's why we started CCing netdev this year. And we do that when we
> send patches to IWL, i.e. outside. It's not like "ok, let's Cc netdev
> instead of going through our internal review process".
> 
> Our clients, partners (e.g. Czech RedHat), our developers, want our
> patches to have proper complex review. Dropping netdev would mean that a
> patch of some non-corpo guy will be reviewed more carefully and at the
> end will have better quality than an Intel patch, which "shouldn't
> overburden netdev".
> Saying "we'll see them when Tony sends a PR" also doesn't work well for
> me. A patch gets taken into a PR once it passes internal review, then
> validation, this always do take a while. Imagine waiting for a month for
> your patch to be sent in a PR to get a negative review, so that you have
> to repeat this process again and wait for another month to get some more
> change requests and again :D
> 
> In a couple months, no our patches will hit netdev without a proper
> Reviewed-by obtained during the internal review, let's not take corner
> cases and effectively hide our code from the world?
> I don't think you'd like to put a huge banner on netdev's lore saying
> "please also take a look at intel-wired-lan" :z I also don't want ppl to
> behave like Greg KH some time ago when he said "where's your damn
> internal RB, stop abusing LKML" in reply to my early RFC PoC sent only
> for an open discussion xD

I was under the impression that some patches landed on IWL cc-ing
netdev possibly unintentionally, e.g.:

https://lore.kernel.org/netdev/20230904021455.3944605-1-junfeng.guo@intel.com/

My intention was to raise attention on such events.

Cheers,

Paolo

_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

  reply	other threads:[~2023-09-12 16:43 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-12  9:29 [Intel-wired-lan] [PATCH iwl-next v2] ice: Add support for packet mirroring using hardware in switchdev mode Andrii Staikov
2023-09-12  9:56 ` Paolo Abeni
2023-09-12 14:41   ` Alexander Lobakin
2023-09-12 16:43     ` Paolo Abeni [this message]
2023-10-03  7:49 ` Buvaneswaran, Sujai

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=a4ebf8016d35fd7a64be65e79025a384ee4b105d.camel@redhat.com \
    --to=pabeni@redhat.com \
    --cc=aleksander.lobakin@intel.com \
    --cc=andrii.staikov@intel.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=netdev@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox