Re: [openib-general] mapping between IP address and device name

At 05:34 PM 6/27/2005, Roland Dreier wrote: >I'm not sure I understand this. At best, ATS can give you back a list >of IPs. How do you decide which one to check against the exports? Any or all of them. Exports is a fairly simple access list, and membership by the client is all that's required. I

RE: [openib-general] mapping between IP address and device name

At 03:10 AM 6/26/2005, Itamar Rabenstein wrote: >But the ATS will not solve the problem of "many to one". >What will the nfs module will do if the the result from the ATS will be >a list of "IP's" which only one of them is has permission to the nfs ? >ATS cant tell you who is the source IP. The N

Re: [openib-general] mapping between IP address and device name

At 02:27 PM 6/24/2005, Hal Rosenstock wrote: >On Fri, 2005-06-24 at 13:51, Talpey, Thomas wrote: >> mentioned earlier. For better or for worse, the ATS approach is easily >> administered and does not impact any protocol layers outside of its >> own. I think of it as ARP for I

Re: [openib-general] mapping between IP address and device name

At 01:30 PM 6/24/2005, Roland Dreier wrote: >Thomas> But in the absence of one, I like what we have. Also, I do >Thomas> not want to saddle the NFS/RDMA transport with carrying an >Thomas> IP address purely for the benefit of a missing transport >Thomas> facility. After all NFS/RDMA

Re: [openib-general] mapping between IP address and device name

At 01:22 PM 6/24/2005, Roland Dreier wrote: >Hal> But we do trust the kernel, right ? > >No, an NFS server can't trust anything coming from a remote client. Well, the server can't trust untrusted information coming from the client. NFS has many forms of strong authentication. But many, many us

Re: [openib-general] mapping between IP address and device name

At 12:42 PM 6/24/2005, Roland Dreier wrote: >Thomas> But that's totally and completely insecure. The goal of >Thomas> /etc/exports is to place at least part of the client >Thomas> authentication in the network rather than the supplied >Thomas> credentials. NFS has quite enough of a

Re: [openib-general] mapping between IP address and device name

At 01:02 PM 6/24/2005, Jay Rosser wrote: >On the subject of NFS/RDMA, what is the IB ServiceID space that is used? >If I recall correctly, I have seen simply the value 2049 (i.e. the >standard TCP/UDP port number) used in some implementations (i.e. 00 00 >00 00 00 00 20 49). Is there a mapping o

Re: [openib-general] mapping between IP address and device name

At 12:19 PM 6/24/2005, Roland Dreier wrote: >It seems far preferable to me to just define the wire protocol of >NFS/RDMA for IB such that a client passes its IP address as part of >the connection request. This scheme was used for SDP to avoid >precisely the complications that we're discussing now.

Re: [openib-general] mapping between IP address and device name

At 01:31 PM 6/23/2005, Roland Dreier wrote: >James> kDAPL uses this feature to provide the passive side of a >James> connection with the IP address of the remote peer. kDAPL >James> consumers can use this information as a weak authentication >James> mechanism. > >This seems so weak

Re: [openib-general] Re: [PATCH] kDAPL: remove dapl_os_assert()

At 05:09 PM 6/23/2005, Grant Grundler wrote: >On Thu, Jun 23, 2005 at 04:55:38PM -0400, James Lentini wrote: >> My argument in favor of retaining them is that dapl_evd_wc_to_event() >> will crash if the cookie NULL. A BUG_ON will detect this situation ... >The tombstone from the data page fault p

Re: [openib-general] NFS/RDMA/kDAPL

At 04:11 PM 6/23/2005, Tom Duffy wrote: >I am new to NFSoRDMA. Where do I start? Is there a good doc about >how to set it up? Consult your OpenSolaris documentation? :-) Seriously, there isn't a cookbook for Linux, because we're not there yet. But it's not too hard. I will plan to roll up the u

[openib-general] NFS/RDMA/kDAPL

At 03:11 PM 6/23/2005, Tom Duffy wrote: >On Thu, 2005-06-23 at 13:54 -0400, Talpey, Thomas wrote: >> We look forward to running NFS/RDMA over OpenIB, when its kDAPL >> is ready. > >Let's get NFSoRDMA going sooner rather than later on James's kDAPL. I >think thi

