Just to correct one comment:
A ULP written to TCP/IP can use RDMA transport without change. An
example is SDP not that the ULP must use what SDP uses. Also,
please keep in mind that SDP on iWARP uses the port mapper protocol to
obtain the IP address and port to target for the connection
reques
Sean Hefty wrote:
> -Original Message-
> From: Sean Hefty [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 25, 2005 6:44 PM
> To: Kanevsky, Arkady
> Cc: Sean Hefty; openib-general@openib.org; [EMAIL PROTECTED]
> Subject: Re: [openib-general] round 2 - proposal for socket
> based connec
No.
iWARP does not have to pass this info.
The info is needed for IB because ZB and SI were introduced
in IBTA 1.2 specs as optional functionality.
So if ULP wants to use that functionality it need to find
out whether remote side can support it.
This is needed for backwards compatibility.
For examp
DAPL also strip this private data header
and present to Consumer IP addresses and ports as separate items
from Consumer private data.
Arkady Kanevsky email: [EMAIL PROTECTED]
Network Appliance phone: 781-768-5395
375 Totten Pond Rd. Fax: 7
Sean wrote:
>Kanevsky, Arkady wrote:
>> What are you trying to achieve?
>I'm trying to define a connection *service* for Infiniband that uses
TCP/IP
>addresses as its user interface. That service will have its own
protocol, in
>much the same way that SDP, SRP, etc. do today.
Seems like we have
Sean Hefty wrote:
- The kernel CMA will expose a new call, rdma_init_qp_attr() to
initialize QP attributes used to modify the state of the QP. The call
will be similar to the infiniband CM routine. Use of this call is
optional. The CMA will automatically transition QPs created by
rdma_creat
Kanevsky, Arkady wrote:
What are you trying to achieve?
I'm trying to define a connection *service* for Infiniband that uses TCP/IP
addresses as its user interface. That service will have its own protocol, in
much the same way that SDP, SRP, etc. do today.
I am trying to define an IB REQ
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Tom Tucker
> Sent: Tuesday, October 25, 2005 2:56 PM
> To: Kanevsky, Arkady
> Cc: [EMAIL PROTECTED]; openib-general@openib.org
> Subject: RE: [openib-general] round 2 - proposal for socket
> based c
Why does an application care whether the remote implementation supports
ZB? Whether memory regions can be described with zero based rkeys or
not doesn't matter on an end-to-end level. Its only a local issue. So
ZB shouldn't be there IMO.
- Original Message -
From: "Tom Tucker" <[
Nishanth> Hrm, well, I'm testing the latest svn (3865), did the
Nishanth> patch just get checked in?
Yeah, I only noticed it and fixed it after your original email. I
just meant that I had already checked it in before sending my reply.
Sorry for the confusion...
- R.
___
On 25.10.2005 [15:09:42 -0700], Roland Dreier wrote:
> >checking dynamic linker charactericonfigure: error:
> >ibv_get_devices() not found. libibcm requires libibcm.
>
> The last error seeming like a circular dependency is just a typo,
> fixed by the following patch (already checked in)
Roland Dreier wrote:
This changes alloc_response_msg() in mad_rmpp.c to return the struct
it allocates directly (or an error code a la ERR_PTR), rather than
returning a status and passing the struct back in a pointer param.
This simplifies the code and gets rid of warnings like
drivers/infin
> checking dynamic linker charactericonfigure: error:
> ibv_get_devices() not found. libibcm requires libibcm.
The last error seeming like a circular dependency is just a typo,
fixed by the following patch (already checked in). As for why your
build is failing, it seems that the libi
Hi all,
I'm trying to add at least the build portion of userspace testing to my
daily kernel build tests, but am running into the following failure in
libibcm:
checking dynamic linker charactericonfigure: error:
ibv_get_devices() not found. libibcm requires libibcm.
Not sure, wh
Arkady:
I may actually have a constructive comment about the protocol (private
data format). One thing I noticed is that *almost* everything in the
private data header is available in the native iWARP protocol header
except the ZB and SI bits. If these bits become part of the canonical
private da
On Tue, 2005-10-25 at 13:16 -0700, Ted H. Kim wrote:
> Tom,
>
> Some comments inline ...
>
>
> Tom Tucker wrote:
> > I think it's relevant, so let's make sure my assumptions are correct:
> >
> > - The ITAPI will be a "ULP" on OpenIB
>
> ITAPI is like uDAPL, so if uDAPL is a "ULP" then the answ
Arkady:
I don't think anyone disagrees with your goals. Unfortunately additional
requirements on the implementation were coupled with the specification
of the private data format (protocol). This peripheral discussion
derailed any attempt to discuss the protocol.
Attempts to separate the protoco
This changes alloc_response_msg() in mad_rmpp.c to return the struct
it allocates directly (or an error code a la ERR_PTR), rather than
returning a status and passing the struct back in a pointer param.
This simplifies the code and gets rid of warnings like
drivers/infiniband/core/mad_rmpp.c:
* On Oct,10 James Lentini<[EMAIL PROTECTED]> wrote :
>
>
> On Fri, 21 Oct 2005, LEI CHAI wrote:
>
> > ips_by_gid: RET 0 at_rec 0x7fa8d380 -> id 4627
> > dapli_at_event_cb()
> > ip_comp_handler: rec 0x7fa8d380 ->id 4627 id 4627 num -22 3c66c000
> > ip_comp_handler: resolution err -22
Hi Woody,
* On Oct,2 Woodruff, Robert J<[EMAIL PROTECTED]> wrote :
> Arlin wrote,
> >James,
>
> >Here is a patch to add an optional openIB uDAPL provider that uses the
> socket CM >for anyone having
> >problems scaling out with the uCM/uAT version. To build the new
> provider, simply >"make
> >VE
> -Original Message From Ted Kim -
>
>
> I should point out that there was once a proposal of doing a
> RDDP IETF draft which would have sub-divided the MPA private
> data into a "middleware" section and an "app" section. The
> idea was to be sure that the app/ULP and middleware (e.
Tom,
Some comments inline ...
Tom Tucker wrote:
I think it's relevant, so let's make sure my assumptions are correct:
- The ITAPI will be a "ULP" on OpenIB
ITAPI is like uDAPL, so if uDAPL is a "ULP" then the answer is yes.
The point is that for uDAPL you have the actual "app" running over
Arlin wrote,
>James,
>Here is a patch to add an optional openIB uDAPL provider that uses the
socket CM >for anyone having
>problems scaling out with the uCM/uAT version. To build the new
provider, simply >"make
>VERBS=openib_scm". This version does not require IPoIB, uCM, or uAT.
>-arlin
I have
What are you trying to achieve?
I am trying to define an IB REQ protocol extension that
support IP connection 5-tuple exchange between connection
requestor and responder.
And define mapping between IP 5-tuple and IB entities.
That way ULP which was written to TCP/IP, UDP/IP, CSTP/IP (and so on)
c
Kanevsky, Arkady wrote:
Sean,
answers in-line.
Arkady
At this point, I'm just going to disagree with this approach and move on with
the current implementation of the CMA. What's needed is a service that provides
IB connections using TCP/IP addressing. I don't believe this proposal meets
th
Title: Message
Sean,
answers in-line.
Arkady
Arkady Kanevsky
email: [EMAIL PROTECTED]
Network
Appliance
phone: 781-768-5395
375 Totten
Pond Rd.
Fax: 781-895-1195
Waltham, MA
02451-2010
central phone: 781-768-5300
> -Original Message-
> From: Sean Hefty [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 25, 2005 11:21 AM
> To: Caitlin Bestler
> Cc: Kanevsky, Arkady; openib-general@openib.org; [EMAIL PROTECTED]
> Subject: Re: [openib-general] RE: [dat-discussions] round 2 -
> proposal for socket
> -Original Message-
> From: Tom Tucker [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 25, 2005 11:13 AM
> To: Caitlin Bestler
> Cc: Sean Hefty; Kanevsky, Arkady; [EMAIL PROTECTED]; DAT
> Collaborative; openib-general@openib.org
> Subject: RE: [openib-general] RE: [dat-discussions]
Caitlin Bestler wrote:
What you are proposing is an API that purports to have the
semantics of TCP/IP connection establishment that can be
implemented under non-IP transports such as InfiniBand.
However, as proposed the mapping of this API to InfiniBand
does *not* implement the semantics of TC
> -Original Message-
> From: Sean Hefty [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 25, 2005 11:10 AM
> To: Kanevsky, Arkady
> Cc: Caitlin Bestler; openib-general@openib.org; [EMAIL PROTECTED]
> Subject: Re: [openib-general] RE: [dat-discussions] round 2 -
> proposal for socket
On Tue, 2005-10-25 at 10:51 -0700, Caitlin Bestler wrote:
>
>
> >
> > I believe that the assurances you are talking about are
> > peculiar to an implementation, not to the network.
> >
>
> I disagree. Anytime you send an IP datagram on an IP network
> you are expected to provide an authentic
Kanevsky, Arkady wrote:
It is APIs not ULPs that are concern.
Yes - and an application that wants to use IP addressing instead of IB
addressing should use a different API than that of the IB CM. Trying to define
the IB CM to use anybody's favorite transport/network address is the wrong
solu
OK, I checked in the mthca QP transition table fix.
By the way, I think we probably need to consolidate the checking of
required/optional QP modify attributes so that mthca, ipath and ehca
don't each have their own copy of the code (and their own bugs).
- R.
_
It is APIs not ULPs that are concern.
Each ULP can define its own protocol.
But APIs can not.
But defining a protocol for each ULP is also bad.
This proposal defines it for all ULPs.
If ULP uses API, it does the parsing.
If ULP uses verbs it can do the parsing and encoding itself.
But in the later
>
> I believe that the assurances you are talking about are
> peculiar to an implementation, not to the network.
>
I disagree. Anytime you send an IP datagram on an IP network
you are expected to provide an authentic source address. Any
intermediate network device MAY enforce that rule and
Kanevsky, Arkady wrote:
Sean,
The reason IBTA is interested to address IP address issue
is because of multiple UPLs and APIs want to support
socket based connection model. Sure each one of them
can define its own protocol (for private data).
But this will not ensure interoperability.
There's no
Sean,
The reason IBTA is interested to address IP address issue
is because of multiple UPLs and APIs want to support
socket based connection model. Sure each one of them
can define its own protocol (for private data).
But this will not ensure interoperability.
Arkady
Arkady Kanevsky
BTW, I just tried this on my PPC 4xx system, and the MAD layer works
fine now. The port makes it to active and IPoIB works as well.
Thanks,
Roland
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-gene
On Tue, 2005-10-25 at 10:21 -0700, Caitlin Bestler wrote:
>
> > -Original Message-
> > From: Sean Hefty [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, October 25, 2005 10:08 AM
> > To: Kanevsky, Arkady
> > Cc: Caitlin Bestler; [EMAIL PROTECTED];
> > openib-general@openib.org; [EMAIL PROTE
Kanevsky, Arkady wrote:
Think of a single API that supports iWARP and IB (transport independent
API).
The CMA implements this today and did not require any changes to the IB CM.
To a connection listener it provides the IP 5-tuple + private data.
For IB it means that CM parses REQ and extracts
> -Original Message-
> From: Tom Tucker [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 25, 2005 10:24 AM
> To: Caitlin Bestler
> Cc: DAT Collaborative; openib-general@openib.org; [EMAIL PROTECTED]
> Subject: Re: [openib-general] RE: [dat-discussions] round 2 -
> proposal for socket
Caitlin Bestler wrote:
Is that because you do not agree that there is a problem?
Or is it that you think the gap betweeen this and existing IP
connection semantics is small enough that it is better to cover
it with a disclosure than by changing the CM protocol?
I would define the problem as: ap
Think of a single API that supports iWARP and IB (transport independent
API).
To a connection listener it provides the IP 5-tuple + private data.
For IB it means that CM parses REQ and extracts IP 5-tuple as separate
fields from private data.
Listener does not parse the private data encoding of the
What does this have to do with the protocol?
On Tue, 2005-10-25 at 09:35 -0700, Caitlin Bestler wrote:
> On an IP network, a non-privileged user is generally not capable of
> forging
> a source IP address and is typically prevented from using certain
> source ports.
>
> I would propose that the
> -Original Message-
> From: Sean Hefty [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 25, 2005 10:08 AM
> To: Kanevsky, Arkady
> Cc: Caitlin Bestler; [EMAIL PROTECTED];
> openib-general@openib.org; [EMAIL PROTECTED]
> Subject: Re: [openib-general] RE: [dat-discussions] round 2 -
Kanevsky, Arkady wrote:
Correct.
But this does bring the question how responder CM knows that it need to
parse
the private data. I suspect this will be done via new version of CM.
But a suage of some of the CM REQ reserved fields are also possible.
Anotherwords the current CM version assumes that
Title: Message
Dear OpenIB, SWG and DAT members,
enclosed is teh second version of the proposal.
There are really 2 proposals that are related.
The first one is encoding IP 5-tuple into REQ private data
with small additional info for versioning and IB
capabilities.
> -Original Message-
> From: Sean Hefty [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 25, 2005 9:56 AM
> To: Caitlin Bestler
> Cc: Kanevsky, Arkady; [EMAIL PROTECTED];
> openib-general@openib.org; [EMAIL PROTECTED]
> Subject: Re: [openib-general] RE: [dat-discussions] round 2 -
>
Correct.
But this does bring the question how responder CM knows that it need to
parse
the private data. I suspect this will be done via new version of CM.
But a suage of some of the CM REQ reserved fields are also possible.
Anotherwords the current CM version assumes that CM only supports
one vers
Caitlin Bestler wrote:
I believe it requires a CM protocol version change, or a "IP Address
Header present" bit.
Basically, userspace consumers can supply *any* 72 bytes of private data
currently.
To maintain backwards compatability you need an authenticator that says
"this IP
header data vou
Title: Message
I believe it requires a CM protocol version change, or a
"IP Address Header present" bit.
Basically, userspace consumers can supply *any* 72 bytes of
private data currently.
To maintain backwards compatability you need an
authenticator that says "this IP
header data vouched f
Title: Message
Caitlin,
how
does it change the proposed protocol?
Arkady
Arkady Kanevsky
email: [EMAIL PROTECTED]
Network
Appliance
phone: 781-768-5395
375 Totten
Pond Rd.
Fax: 781-895-1195
Waltham, MA
02451-2010
Title: Message
On an IP network, a non-privileged user is generally not
capable of forging
a source IP address and is typically prevented from using
certain source ports.
I would propose that the CM [MAY|SHOULD|MUST] enforce that
a non-privileged
user can only use a Source IP Address and Po
Joerg> hi, i hope it's ok to ask this question here. i just want
Joerg> to know more about poll_cq(). the standard seems to define
Joerg> only the input/ouput-params. after reading the code i
Joerg> figured out that there is some kind of "mapping" from
Joerg> libibverbs to th
Caitlin Bestler wrote:
- The kernel CMA will be modified to remove the requirement
to use rdma_create_qp(). Users that want to allocate and
manage their own QP states will be able to specify QP
attributes (qpn, qp_type, srq) through the rdma_conn_param structure.
Why?
If the userspace CMA
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Sean Hefty
> Sent: Monday, October 24, 2005 5:06 PM
> To: openib
> Subject: [openib-general] RFC userspace CMA
>
> I'm soliciting any comments that anyone might have on the
> general design for the
Sean Hefty wrote:
The following patch should fix the MAD layer's DMA mapping issue. This
patch includes all related patches that were previously posted. The fix
involved changing the MAD layer API. All callers must now use the MAD
layer to allocate and free send MADs. DMA mappings are done by
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Joerg Zinke
> Sent: Tuesday, October 25, 2005 2:40 AM
> To: openib-general@openib.org
> Subject: [openib-general] question about poll_cq()
>
> hi,
>
> i hope it's ok to ask this question here.
> i
$B!V$O$8$a$^$7$F!#%^%j$C$F$^$9!#$$$-$J$j$N%a!<%k$4$a$s$J(B
$B$5$$!#(B
$BAjCL$K>h$C$FM_$7$/$F!"%a!<%k$7$F$_$^$7$?!#CK$N?M$G$9$h$M!)(B
$B!!%a!<%k=P$7$?;~$+$iF,$NCf$O$3$N=P2q$$$N;v$G0l?'@w$^$C$A$c(B
$B$C$F$$$^$9!#$=$A$i$O;d$N;v$I$&;W$$$^$9$+!)(B($B6[D%46!*!)!K$:(B
$B$C$HG:$s$G$$$^$7$?
$B!V$O$8$a$^$7$F!#%^%j$C$F$^$9!#$$$-$J$j$N%a!<%k$4$a$s$J(B
$B$5$$!#(B
$BAjCL$K>h$C$FM_$7$/$F!"%a!<%k$7$F$_$^$7$?!#CK$N?M$G$9$h$M!)(B
$B!!%a!<%k=P$7$?;~$+$iF,$NCf$O$3$N=P2q$$$N;v$G0l?'@w$^$C$A$c(B
$B$C$F$$$^$9!#$=$A$i$O;d$N;v$I$&;W$$$^$9$+!)(B($B6[D%46!*!)!K$:(B
$B$C$HG:$s$G$$$^$7$?
hi,
i hope it's ok to ask this question here.
i just want to know more about poll_cq().
the standard seems to define only the input/ouput-params.
after reading the code i figured out that there is some kind of
"mapping" from libibverbs to the device specific "plugin" (mthca).
so it looks like that
Hal Rosenstock wrote:
On Mon, 2005-10-24 at 14:24, Eitan Zahavi wrote:
How do you get the old versions of this ?
It is in the main trunk ...
https://openib.org/svn/gen2/trunk/src/userspace/management/osm/doc/OpenS
M_UM.pdf
That's older than 1.7.1 1.7.0 manuals you had mentioned. Maybe not
Hal Rosenstock wrote:
On Mon, 2005-10-24 at 14:38, Eitan Zahavi wrote:
Hal Rosenstock wrote:
On Mon, 2005-10-24 at 03:08, Eitan Zahavi wrote:
I would suggest to use SNMP for the tasks below. IETF IPoIB group
has
defined an SNMP MIB that can support the required functionality
below.
$B!V$O$8$a$^$7$F!#%^%j$C$F$^$9!#$$$-$J$j$N%a!<%k$4$a$s$J(B
$B$5$$!#(B
$BAjCL$K>h$C$FM_$7$/$F!"%a!<%k$7$F$_$^$7$?!#CK$N?M$G$9$h$M!)(B
$B!!%a!<%k=P$7$?;~$+$iF,$NCf$O$3$N=P2q$$$N;v$G0l?'@w$^$C$A$c(B
$B$C$F$$$^$9!#$=$A$i$O;d$N;v$I$&;W$$$^$9$+!)(B($B6[D%46!*!)!K$:(B
$B$C$HG:$s$G$$$^$7$?
64 matches
Mail list logo
