All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Jiri Pirko <jiri@resnulli.us>
Cc: netdev@vger.kernel.org, pabeni@redhat.com, davem@davemloft.net,
	edumazet@google.com, moshe@nvidia.com, saeedm@nvidia.com,
	shayd@nvidia.com, leon@kernel.org
Subject: Re: [patch net-next 0/4] net/mlx5: expose peer SF devlink instance
Date: Tue, 22 Aug 2023 08:28:33 -0700	[thread overview]
Message-ID: <20230822082833.1cb68ef7@kernel.org> (raw)
In-Reply-To: <ZORXVr4bcTlbstj8@nanopsycho>

On Tue, 22 Aug 2023 08:36:06 +0200 Jiri Pirko wrote:
> >I'm thinking about containers. Since the SF configuration is currently
> >completely vendor ad-hoc I'm trying to establish who's supposed to be
> >in control of the devlink instance of an SF - orchestrator or the
> >workload. We should pick one and force everyone to fall in line.  
> 
> I think that both are valid. In the VF case, the workload (VM) owns the
> devlink instance and netdev. In the SF case:
> 1) It could be the same. You can reload SF into netns, then
>    the container has them both. That would provide the container
>    more means (e.g. configuration of rdma,netdev,vdev etc).
> 2) Or, your can only put netdev into netns.

Okay, can you document that?

> Both usecases are valid. But back to my question regarding to this
> patchsets. Do you see the need to expose netns for nested port function
> devlink instance? Even now, I still don't.

It's not a huge deal but what's the problem with adding the netns id?
It's probably 50 LoC, trivial stuff.

  reply	other threads:[~2023-08-22 15:28 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-15 14:51 [patch net-next 0/4] net/mlx5: expose peer SF devlink instance Jiri Pirko
2023-08-15 14:51 ` [patch net-next 1/4] net/mlx5: Disable eswitch as the first thing in mlx5_unload() Jiri Pirko
2023-08-15 14:51 ` [patch net-next 2/4] net/mlx5: Lift reload limitation when SFs are present Jiri Pirko
2023-08-15 14:51 ` [patch net-next 3/4] devlink: expose peer SF devlink instance Jiri Pirko
2023-08-15 14:51 ` [patch net-next 4/4] net/mlx5: SF, Implement peer devlink set for SF representor devlink port Jiri Pirko
2023-08-18  2:34 ` [patch net-next 0/4] net/mlx5: expose peer SF devlink instance Jakub Kicinski
2023-08-18  7:30   ` Jiri Pirko
2023-08-18 21:20     ` Jakub Kicinski
2023-08-21 10:49       ` Jiri Pirko
2023-08-21 20:19         ` Jakub Kicinski
2023-08-22  6:36           ` Jiri Pirko
2023-08-22 15:28             ` Jakub Kicinski [this message]
2023-08-22 17:40               ` Jiri Pirko
2023-08-23 13:28               ` Jiri Pirko

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=20230822082833.1cb68ef7@kernel.org \
    --to=kuba@kernel.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=jiri@resnulli.us \
    --cc=leon@kernel.org \
    --cc=moshe@nvidia.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=saeedm@nvidia.com \
    --cc=shayd@nvidia.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.