From: Sean Hefty <[EMAIL PROTECTED]>
Date: Wed, 10 Oct 2007 14:01:07 -0700
> > The hack to use a socket and bind it to claim the port was just for
> > demostrating the idea. The correct solution, IMO, is to enhance the
> > core low level 4-tuple allocation services to be more generic (eg: not
The hack to use a socket and bind it to claim the port was just for
demostrating the idea. The correct solution, IMO, is to enhance the
core low level 4-tuple allocation services to be more generic (eg: not
be tied to a struct sock). Then the host tcp stack and the host rdma
stack can allocat
On Mon, 8 Oct 2007, Steve Wise wrote:
> The correct solution, IMO, is to enhance the core low level 4-tuple
> allocation services to be more generic (eg: not be tied to a struct
> sock). Then the host tcp stack and the host rdma stack can allocate
> TCP/iWARP ports/4tuples from this common ex
David Miller wrote:
From: Sean Hefty <[EMAIL PROTECTED]>
Date: Thu, 09 Aug 2007 14:40:16 -0700
Steve Wise wrote:
Any more comments?
Does anyone have ideas on how to reserve the port space without using a
struct socket?
How about we just remove the RDMA stack altogether? I am not at all
k
From: Roland Dreier <[EMAIL PROTECTED]>
Date: Tue, 28 Aug 2007 12:38:07 -0700
> It seems that the NIC would also have to look into a TCP stream (and
> handle out of order segments etc) to find message boundaries for this
> to be equivalent to what an RDMA NIC does.
It would work for data that acc
Sorry for the long latency, I was at the beach all last week.
> > And direct data placement really does give you a factor of two at
> > least, because otherwise you're stuck receiving the data in one
> > buffer, looking at some of the data at least, and then figuring out
> > where to copy it.
From: Roland Dreier <[EMAIL PROTECTED]>
Date: Mon, 20 Aug 2007 18:16:54 -0700
> And direct data placement really does give you a factor of two at
> least, because otherwise you're stuck receiving the data in one
> buffer, looking at some of the data at least, and then figuring out
> where to copy
[TSO / LRO discussion snipped -- it's not the main point so no sense
spending energy arguing about it]
> Just be realistic and accept that RDMA is a point in time solution,
> and like any other such technology takes flexibility away from users.
>
> Horizontal scaling of cpus up to huge arity
From: Roland Dreier <[EMAIL PROTECTED]>
Date: Fri, 17 Aug 2007 22:23:01 -0700
> Also, looking at the complexity and bug-fixing effort that go into
> making TSO work vs the really pretty small gain it gives also makes
> part of me wonder whether the noble proclamations about
> maintainability are a
> This is also a series of falsehoods. All packet filtering,
> queue management, and packet scheduling facilities work perfectly
> fine and as designed with both LRO and TSO.
I'm not sure I follow. Perhaps "broken" was too strong a word to use,
but if you pass a huge segment to a NIC with TSO
From: Roland Dreier <[EMAIL PROTECTED]>
Date: Fri, 17 Aug 2007 16:31:07 -0700
> > > > When using RDMA you lose the capability to do packet shaping,
> > > > classification, and all the other wonderful networking facilities
> > > > you've grown to love and use over the years.
> > >
> > > Sa
> > > When using RDMA you lose the capability to do packet shaping,
> > > classification, and all the other wonderful networking facilities
> > > you've grown to love and use over the years.
> >
> > Same thing with TSO and LRO and who knows what else.
>
> Not true at all. Full classifi
From: Roland Dreier <[EMAIL PROTECTED]>
Date: Fri, 17 Aug 2007 12:52:39 -0700
> > When using RDMA you lose the capability to do packet shaping,
> > classification, and all the other wonderful networking facilities
> > you've grown to love and use over the years.
>
> Same thing with TSO and LRO
> > Isn't RDMA _part_ of the "software net stack" within Linux?
> It very much is not so.
This is just nit-picking. You can draw the boundary of the "software
net stack" wherever you want, but I think Sean's point was just that
RDMA drivers already are part of Linux, and we all want them to ge
From: Tom Tucker <[EMAIL PROTECTED]>
Date: Thu, 16 Aug 2007 08:43:11 -0500
> Isn't RDMA _part_ of the "software net stack" within Linux?
It very much is not so.
When using RDMA you lose the capability to do packet shaping,
classification, and all the other wonderful networking facilities
you've
On Wed, 2007-08-15 at 22:26 -0400, Jeff Garzik wrote:
[...snip...]
> > I think removing the RDMA stack is the wrong thing to do, and you
> > shouldn't just threaten to yank entire subsystems because you don't like
> > the technology. Lets keep this constructive, can we? RDMA should get
> > t
> Needing to reach out of the RDMA sandbox and reserve net stack
> resources away from itself travels a path we've consistently avoided.
Where did the idea of an "RDMA sandbox" come from? Obviously no one
disagrees with keeping things clean and maintainable, but the idea
that RDMA is a second-c
Steve Wise wrote:
David Miller wrote:
From: Sean Hefty <[EMAIL PROTECTED]>
Date: Thu, 09 Aug 2007 14:40:16 -0700
Steve Wise wrote:
Any more comments?
Does anyone have ideas on how to reserve the port space without using
a struct socket?
How about we just remove the RDMA stack altogether?
David Miller wrote:
From: Sean Hefty <[EMAIL PROTECTED]>
Date: Thu, 09 Aug 2007 14:40:16 -0700
Steve Wise wrote:
Any more comments?
Does anyone have ideas on how to reserve the port space without using a
struct socket?
How about we just remove the RDMA stack altogether? I am not at all
k
How about we just remove the RDMA stack altogether? I am not at all
kidding. If you guys can't stay in your sand box and need to cause
problems for the normal network stack, it's unacceptable. We were
told all along the if RDMA went into the tree none of this kind of
stuff would be an issue.
From: Sean Hefty <[EMAIL PROTECTED]>
Date: Thu, 09 Aug 2007 14:40:16 -0700
> Steve Wise wrote:
> > Any more comments?
>
> Does anyone have ideas on how to reserve the port space without using a
> struct socket?
How about we just remove the RDMA stack altogether? I am not at all
kidding. If yo
Steve Wise wrote:
Any more comments?
Does anyone have ideas on how to reserve the port space without using a
struct socket?
- Sean
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/
Any more comments?
Steve Wise wrote:
Networking experts,
I'd like input on the patch below, and help in solving this bug
properly. iWARP devices that support both native stack TCP and iWARP
(aka RDMA over TCP/IP/Ethernet) connections on the same interface need
the fix below or some similar
On Tue, Aug 07, 2007 at 10:06:29AM -0500, Steve Wise ([EMAIL PROTECTED]) wrote:
> >On Tue, Aug 07, 2007 at 09:37:41AM -0500, Steve Wise
> >([EMAIL PROTECTED]) wrote:
> >>+static int cma_get_tcp_port(struct rdma_id_private *id_priv)
> >>+{
> >>+ int ret;
> >>+ struct socket *sock;
> >>+
> >>+
Evgeniy Polyakov wrote:
Hi Steve.
On Tue, Aug 07, 2007 at 09:37:41AM -0500, Steve Wise ([EMAIL PROTECTED]) wrote:
+static int cma_get_tcp_port(struct rdma_id_private *id_priv)
+{
+ int ret;
+ struct socket *sock;
+
+ ret = sock_create_kern(AF_INET, SOCK_STREAM, IPPROTO_TCP,
Hi Steve.
On Tue, Aug 07, 2007 at 09:37:41AM -0500, Steve Wise ([EMAIL PROTECTED]) wrote:
> +static int cma_get_tcp_port(struct rdma_id_private *id_priv)
> +{
> + int ret;
> + struct socket *sock;
> +
> + ret = sock_create_kern(AF_INET, SOCK_STREAM, IPPROTO_TCP, &sock);
> + if (ret
Networking experts,
I'd like input on the patch below, and help in solving this bug
properly. iWARP devices that support both native stack TCP and iWARP
(aka RDMA over TCP/IP/Ethernet) connections on the same interface need
the fix below or some similar fix to the RDMA connection manager.
T
27 matches
Mail list logo
