On Mon, Jul 19, 2010 at 10:28:24PM -0700, Paul Grun wrote:
This is incorrect. The intent of the text is that a verbs consumer deals
ONLY in layer 3 addresses (GIDs). It doesn't make any sense to restrict the
interpretation to mean 'LIDs', since LIDs are a NOP for RoCE.
CA16-17: When
Small correction needed regarding the multicast forwarding.
Since we are talking about IPv6 multicast groups, which
translate to 33:33:xx:xx:xx:xx MAC address, the router
listener notification protocol is going to be MLD and not
IGMP. Still there are switches which support MLD
...@voltaire.com; yift...@voltaire.com; Tziporet
Koren; al...@voltaire.com
Subject: Re: When IBoE will be merged to upstream?
On Mon, Jul 12, 2010 at 10:58:19AM +0300, Liran Liss wrote:
...A verbs consumer using a RoCE network relies strictly
on so-called
Layer 3 addressing (GIDs); layer
The text is saying that the specification does not use any of the
LID fields in the verbs interface, that is it. It isn't talking
about MAC addresses.
Exactly how and where the MAC address comes about was
never decided,
and at least some participants thought it should be a
But, we can't mandate an overload of the GID in a way that
it prevents its use as a true L3 address (eventually routable).
Actually I'm beginning to think that the only possible way we
can use the GID in IBoE is as a link-local IPv6 addresses
containing an Ethernet address. Trying
A quibble about multicast - AFAIK this is unsolved. I
think some spec needs to be agreed that documents what
sort of multicast snooping operations switches need to do,
ie if IGMP joins imply that IBoE traffic for the same DMAC
is included in the join, or if IBoE requires a
On Thu, Jul 15, 2010 at 01:55:32PM +0300, Liran Liss wrote:
I objected to the draft spec leaving this area
absent, even.
You should submit a comment on this matter using the IBTA comment
tracker database if you intend your concern to be taken into account.
The position of IBTA is that
No, I think all switches will flood unknown multicast packets. But
there is a reason that IGMP snooping was invented -- it is inefficient
(to say the least) to flood all multicast traffic.
And by the way I view the fact that the IBoE spec does not say anything
at all about how to map MGIDs
No, I think all switches will flood unknown multicast packets. But
there is a reason that IGMP snooping was invented -- it is inefficient
(to say the least) to flood all multicast traffic.
- R.
Small correction needed regarding the multicast forwarding.
Since we are talking about IPv6
Small correction needed regarding the multicast forwarding.
Since we are talking about IPv6 multicast groups, which translate to
33:33:xx:xx:xx:xx MAC address, the router listener notification protocol
is going to be MLD and not IGMP. Still there are switches which support
MLD forwarding
...A verbs consumer using a RoCE network relies strictly
on so-called
Layer 3 addressing (GIDs); layer 2 addresses (e.g. subnet local
identifiers) are not passed across the verbs interface...
Ah, hmm, well, I was on that list during this time and I don't
think
this
On Tue, Jul 13, 2010 at 11:26:41AM +0300, Liran Liss wrote:
'subnet local identidifer' == LID
The text is saying that the specification does not use any of the LID
fields in the verbs interface, that is it. It isn't talking about MAC
addresses.
Exactly how and where the MAC
On Mon, Jul 12, 2010 at 02:20:22PM -0700, Roland Dreier wrote:
So the best solution I can see is to declare that an IBoE GID must be an
IPv6 address coming from an EUI-64 Ethernet address for the
corresponding port; for MGIDs I guess we use the standard IPv6 mapping
to Ethernet address
A quibble about multicast - AFAIK this is unsolved. I think some spec
needs to be agreed that documents what sort of multicast snooping
operations switches need to do, ie if IGMP joins imply that IBoE
traffic for the same DMAC is included in the join, or if IBoE requires
a seperate IGMP
But, we can't mandate an overload of the GID in a way that it
prevents its use as a true L3 address (eventually routable).
Actually I'm beginning to think that the only possible way we can use
the GID in IBoE is as a link-local IPv6 addresses containing an Ethernet
address. Trying to hide
; mo...@voltaire.com; aleks...@voltaire.com;
yift...@voltaire.com; Tziporet Koren; al...@voltaire.com
Subject: Re: When IBoE will be merged to upstream?
Liran Liss wrote:
but keeping ib_create_ah() callable from any context is not
a goal by itself.
going with your approach, if your
On Sat, Jul 10, 2010 at 11:55:18AM +0300, Liran Liss wrote:
...A verbs consumer using a RoCE network relies strictly on
so-called Layer 3 addressing (GIDs); layer 2 addresses (e.g. subnet
local identifiers) are not passed across the verbs interface...
Ah, hmm, well, I was on that list during
Liran Liss wrote:
but keeping ib_create_ah() callable from any context is not a goal by itself.
going with your approach, if your proposed design is accepted, I believe that
you probably need to patch all the code-chains that makes calls under the
current assumption
I am looking for
Third, RoCE is not IB; its all about making RDMA user-friendly to Ethernet
users.
This is utter nonsense. RoCE (or IBoE as I prefer ;) is absolutely
IB-over-Ethernet and it is all about making minimal changes to IB and IB
applications to run on Ethernet.
Most importantly, we don't want
On Thu, Jul 01, 2010 at 02:50:55PM +0300, Liran Liss wrote:
We have a specification, we have an implementation, and we have
clean way of passing RoCE L2 information to user-space via address
handles. I don't see any substantial reason to change the basic
approach.
Actually, we have a spec
On Thu, Jul 01, 2010 at 05:20:05PM -0700, Hefty, Sean wrote:
The most evident example is the CM protocol, which has L2 fields in its
payloads.
How does moving the L3 to L2 mapping from outside create AH result
in the CM protocol needing to change? Why is hiding this under modify
QP
There are also good reasons why the RoCE standard left the syntax of
address handles.
First, it keeps the Verbs unchanged. Even if you are using rdmacm to make
connections, you still have to inspect address handles when connecting to
UD QPs or joining multicast addresses.
Verbs isn't an API,
: Thursday, June 24, 2010 11:37 PM
To: Liran Liss
Cc: Hefty, Sean; Roland Dreier; Aleksey Senin; linux-rdma; mo...@voltaire.com;
aleks...@voltaire.com; yift...@voltaire.com; Tziporet Koren; al...@voltaire.com
Subject: Re: When IBoE will be merged to upstream?
The current behavior of ibv_create_ah
On Fri, Jun 25, 2010 at 11:04:28AM +0300, Liran Liss wrote:
VLANs are part of L2 in Ethernet -- when you resolve a destination
L3 address to an L2 address, you get the outgoing interface, which
also determines the VLAN. I think this approach has an advantage
over an RDMA device per VLAN in
(BTW, Sean, did AF_IB's sockaddr include a scoping field, and did you
figure out some way to make that work?)
The af_ib does include a scoping field, but the last set of patches doesn't
make use of it.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a
[mailto:linux-rdma-ow...@vger.kernel.org] On Behalf Of Roland Dreier
Sent: Thursday, June 24, 2010 2:24 AM
To: Aleksey Senin
Cc: linux-rdma; mo...@voltaire.com; aleks...@voltaire.com;
yift...@voltaire.com; Tziporet Koren; al...@voltaire.com
Subject: Re: When IBoE will be merged to upstream
: RE: When IBoE will be merged to upstream?
Regarding GID to Eth mappings, we discussed using the standard
create_ah() Verb for this.
In the kernel, create_ah() will call a generic address resolution
function in the cma.
The returned information will be copied back to user-space
This is actually a continue of the RAW_ET() issue. We want to
make a submition of the patches to the upstream, but there is not
support for IB transport in Ethernet devices, and the mlx4_en drivers
version is a bit outdated 1.4.1.1 in upstream and 1.5.1 in the OFED
There is also
28 matches
Mail list logo
