All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@ziepe.ca>
To: Parav Pandit <parav@mellanox.com>
Cc: Leon Romanovsky <leon@kernel.org>,
	Weihang Li <liweihang@huawei.com>,
	"dledford@redhat.com" <dledford@redhat.com>,
	"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
	"linuxarm@huawei.com" <linuxarm@huawei.com>,
	Shiraz Saleem <shiraz.saleem@intel.com>
Subject: Re: Is anyone working on implementing LAG in ib core?
Date: Mon, 24 Feb 2020 15:23:53 -0400	[thread overview]
Message-ID: <20200224192353.GU31668@ziepe.ca> (raw)
In-Reply-To: <8c2df0c3-db07-4f18-1b7f-f648539d52d1@mellanox.com>

On Mon, Feb 24, 2020 at 07:01:43PM +0000, Parav Pandit wrote:
> On 2/24/2020 12:29 PM, Jason Gunthorpe wrote:
> > On Mon, Feb 24, 2020 at 12:52:06PM +0200, Leon Romanovsky wrote:
> >>> Are you asking why bonding should be implemented as dedicated
> >>> ulp/driver, and not as an extension by the vendor driver?
> >>
> >> No, I meant something different. You are proposing to combine IB
> >> devices, while keeping netdev devices separated. I'm asking if it is
> >> possible to combine netdev devices with already existing bond driver
> >> and simply create new ib device with bond netdev as an underlying
> >> provider.
> > 
> > Isn't that basically what we do now in mlx5?
> > 
> And its broken for few aspects that I described in Q&A question-1 in
> this thread previously.
> 
> On top of that user has no ability to disable rdma bonding.

And what does that mean? The real netdevs have no IP addreses so what
exactly does a non-bonded RoCEv2 RDMA device do?

> User exactly asked us that they want to disable in some cases.
> (not on mailing list). So there are non-upstream hacks exists that is
> not applicable for this discussion.

Bah, I'm aware of that - that request is hack solution to something
else as well.

> > Logically the ib_device is attached to the bond, it uses the bond for
> > IP addressing, etc.
> > 
> > I'm not sure trying to have 3 ib_devices like netdev does is sane,
> > that is very, very complicated to get everything to work. The ib stuff
> > just isn't designed to be stacked like that.
> > 
> I am not sure I understand all the complications you have thought through.
> I thought of few and put forward in the Q&A in the thread and we can
> improve the design as we go forward.
> 
> Stacking rdma device on top of existing rdma device as an ib_client so
> that rdma bond device exactly aware of what is going on with slaves and
> bond netdev.

How do you safely proxy every single op from the bond to slaves?

How do you force the slaves to allow PDs to be shared across them?

What provider lives in user space for the bond driver? What happens to
the udata/etc?

And it doesn't solve the main problem you raised, creating a IB device
while holding RTNL simply should not ever be done. Moving this code
into the core layer fixed it up significantly for the similar rxe/siw
cases, I expect the same is possible for the LAG situation too.

Jason

  reply	other threads:[~2020-02-24 19:23 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-22  3:48 Is anyone working on implementing LAG in ib core? Weihang Li
2020-02-22 23:40 ` Jason Gunthorpe
2020-02-23  0:44   ` Parav Pandit
2020-02-23  9:49     ` Leon Romanovsky
2020-02-24  7:10       ` Parav Pandit
2020-02-24 10:52         ` Leon Romanovsky
2020-02-24 18:12           ` Parav Pandit
2020-02-24 18:29           ` Jason Gunthorpe
2020-02-24 19:01             ` Parav Pandit
2020-02-24 19:23               ` Jason Gunthorpe [this message]
2020-02-24 19:41                 ` Parav Pandit
2020-02-25  7:58             ` Leon Romanovsky
2020-03-02  7:22     ` liweihang

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=20200224192353.GU31668@ziepe.ca \
    --to=jgg@ziepe.ca \
    --cc=dledford@redhat.com \
    --cc=leon@kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=liweihang@huawei.com \
    --cc=parav@mellanox.com \
    --cc=shiraz.saleem@intel.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.