Re: [openib-general] A new simple ulp (SPTS)

At 01:11 PM 6/23/2005, Jeff Carr wrote: >I didn't know there was a nfs/rmda module? > >[EMAIL PROTECTED]:/test/gen2# find . |grep -i nfs >[EMAIL PROTECTED]:/test/gen2# Brief intro to NFS/RDMA work: Current client version is on Sourceforge, supporting various flavors of 2.4. I'm preparing a new re

Re: [openib-general] A new simple ulp (SPTS)

At 12:43 PM 6/22/2005, Jeff Carr wrote: >On 06/21/2005 12:50 PM, Roland Dreier wrote: > >> What happens if you try replacing the send_flags line with the one you >> have commented out? >> >> +// send_wr.send_flags = IB_SEND_SIGNALED; > >Thanks, you are correct. IB_SEND_SIGNALED gives me the be

RE: [openib-general] kdaptest wedges server

At 08:44 PM 6/14/2005, Josh England wrote: >On another note, has anyone got a *bare-bones* kdapl/udapl example with >connection setup and RDMA send/receive. Define bare bones? If you go to the Sourceforge version of dapl (http://sourceforge.net/projects/dapl) you can take a look at the dat_echo di

RE: [openib-general] [PATCHv2][RFC] kDAPL: use cm timers instead of own

At 09:49 AM 6/14/2005, Hal Rosenstock wrote: >Are you proposing that the number of retries be set to 0 then >(regardless of the timeout requested) ? All I am suggesting is that the number of retries is not something the consumer can or should be specifying. Whatever the appropriate number is, is s

RE: [openib-general] [PATCHv2][RFC] kDAPL: use cm timers instead of own

At 08:41 AM 6/14/2005, Hal Rosenstock wrote: >The current implementation is: >1. address resolution phase for some amount of time >followed by: >2. dapl_ib_connect timeout * 5 (since there are 4 retries) > >A better algorithm would be to divide down the timeout by some number of >retries (which wo

Re: [openib-general] [PATCH][RFC] kDAPL: remove dat wrapper funct ion dat_ia_query()

At 05:20 AM 6/11/2005, Christoph Hellwig wrote: >Currently every dapl object embedds dapl_common which has a pointer >to the dapl_ia. Now fixing that mess up a little every dat object >can have a dat_ia pointer (without the utter _common braindamage) >and there's one additional dereference, while

Re: [openib-general] [PATCHv3][RFC] kDAPL: use cm timers instead of own

At 05:55 PM 6/1/2005, Tom Duffy wrote: >I was looking at some of the ULPs. SDP sets the timeout to 20, without >explanation. DAPL has a #define (set to 20 saying it is 4 sec in a >comment). simple example? Set to 20, no reason. To me, it ends up >just being this opaque value. Maybe some pre#d

Re: [openib-general] [PATCHv3][RFC] kDAPL: use cm timers instead of own

At 05:26 PM 6/1/2005, Sean Hefty wrote: >The time format is IB architecture specific. The CM is exposing a field >value defined by the spec. If a different format would be a better >alternative, we can look at changing it. Okay. (But, the spec requires it to be a u8? Sheesh) Anyway, I vote fo

Re: [openib-general] [PATCHv3][RFC] kDAPL: use cm timers instead of own

At 04:19 PM 6/1/2005, Tom Duffy wrote: >> Do any of these tests intentionally trigger timer events? I don't think >> they do... > >Tom, do you know of a test that will? Can't think of one, actually. Seems like it would take some kind of error injection. Maybe drop the peer into a debugger while th

Re: [openib-general] [PATCHv3][RFC] kDAPL: use cm timers instead of own

At 03:48 PM 6/1/2005, Tom Duffy wrote: >This patch takes into account some of the feedback by Sean, it sets the >retry to 0, so it will do the timeout right. It also stops the >conversion of ms to ib at 63 since 64 overflows. I have tested this >version using kdapltest in quit, performance, and t

Re: [Rdma-developers] Re: [openib-general] OpenIB and OpenRDMA: Convergence on common RDMAAPIs and ULPs for Linux

At 03:36 AM 6/1/2005, Christoph Hellwig wrote: >kDAPL is supposed to serve two needs: > (1) provide an unified API for different RDMA transports > (2) provide various higher level helpers >... >For (1) doing a proper RDMA stack should solve thing, and the discussion >how to do it is already ongoing

Re: [Rdma-developers] RE: [openib-general] OpenIB and OpenRDMA: Convergence on commonRDMA APIs and ULPs for Linux

I usually try to avoid sending messages like the following, but... Well said, Roland. TTKO - Time To Kernel dot Org. I for one want iWARP there along with IB. Before 2007. Before 2006! Tom. At 02:09 PM 5/27/2005, Roland Dreier wrote: >Caitlin> There isn't enough there to go farther. > >I

RE: [openib-general] OpenIB and OpenRDMA: Convergence on common RDMAAPIs and ULPs for Linux

At 11:49 AM 5/26/2005, Bob Woodruff wrote: >Finally, until there is some consensus about allowing TCP offload in Linux, >I see no need to start to hack up the InfiniBand stack to support iWarp. It is not a requirement that TCP offload be supported in order to support iWARP. Upper layers which do

Re: [openib-general] OpenIB and OpenRDMA: Convergence on common RDMA APIs and ULPs for Linux

At 08:45 AM 5/26/2005, Christoph Hellwig wrote: >>> >The sf.net mail archives are too f*d up to allow retrieving >attachments. Here it is again... My opinions/assertions only, presented at the April OpenRDMA f2f. Tom.

Re: [openib-general] OpenIB and OpenRDMA: Convergence on common RDMA APIs and ULPs for Linux

At 02:20 AM 5/26/2005, Venkata Jagana wrote: >I would like to really understand the technical reasons why you say RNIC-PI is >irrelevant to Linux kernel. >RNIC-PI is developed to support not only the RNICs but it is also IB >compatible. I'm not Roland, but my belief is that until RNIC-PI exists

RE: [openib-general] IB Address Translation service

At 02:58 PM 3/4/2005, Tom Duffy wrote: >In any event, I think being able to plop an IB network in an Ethernet >world will require things like RARP to work. If there is no spec now, >it should be written. I can't remember the last time I saw a machine RARP. Well, maybe I do but it was like 1980-so

kDAPL code size Re: [openib-general] putting in dead wood for DAPL and similarabomination

At 09:56 AM 3/3/2005, Talpey, Thomas wrote: >that. At present, the code is heavily commented and fully generalized to >aid porting to multiple operating systems. It will look quite different once >it is freed of these attributes. Also, I'll point out there is extensive debug >and

Re: [openib-general] putting in dead wood for DAPL and similarabomination

At 10:48 PM 3/2/2005, Christoph Hellwig wrote: >The current iSER code is 10928 LOC, add to that 22155 LOC of kDAPL (not >including the actual provider for IB) and 5822 LOC linux-iscsi kernel >code. Compare that to the 25412 LOC total for drivers/infiniband in Linux >2.6.11. Is this just about LOCs

RE: [openib-general] putting in dead wood for DAPL and similarabomination

At 02:22 PM 3/2/2005, Woodruff, Robert J wrote: >I think the point is that only one of those interconnects (IB) is >in the kernel, the rest are proprietary. Do any of the other RDMA >interconnect vendors plan to submit their code for inclusion into Linux >in the near future ? Yes - take a look a

RE: [openib-general] IB Address Translation service

At 01:15 PM 3/2/2005, Yaron Haviv wrote: >In order to issue a RARP I believe you should supply the full HW address >to get the IP address back, how would you know the remote IPoIB QPN ? or >can you do it without a QPN ? To say nothing of the fact that there must be a RARPD, administered and secure

Re: [openib-general] putting in dead wood for DAPL and similar abomination

At 05:05 PM 3/1/2005, Christoph Hellwig wrote: >Similar hint to the NFS over RDMA folks at CITI - >if you want your stuff to go in use the openib helper directly below >the transport switch - differnet RDMA transports are too diverse to >be sanely abstracted out and DAPL does a horrible job at that

<    1   2