All of lore.kernel.org
 help / color / mirror / Atom feed
From: Saeed Mahameed <saeed@kernel.org>
To: Leon Romanovsky <leon@kernel.org>, Ido Schimmel <idosch@idosch.org>
Cc: Chris Mi <cmi@nvidia.com>, Jakub Kicinski <kuba@kernel.org>,
	Cong Wang <xiyou.wangcong@gmail.com>,
	Linux Kernel Network Developers <netdev@vger.kernel.org>,
	jiri@nvidia.com, kernel test robot <lkp@intel.com>
Subject: Re: [PATCH net-next v4] net: psample: Introduce stubs to remove NIC driver dependency
Date: Wed, 10 Feb 2021 21:09:41 -0800	[thread overview]
Message-ID: <30482e059a48fb35f90a7594355bc27dcd71dacc.camel@kernel.org> (raw)
In-Reply-To: <20210209064702.GB139298@unreal>

On Tue, 2021-02-09 at 08:47 +0200, Leon Romanovsky wrote:
> On Mon, Feb 08, 2021 at 07:07:35PM +0200, Ido Schimmel wrote:
> > On Mon, Feb 08, 2021 at 11:07:02AM +0200, Leon Romanovsky wrote:
> > 
> > 

[...]

> > I don't know. What are they complaining about? That psample needs
> > to be
> > installed for mlx5_core to be loaded? How come the rest of the
> > dependencies are installed?
> 
> The psample module was first dependency that caught our attention. It
> is
> here as an example of such not-needed dependency. Like Saeed said, we
> are
> interested in more general solution that will allow us to use
> external
> modules in fully dynamic mode.
> 
> Internally, as a preparation to the submission of mlx5 code that used
> nf_conntrack,
> we found that restart of firewald service will bring down our
> mlx5_core driver, because
> of such dependency.
> 
> So to answer on your question, HPC didn't complain yet, but we don't
> have any plans
> to wait till they complain.
> 
> > 
> > Or are they complaining about the size / memory footprint of
> > psample?
> > Because then they should first check mlx5_core when all of its
> > options
> > are blindly enabled as part of a distribution config.
> 
> You are too focused on psample, while Saeed and I are saying more
> general statement "I prefer to have 0 dependency on external modules
> in a HW driver."
> 
> > 
> > AFAICS, mlx5 still does not have any code that uses psample. You
> > can
> > wrap it in a config option and keep the weak dependency on psample.
> > Something like:
> > 
> > diff --git a/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
> > b/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
> > index ad45d20f9d44..d17d03d8cc8b 100644
> > --- a/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
> > +++ b/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
> > @@ -104,6 +104,15 @@ config MLX5_TC_CT
> > 
> >           If unsure, set to Y
> > 
> > +config MLX5_TC_SAMPLE
> > +       bool "MLX5 TC sample offload support"
> > +       depends on MLX5_CLS_ACT
> > +       depends on PSAMPLE || PSAMPLE=n
> > +       default n
> > +       help
> > +         Say Y here if you want to support offloading tc rules
> > that use sample
> > +          action.
> > +
> 

This won't solve anything other than compilation time dependency
between built-in modules to external modules, this is not the case.

our case is when both mlx5 and psample are modules, you can't load mlx5
without loading psample, even if you are not planning to use psample or
mlx5 psample features, which is 99.99% of the cases.

What we are asking for here is not new, and is a common practice in
netdev stack

see :
udp_tunnel_nic_ops
netfilter is full of these, see nf_ct_hook..

I don't see anything wrong with either repeating this practice for any
module or having some sort of a generic proxy in the built-in netdev
layer..





  parent reply	other threads:[~2021-02-11  5:13 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-28  1:45 [PATCH net-next v4] net: psample: Introduce stubs to remove NIC driver dependency Chris Mi
2021-01-29  5:14 ` Cong Wang
2021-01-29  6:08   ` Chris Mi
2021-01-29 20:30     ` Jakub Kicinski
2021-01-29 20:44       ` Saeed Mahameed
2021-01-29 21:47         ` Jakub Kicinski
2021-01-30 14:42       ` Ido Schimmel
2021-02-01  1:37         ` Chris Mi
2021-02-01 18:08           ` Ido Schimmel
2021-02-08  7:03             ` Leon Romanovsky
2021-02-08  8:57               ` Ido Schimmel
2021-02-08  9:07                 ` Leon Romanovsky
2021-02-08 17:07                   ` Ido Schimmel
2021-02-09  6:47                     ` Leon Romanovsky
2021-02-09  9:25                       ` Or Gerlitz
2021-02-09 10:01                         ` Leon Romanovsky
2021-02-09 10:49                           ` Or Gerlitz
2021-02-11  5:09                       ` Saeed Mahameed [this message]
2021-02-11 21:59                         ` Ido Schimmel
2021-02-12  0:41                           ` Saeed Mahameed
2021-01-29 21:50 ` Jakub Kicinski
2021-01-30  2:35   ` Chris Mi

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=30482e059a48fb35f90a7594355bc27dcd71dacc.camel@kernel.org \
    --to=saeed@kernel.org \
    --cc=cmi@nvidia.com \
    --cc=idosch@idosch.org \
    --cc=jiri@nvidia.com \
    --cc=kuba@kernel.org \
    --cc=leon@kernel.org \
    --cc=lkp@intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=xiyou.wangcong@gmail.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.