If we have a dedicated ABI call for this mapping, then it seems reasonable to
have it device independent.
However, this mapping is really only used when creating address handles.
So, we can base the mapping on the (device specific) create_ah() flow, but
provide generic mapping functions for all
also intend to allow the use of (non link local) IP
addresses encoded in the GIDs. And we will definitely use neighbor
discovery to translate those.
--Liran
-Original Message-
From: Roland Dreier [mailto:rdre...@cisco.com]
Sent: Monday, November 30, 2009 7:34 AM
To: Liran Liss
Cc
RFC 4291, Appendix A.
--Liran
-Original Message-
From: Roland Dreier [mailto:rdre...@cisco.com]
Sent: Monday, November 23, 2009 9:18 PM
To: Liran Liss
Cc: Richard Frank; o...@lists.openfabrics.org; OpenFabrics EWG
Subject: Re: [ewg] Re: [ofw] SC'09 BOF - Meeting notes
RFC 3041 deals
stack
implementation.
--Liran
-Original Message-
From: Roland Dreier [mailto:rdre...@cisco.com]
Sent: Monday, November 23, 2009 9:20 PM
To: Liran Liss
Cc: Richard Frank; o...@lists.openfabrics.org; OpenFabrics EWG
Subject: Re: [ewg] Re: [ofw] SC'09 BOF - Meeting notes
In any case
As far as core APIs go, the patch set introduces 2 basic additions
rather than changes:
- A new ABI function to resolve gids to macs - ib_get_mac()
- A new kernel ib_device function to get the port transport -
ib_get_port_transport().
There are no changes to the Verbs API.
All the address
90% of the changes are either in the mlx4 driver, or self-contained in
the rdmaoe flow of the cma, which handles rdmaoe addressing and
connection setup.
The rest of the changes indeed touch various locations of the stack, but
they are either definitions or follow the same logic:
if
In the past few months of review, the responsibility for rdmaoe
addressing was moved to the rdmacm.
So, any future addressing enhancements can be confined to the rdmacm
module without breaking existing APIs.
RFC 3041 deals with static global IP addresses on the Internet,
especially for portable
This exaclty the same as for iWARP: IPoIB checks the node transport, and
if it is != IB, it exists.
For RDMAoE, we do the same check but at the port level.
-Original Message-
From: general-boun...@lists.openfabrics.org
[mailto:general-boun...@lists.openfabrics.org] On Behalf Of Woodruff,
S.B.
--Liran
Trying to emulate IB for mad services is a total hack and not how this
new transport should be added into the core. It should be it's own
transport type, just like iWarp was added.
You should start with adding a new transport type to ib_verbs.h, e.g.,
LL: it is not a hack:
Oops, I meant exits instead of exists...
-Original Message-
From: Liran Liss
Sent: Tuesday, July 14, 2009 11:16 AM
To: 'Woodruff, Robert J'; Eli Cohen; Hefty, Sean; Roland Dreier
Cc: ewg; general-list
Subject: RE: [ofa-general] RE: [ewg] [PATCH 6/8 v3] IB/ipoib: restrict
IPoIB to work
regsiter a
port-transport function, it will default to the node transport.)
Thanks!
--Liran
-Original Message-
From: Liran Liss
Sent: Tuesday, July 14, 2009 11:53 AM
To: 'Woodruff, Robert J'; Eli Cohen; Hefty, Sean; Roland Dreier
Cc: ewg; general-list
Subject: RE: [ofa-general] RE: [ewg
Let's just say that at this point I completely disagree with where
these patches try to abstract the differences, which are many.
RDMA apps that want to use this and IB without going through an
abstraction will need different code -- just like they would for iWarp,
which also provides RDMA over
Why not just use IP to MAC calls? Or use the MAC as the GUID?
We do use standard OS services to map the IP addresses (that were
encoded in the GID) to MACs.
GIDs encode IP addresses rather than MACs to enable users to use the
node names that they are used to.
Specifically, we will feed in all
13 matches
Mail list logo
