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
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
be
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
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
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. And
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
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 it.
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 get
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 and who
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 classification and
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.
Same thing with TSO
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
the
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
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
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?
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
Steve Wise wrote:
Any more comments?
Does anyone have ideas on how to reserve the port space without using a
struct socket?
- Sean
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
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 you guys
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.
Sean Hefty wrote:
Lemme know how I can help. I certainly can test any patches on my 8
node iwarp cluster.
We should probably take the idea to netdev before making any substantial changes
to the code.
- Sean
Yup.
Should I post my RFC patch and we'll go from there?
Steve.
Should I post my RFC patch and we'll go from there?
Sounds good to me. Roland, do you have any opinion?
- Sean
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe,
Sean Hefty wrote:
If we get rid of the rdma_cm specific port spaces, do we then reduce
the valid possible spaces to just TCP and UDP? Or what? In the
sockets paradigm, the socket is explicitly bound to a protocol space
when its created (based on the protocol id). Do you think we need to
Lemme know how I can help. I certainly can test any patches on my 8
node iwarp cluster.
We should probably take the idea to netdev before making any substantial changes
to the code.
- Sean
___
general mailing list
general@lists.openfabrics.org
Sean Hefty wrote:
Consider NFS and NFS-RDMA. The NFS gurus struggled with this very
issue and concluded that the RDMA service needs to be on a separate
port. Thus they are proposing a new netid/port number for doing RDMA
mounts vs TCP/UDP mounts. IMO that is the correct way to go: RDMA
In the RFC patch I posted, the socket is _just_ to allow binding to a
port/addr. Its not used for anything else. From the native stack's
perspective, its a TCP socket in the CLOSED state (but bound) I guess.
For RDMA, I think we're somewhere in between binding to an address,
versus mapping
Sean Hefty wrote:
In the RFC patch I posted, the socket is _just_ to allow binding to a
port/addr. Its not used for anything else. From the native stack's
perspective, its a TCP socket in the CLOSED state (but bound) I guess.
For RDMA, I think we're somewhere in between binding to an
Sean Hefty wrote:
Okay - for final patches, I think we want to remove the rdma_cm specific
port spaces, along with changing the API to clarify that it uses the
same port space as TCP/UDP.
If we get rid of the rdma_cm specific port spaces, do we then reduce the
valid possible spaces to
If we get rid of the rdma_cm specific port spaces, do we then reduce the
valid possible spaces to just TCP and UDP? Or what? In the sockets
paradigm, the socket is explicitly bound to a protocol space when its
created (based on the protocol id). Do you think we need to change the
Consider NFS and NFS-RDMA. The NFS gurus struggled with this very issue
and concluded that the RDMA service needs to be on a separate port. Thus
they are proposing a new netid/port number for doing RDMA mounts vs
TCP/UDP mounts. IMO that is the correct way to go: RDMA services are
different
29 matches
Mail list logo
