From: Leon Romanovsky <leon@kernel.org>
To: Nikolay Aleksandrov <nikolay@enfabrica.net>
Cc: netdev@vger.kernel.org, shrijeet@enfabrica.net,
alex.badea@keysight.com, eric.davis@broadcom.com,
rip.sohan@amd.com, dsahern@kernel.org, bmt@zurich.ibm.com,
roland@enfabrica.net, winston.liu@keysight.com,
dan.mihailescu@keysight.com, kheib@redhat.com,
parth.v.parikh@keysight.com, davem@redhat.com,
ian.ziemba@hpe.com, andrew.tauferner@cornelisnetworks.com,
welch@hpe.com, rakhahari.bhunia@keysight.com,
kingshuk.mandal@keysight.com, linux-rdma@vger.kernel.org,
kuba@kernel.org, pabeni@redhat.com,
Jason Gunthorpe <jgg@nvidia.com>
Subject: Re: [RFC PATCH 00/13] Ultra Ethernet driver introduction
Date: Wed, 12 Mar 2025 13:29:21 +0200 [thread overview]
Message-ID: <20250312112921.GA1322339@unreal> (raw)
In-Reply-To: <2f06a40d-2f14-439a-9c95-0231dce5772d@enfabrica.net>
On Wed, Mar 12, 2025 at 11:40:05AM +0200, Nikolay Aleksandrov wrote:
> On 3/8/25 8:46 PM, Leon Romanovsky wrote:
> > On Fri, Mar 07, 2025 at 01:01:50AM +0200, Nikolay Aleksandrov wrote:
> >> Hi all,
> >
> > <...>
> >
> >> Ultra Ethernet is a new RDMA transport.
> > > Awesome, and now please explain why new subsystem is needed when
> > drivers/infiniband already supports at least 5 different RDMA
> > transports (OmniPath, iWARP, Infiniband, RoCE v1 and RoCE v2).
> >
>
> As Bernard commented, we're not trying to add a new subsystem,
So why did you create new drivers/ultraeth/ folder?
> but start a discussion on where UEC should live because it has multiple
> objects and semantics that don't map well to the current
> infrastructure. For example from this set - managing contexts, jobs and
> fabric endpoints.
It is just different names which libfabric used to do not use
traditional verbs naming. There is nothing in the stack which prevents
from QP to have same properties as "fabric endpoints" have.
> Also we have the ephemeral PDC connections
> that come and go as needed. There more such objects coming with more
> state, configuration and lifecycle management. That is why we added a
> separate netlink family to cleanly manage them without trying to fit
> a square peg in a round hole so to speak.
Yeah, I saw that you are planning to use netlink to manage objects,
which is very questionable. It is slow, unreliable, requires sockets,
needs more parsing logic e.t.c
To avoid all this overhead, RDMA uses netlink-like ioctl calls, which
fits better for object configurations.
Thanks
next prev parent reply other threads:[~2025-03-12 11:29 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-06 23:01 [RFC PATCH 00/13] Ultra Ethernet driver introduction Nikolay Aleksandrov
2025-03-06 23:01 ` [RFC PATCH 01/13] drivers: ultraeth: add initial skeleton and kconfig option Nikolay Aleksandrov
2025-03-06 23:01 ` [RFC PATCH 02/13] drivers: ultraeth: add context support Nikolay Aleksandrov
2025-03-06 23:01 ` [RFC PATCH 03/13] drivers: ultraeth: add new genl family Nikolay Aleksandrov
2025-03-06 23:01 ` [RFC PATCH 04/13] drivers: ultraeth: add job support Nikolay Aleksandrov
2025-03-06 23:01 ` [RFC PATCH 05/13] drivers: ultraeth: add tunnel udp device support Nikolay Aleksandrov
2025-03-06 23:01 ` [RFC PATCH 06/13] drivers: ultraeth: add initial PDS infrastructure Nikolay Aleksandrov
2025-03-06 23:01 ` [RFC PATCH 07/13] drivers: ultraeth: add request and ack receive support Nikolay Aleksandrov
2025-03-06 23:01 ` [RFC PATCH 08/13] drivers: ultraeth: add request transmit support Nikolay Aleksandrov
2025-03-06 23:01 ` [RFC PATCH 09/13] drivers: ultraeth: add support for coalescing ack Nikolay Aleksandrov
2025-03-06 23:02 ` [RFC PATCH 10/13] drivers: ultraeth: add sack support Nikolay Aleksandrov
2025-03-06 23:02 ` [RFC PATCH 11/13] drivers: ultraeth: add nack support Nikolay Aleksandrov
2025-03-06 23:02 ` [RFC PATCH 12/13] drivers: ultraeth: add initiator and target idle timeout support Nikolay Aleksandrov
2025-03-06 23:02 ` [RFC PATCH 13/13] HACK: drivers: ultraeth: add char device Nikolay Aleksandrov
2025-03-08 18:46 ` [RFC PATCH 00/13] Ultra Ethernet driver introduction Leon Romanovsky
2025-03-09 3:21 ` Parav Pandit
2025-03-11 14:20 ` Bernard Metzler
2025-03-11 14:55 ` Leon Romanovsky
2025-03-11 17:11 ` Sean Hefty
2025-03-12 9:20 ` Nikolay Aleksandrov
2025-03-12 9:40 ` Nikolay Aleksandrov
2025-03-12 11:29 ` Leon Romanovsky [this message]
2025-03-12 14:20 ` Nikolay Aleksandrov
2025-03-12 15:10 ` Leon Romanovsky
2025-03-12 16:00 ` Nikolay Aleksandrov
2025-03-14 14:53 ` Bernard Metzler
2025-03-17 12:52 ` Leon Romanovsky
2025-03-19 13:52 ` Jason Gunthorpe
2025-03-19 14:02 ` Nikolay Aleksandrov
2025-03-14 20:51 ` Stanislav Fomichev
2025-03-17 12:30 ` Leon Romanovsky
2025-03-19 19:12 ` Stanislav Fomichev
2025-03-15 20:49 ` Netlink vs ioctl WAS(Re: " Jamal Hadi Salim
2025-03-17 12:57 ` Leon Romanovsky
2025-03-18 22:49 ` Jason Gunthorpe
2025-03-19 18:21 ` Jamal Hadi Salim
2025-03-19 19:19 ` Jason Gunthorpe
2025-03-25 14:12 ` Jamal Hadi Salim
2025-03-26 15:50 ` Jason Gunthorpe
2025-04-08 14:16 ` Jamal Hadi Salim
2025-04-09 16:10 ` Jason Gunthorpe
2025-03-19 16:48 ` Jason Gunthorpe
2025-03-20 11:13 ` Yunsheng Lin
2025-03-20 14:32 ` Jason Gunthorpe
2025-03-20 20:05 ` Sean Hefty
2025-03-20 20:12 ` Jason Gunthorpe
2025-03-21 2:02 ` Yunsheng Lin
2025-03-21 12:01 ` Jason Gunthorpe
2025-03-24 20:22 ` Roland Dreier
2025-03-24 21:28 ` Sean Hefty
2025-03-25 13:22 ` Bernard Metzler
2025-03-25 17:02 ` Sean Hefty
2025-03-26 14:45 ` Jason Gunthorpe
2025-03-26 15:29 ` Sean Hefty
2025-03-26 15:53 ` Jason Gunthorpe
2025-03-26 17:39 ` Sean Hefty
2025-03-27 13:26 ` Jason Gunthorpe
2025-03-28 12:20 ` Yunsheng Lin
2025-03-31 19:49 ` Sean Hefty
2025-04-01 9:19 ` Yunsheng Lin
2025-03-31 19:29 ` Sean Hefty
2025-04-01 13:04 ` Jason Gunthorpe
2025-04-01 16:57 ` Sean Hefty
2025-04-01 19:39 ` Jason Gunthorpe
2025-04-03 1:30 ` Sean Hefty
2025-04-04 16:03 ` Ziemba, Ian
2025-04-05 1:07 ` Sean Hefty
2025-04-07 19:32 ` Ziemba, Ian
2025-04-08 4:40 ` Sean Hefty
2025-04-16 23:58 ` Sean Hefty
2025-04-17 1:23 ` Jason Gunthorpe
2025-04-17 2:59 ` Sean Hefty
2025-04-17 13:31 ` Jason Gunthorpe
2025-04-18 16:50 ` Sean Hefty
2025-04-22 15:44 ` Jason Gunthorpe
2025-03-26 15:16 ` Jason Gunthorpe
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=20250312112921.GA1322339@unreal \
--to=leon@kernel.org \
--cc=alex.badea@keysight.com \
--cc=andrew.tauferner@cornelisnetworks.com \
--cc=bmt@zurich.ibm.com \
--cc=dan.mihailescu@keysight.com \
--cc=davem@redhat.com \
--cc=dsahern@kernel.org \
--cc=eric.davis@broadcom.com \
--cc=ian.ziemba@hpe.com \
--cc=jgg@nvidia.com \
--cc=kheib@redhat.com \
--cc=kingshuk.mandal@keysight.com \
--cc=kuba@kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nikolay@enfabrica.net \
--cc=pabeni@redhat.com \
--cc=parth.v.parikh@keysight.com \
--cc=rakhahari.bhunia@keysight.com \
--cc=rip.sohan@amd.com \
--cc=roland@enfabrica.net \
--cc=shrijeet@enfabrica.net \
--cc=welch@hpe.com \
--cc=winston.liu@keysight.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).