[openib-general] Re: [PATCH][16/26] IB/mthca: mem-free doorbell record writing
Quoting r. Roland Dreier [EMAIL PROTECTED]: Subject: Re: [PATCH][16/26] IB/mthca: mem-free doorbell record writing Jeff Well, we don't just add code to hope and pray for an event Jeff that nobody is sure can even occur... The hardware requires that if the record is written in two 32-bit chunks, then they must be written in order. Of course the hardware probably won't be reading just as we're writing, so almost all of the time we won't notice the problem. Its not necessarily related to reads. writes must arrive in order, even if the card is not reading at that time. -- MST - Michael S. Tsirkin ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] Problem when trying to compile management and libibverb
Hi, I get some troubles when trying to install the openib userspace gen2... When I try to compile the management part in gen2/trunk/src/userspace/management/libibcommon after the autogen and configure part I get an error with the Makefile : make[2]: rpath : command not found It seems that the LINK variable has no value (I tried with ld and ./libtool --mode=link gcc -g but still nothing...). And for the libibverb part, using autogen configure and make too, I get : make: *** No rule to make target src/libibverbs.la , necessary for all-am . Stop Thanks... ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] Problem when trying to compile management and libibverb
On Fri, 2005-03-04 at 09:46, Marc von Wyl wrote: I get some troubles when trying to install the openib userspace gen2... When I try to compile the management part in gen2/trunk/src/userspace/management/libibcommon after the autogen and configure part I get an error with the Makefile : make[2]: rpath : command not found It seems that the LINK variable has no value (I tried with ld and ./libtool --mode=link gcc -g but still nothing...). And for the libibverb part, using autogen configure and make too, I get : make: *** No rule to make target src/libibverbs.la , necessary for all-am . Stop Not sure I totally follow what you did. I presume you followed the instructions in management/README and ran autogen.sh and configure in the library directories to generate your makefiles before running make. If so, not sure why LINK would not be defined. It gets generated in my Makefile as: LINK = $(LIBTOOL) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) \ $(AM_LDFLAGS) $(LDFLAGS) -o $@ where CCLD = $(CC) Have you built this before or is this the first time ? What distribution are you using ? Can you send your Makefile which was generated for one of these libraries ? Thanks. -- Hal ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] Problem when trying to compile management and libibverb
Hal Rosenstock a écrit : Not sure I totally follow what you did. I presume you followed the instructions in management/README and ran autogen.sh and configure in the library directories to generate your makefiles before running make. If so, not sure why LINK would not be defined. It gets generated in my Makefile as: LINK = $(LIBTOOL) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) \ $(AM_LDFLAGS) $(LDFLAGS) -o $@ where CCLD = $(CC) Have you built this before or is this the first time ? What distribution are you using ? Can you send your Makefile which was generated for one of these libraries ? Thanks. -- Hal I found the problem... I was looking in the wrong direction since two days... It was a problem with automake. Thanks and sorry for the disturbance. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] Re: [PATCH][16/26] IB/mthca: mem-free doorbell record writing
Michael Its not necessarily related to reads. writes must arrive Michael in order, even if the card is not reading at that time. We're talking about doorbell records in host memory, not MMIO doorbell writes. So there's no way for the HCA to know that host memory was written out of order unless it happens to read in the middle. - R. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] Re: [PATCH][3/26] IB/mthca: improve CQ locking part 1
On Thu, Mar 03, 2005 at 05:02:36PM -0800, Roland Dreier wrote: Greg Sure, I have no problem accepting that into the pci core. What would pci_irq_sync() do exactly? Consolidate common code like this? :) thanks, greg k-h ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] Re: [PATCH][3/26] IB/mthca: improve CQ locking part 1
Roland What would pci_irq_sync() do exactly? Greg Consolidate common code like this? :) I don't see how one can do that. As I pointed out in my reply to Jeff, it actually requires understanding how the driver uses the different MSI-X vectors to know which vector we need to synchronize against. So it seems pci_irq_sync() would have to be psychic. If we can figure out how to do that, maybe we can consolidate a lot more code into an API like void do_what_i_mean(void); ;) - R. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] Re: [RFC] userspace CM/verbs QP
I thought about this a little more. There is a problem with letting the CM module look up QPs in the userspace verbs table: it becomes very awkward to check that the the QP belongs to a context (== userspace verbs file descriptor) owned by the CM user. I see the following solutions: 1. Don't worry about checking. There's nothing too evil a CM user can do with a QP beyond getting another QP to connect to it, since the CM user can't modify a QP unless it legitimately owns it. And an evil user can always guess the QPN instead of the QP handle anyway. 2. Change the CM API so that it just takes the QPN, QP type, SRQ status and device directly rather than reading it out of the QP. This lets the userspace CM just get the info from userspace without needing to look at the QP at all. Of course it does raise the issue of how userspace should specify the device. 3. Merge the userspace CM into userspace verbs support so they use the same context. Ugh. Personally I would lean slightly towards #2, since it feels to me like even the kernel CM API would be cleaner that way. However I don't have a good answer for how userspace should specify which device to use. - R. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] Re: [RFC] userspace CM/verbs QP
On Fri, Mar 04, 2005 at 08:58:41AM -0800, Roland Dreier wrote: I thought about this a little more. There is a problem with letting the CM module look up QPs in the userspace verbs table: it becomes very awkward to check that the the QP belongs to a context (== userspace verbs file descriptor) owned by the CM user. I see the following solutions: 1. Don't worry about checking. There's nothing too evil a CM user can do with a QP beyond getting another QP to connect to it, since the CM user can't modify a QP unless it legitimately owns it. And an evil user can always guess the QPN instead of the QP handle anyway. 2. Change the CM API so that it just takes the QPN, QP type, SRQ status and device directly rather than reading it out of the QP. This lets the userspace CM just get the info from userspace without needing to look at the QP at all. Of course it does raise the issue of how userspace should specify the device. As you say, the second solution does not resolve the issue about which you are worried in the first solution. The device issue I think still creates a dependancy between the kernel components of uverbs and ucm, it's just moved down the chain, since the only thing that has the user to kernel mapping of the device handle is uverbs. Unless that code is duplicated, and then it becomes a software maintenance dependency... Personally I would lean slightly towards #2, since it feels to me like even the kernel CM API would be cleaner that way. However I don't have a good answer for how userspace should specify which device to use. I'm still leaning towards #1, if it comes down to a choice between device or QP that needs to be exposed, the QP seems more intuitive to me. -Libor ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] Re: [RFC] userspace CM/verbs QP
Libor As you say, the second solution does not resolve the Libor issue about which you are worried in the first Libor solution. The device issue I think still creates a Libor dependancy between the kernel components of uverbs and ucm, Libor it's just moved down the chain, since the only thing that Libor has the user to kernel mapping of the device handle is Libor uverbs. Unless that code is duplicated, and then it becomes Libor a software maintenance dependency... Yeah, you're right. OK, let's just export the QP handle lookup/release stuff from uverbs. - R. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] Re: [RFC] userspace CM/verbs QP
Libor Michalek wrote: 2. Change the CM API so that it just takes the QPN, QP type, SRQ status and device directly rather than reading it out of the QP. This lets the userspace CM just get the info from userspace without needing to look at the QP at all. Of course it does raise the issue of how userspace should specify the device. As you say, the second solution does not resolve the issue about which you are worried in the first solution. The device issue I think still creates a dependancy between the kernel components of uverbs and ucm, it's just moved down the chain, since the only thing that has the user to kernel mapping of the device handle is uverbs. Unless that code is duplicated, and then it becomes a software maintenance dependency... The CM needs the device in order to locate which port to send out the connection REQ on. We could let the CM locate the device in the kernel based on the user's path record. This goes back a little to the discussion of having a cm_path field in the REQ parameter that the CM can use when sending the REQ. On the receiving side of the REQ, the CM knows the device based on which port the REQ came in on. In order to make this work, there needs to be a call similar to: ib_find_cached_device_gid(gid, device, port_num, index); The CM already needs something like this call in order to perform SIDR. (See cm_find_device() in cm.c.) Support for this call requires some changes/exposure to the known device list. So, I think that we may be able to change the kernel CM API to take the necessary fields, rather than the QP pointer. I can make doing these changes a priority over RMPP if we decide to go this route. - Sean ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
RE: [openib-general] IB Address Translation service
On Wed, 2005-03-02 at 11:26 -0500, James Lentini wrote: tduffy The one thing that ATS provide and is not possible with tduffy ARP is reverse resolution GID-IP, any ideas how to achieve tduffy that without ATS ? tduffy tduffy RARP. Where is the encapsulation of RARP packets on IB defined? The Transmission of IP over InfiniBand IETF draft specifies the procedure for ARP and Neighbor Discovery, but not RARP. I do see some mention of RARP in the ipoib IETF draft, but it may not be fully flushed out. 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. -tduffy signature.asc Description: This is a digitally signed message part ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[Fwd: Re: [openib-general] Solaris IPoIB MTU with OpenSM]
Hi again Nitin, Finally got a chance to work on this. I have a workaround for you for now. Real patch later... Let me know if this does the trick for you. It did for me. -- Hal Index: osm_sa_mcmember_record.c === --- osm_sa_mcmember_record.c(revision 1953) +++ osm_sa_mcmember_record.c(working copy) @@ -1522,9 +1522,11 @@ if ((IB_MCR_COMPMASK_PROXY comp_mask) (p_rcvd_rec-proxy_join != p_mgrp-mcmember_rec.proxy_join)) goto Exit; +#if 0 /* if defined MUST match exactly !*/ if ((IB_MCR_COMPMASK_MTU_SEL comp_mask) ((p_rcvd_rec-mtu 6) != (p_mgrp-mcmember_rec.mtu 6))) goto Exit; +#endif if ((IB_MCR_COMPMASK_MTU comp_mask) ((p_rcvd_rec-mtu 0x3F) != (p_mgrp-mcmember_rec.mtu 0x3F))) goto Exit; -Forwarded Message- From: Hal Rosenstock [EMAIL PROTECTED] To: Nitin Hande [EMAIL PROTECTED] Cc: openib openib-general@openib.org, Tom Duffy [EMAIL PROTECTED] Subject: Re: [openib-general] Solaris IPoIB MTU with OpenSM Date: 24 Feb 2005 08:42:23 -0500 Hi Nitin, On Wed, 2005-02-23 at 17:19, Nitin Hande wrote: Hal, [comments below] On Wed, 2005-02-23 at 02:19, Hal Rosenstock wrote: On Tue, 2005-02-22 at 22:56, Nitin Hande wrote: So I tried the latest patches and preliminarily things seem to be working fine. Yipee. [snip..] So after this test above, I try to run snoop on the solaris interface and get the following error message from the layer below IPoIB: Feb 22 19:50:25 dongon.SFBay.Sun.COM ibd: [ID 517869 kern.info] NOTICE: ibd0: HCA GUID 0002c901097651d0 port 1 PKEY Could not get list of IBA multicast groups My preliminary assumption is that OpenSm is not returning the list of multicast groups that the ibd interface has joined. I will look at the MAD's tomorrow and try to ascertain that. How does S10 request this ? Remember that if it is a GetTable and doesn't fit in a single MAD, it will be broken now. If that is the case, we will live with this until we have real RMPP. Below is an an example of a single GetTable request and response between Solaris and OpenSM. OpenSM is not reporting the MCgroups in case of a single request/response. I have also provided a MAD output between Solaris IPoIB driver and IBSRM single GetTable request response below this example. Here is the MAD trace between solaris and OpenSM: Outgoing MAD: BaseVersion: 0x1 MgmtClass: 0x3 - SubnAdm ClassVersion: 0x2 R_Method: 0x12 - SubnAdmGetTable() Status: 0x0 - NO_ERROR ClassSpecific: 0x0 TransactionID: 0x97651d100ec AttributeID: 0x38 - SA_MCMEMBERRECORD_ATTRID 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 0: 01 03 02 12 00 00 00 00 09 76 51 d1 00 00 00 ec .vQ. 10: 00 38 00 00 ff ff ff ff 00 00 00 00 00 00 00 00 .8.. 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 80 b4 00 00 00 00 00 00 00 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 0b 1b 00 00 84 00 60: ff ff 00 00 00 00 00 00 20 00 00 00 00 00 00 00 ... 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Incoming MAD: BaseVersion: 0x1 MgmtClass: 0x3 - SubnAdm ClassVersion: 0x2 R_Method: 0x92 - Status: 0x0 - NO_ERROR ClassSpecific: 0x0 TransactionID: 0x97651d100ec AttributeID: 0x38 - SA_MCMEMBERRECORD_ATTRID 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 0: 01 03 02 92 00 00 00 00 09 76 51 d1 00 00 00 ec .vQ. 10: 00 38 00 00 ff ff ff ff 01 01 77 00 00 00 00 01 .8w. 20: 00 00 00 14 00 00 00 00 00 00 00 00 00 07 00 00 30: 00 00 00 00 00 00 80 b4 00 00 00 00 00 00 00 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00
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-something. Since DHCP, I don't think there's a reason for hosts to do it. Here's what comes out when I type man rarp on a 2.6 system. Obsolete. RARP(8) Linux Programmer's Manual RARP(8) NAME rarp - manipulate the system RARP table SYNOPSIS rarp [-V] [--version] [-h] [--help] rarp -a rarp [-v] -d hostname ... rarp [-v] [-t type] -s hostname hw_addr NOTE This program is obsolete. From version 2.3, the Linux kernel no longer contains RARP support. For a replacement RARP daemon, see ftp://ftp.dementia.org/pub/net-tools Tom. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [MAD] RMPP reassembly
Sean Hefty wrote: I'm studying the RMPP implementation requirements for reassembly, and there are a couple of issues/questions. * In order to send RMPP ACKs, etc. the RMPP code needs access to a MR (LKey actually) usable with the registered mad_agent. Both the CM and SA query code call ib_get_dma_mr() after calling ib_register_mad_agent(), and I would expect that other code will be similar. I was considering adding an ib_mr* field to the mad_agent structure and returning it to the user. Any objections or comments? - Sean ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [MAD] RMPP reassembly
Sean * In order to send RMPP ACKs, etc. the RMPP code needs Sean access to a MR (LKey actually) usable with the registered Sean mad_agent. Both the CM and SA query code call Sean ib_get_dma_mr() after calling ib_register_mad_agent(), and I Sean would expect that other code will be similar. I was Sean considering adding an ib_mr* field to the mad_agent Sean structure and returning it to the user. Any objections or Sean comments? We discussed this once back in September of last year. For some reason we decided that the consumer was responsible for managing memory registration, but I don't remember why. - R. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [MAD] RMPP reassembly
Roland Dreier wrote: Sean * In order to send RMPP ACKs, etc. the RMPP code needs Sean access to a MR (LKey actually) usable with the registered Sean mad_agent. We discussed this once back in September of last year. For some reason we decided that the consumer was responsible for managing memory registration, but I don't remember why. I can't remember either, but I don't know if we thought about internally generated MADs sent on behalf of the user. I will continue to try to find that discussion. At a minimum, the RMPP code either needs the user to provide a MR that it can use when registering for the MAD service, or it needs to allocate one internally. If the latter approach is used, exposing it to the user seems to make sense. For QP 0/1 traffic, the RMPP layer could cheat a little and allocate a single MR per port, rather than per mad_agent, similar to what the CM and SA module do. But then a different method would be needed if we ever wanted to support RMPP on a redirected QP. - Sean ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] Re: Incorrect endian in GUID comparison/SM master selection
Hello again,
I found another place in OpenSM where it compares two SM's. I suggest
the following both to fix it and to form a common comparison routine:
--- osm_sminfo_rcv.c4 Mar 2005 23:21:53 - 1.2.2.4
+++ osm_sminfo_rcv.c5 Mar 2005 00:45:03 -
@@ -156,30 +156,15 @@ osm_sminfo_rcv_init(
By higher - we mean: SM with higher priority or with same priority
and lower GUID.
**/
-boolean_t
+inline boolean_t
__osm_sminfo_rcv_remote_sm_is_higher (
IN const osm_sminfo_rcv_t* p_rcv,
IN const ib_sm_info_t* p_remote_sm )
{
-
-
- if( ib_sminfo_get_priority( p_remote_sm )
- p_rcv-p_subn-opt.sm_priority )
- {
-return( TRUE );
- }
- else
- {
-if( ib_sminfo_get_priority( p_remote_sm ) ==
-p_rcv-p_subn-opt.sm_priority )
-{
- if( p_remote_sm-guid p_rcv-p_subn-sm_port_guid )
- {
-return( TRUE );
- }
-}
- }
- return( FALSE );
+ return( osm_sm_is_greater_than( ib_sminfo_get_priority( p_remote_sm
),
+ p_remote_sm-guid,
+ p_rcv-p_subn-opt.sm_priority,
+ p_rcv-p_subn-sm_port_guid) );
}
/**
--- osm_state_mgr.c 4 Mar 2005 23:15:42 - 1.2.2.6
+++ osm_state_mgr.c 5 Mar 2005 00:45:03 -
@@ -1563,12 +1563,19 @@ __osm_state_mgr_get_highest_sm(
{
cl_qmap_t* p_sm_tbl;
osm_remote_sm_t* p_sm = NULL;
- osm_remote_sm_t*p_highest_sm = NULL;
+ osm_remote_sm_t* p_highest_sm;
+ uint8_t highest_sm_priority;
+ ib_net64_t highest_sm_guid;
OSM_LOG_ENTER( p_mgr-p_log, __osm_state_mgr_get_highest_sm );
p_sm_tbl = p_mgr-p_subn-sm_guid_tbl;
+ /* Start with the local sm as the standard */
+ p_highest_sm = NULL;
+ highest_sm_priority = p_mgr-p_subn-opt.sm_priority;
+ highest_sm_guid = p_mgr-p_subn-sm_port_guid;
+
/* go over all the remote SMs */
for( p_sm = (osm_remote_sm_t*)cl_qmap_head( p_sm_tbl );
p_sm != (osm_remote_sm_t*)cl_qmap_end( p_sm_tbl );
@@ -1579,55 +1586,19 @@ __osm_state_mgr_get_highest_sm(
if (ib_sminfo_get_state(p_sm-smi) == IB_SMINFO_STATE_NOTACTIVE )
continue;
-if ( p_highest_sm == NULL)
+if ( osm_sm_is_greater_than( ib_sminfo_get_priority(p_sm-smi),
+ p_sm-smi.guid, highest_sm_priority, highest_sm_guid ) )
{
+ /* the new p_sm is with higher priority - update the highest_sm
*/
+ /* to this sm */
p_highest_sm = p_sm;
-}
-else
-{
- if ( ib_sminfo_get_priority(p_sm-smi)
- ib_sminfo_get_priority(p_highest_sm-smi) )
- {
-/* the new p_sm is with higher priority - update the
highest_sm */
-/* to this sm */
-p_highest_sm = p_sm;
- }
- else
- {
-if ( ib_sminfo_get_priority(p_sm-smi) ==
- ib_sminfo_get_priority(p_highest_sm-smi) )
-{
- /* both SMs are with same priority - compare GUIDs */
- if ( p_sm-smi.guid p_highest_sm-smi.guid )
- {
-/* the new p_sm is with same priority but lower GUID - */
-/* update the highest sm to this sm */
-p_highest_sm = p_sm;
- }
-}
- }
+ highest_sm_priority = ib_sminfo_get_priority(p_sm-smi);
+ highest_sm_guid = p_sm-smi.guid;
}
}
- /* compare the p_highest_sm to the local sm */
+
if ( p_highest_sm != NULL )
{
-/* check if this SM is higher then us */
-if ( p_mgr-p_subn-opt.sm_priority
- ib_sminfo_get_priority(p_highest_sm-smi) )
-{
- /* the local SM has higher priority */
- return( NULL );
-}
-else
-{
- if( ib_sminfo_get_priority(p_highest_sm-smi) ==
-p_mgr-p_subn-opt.sm_priority
-p_highest_sm-smi.guid p_mgr-p_subn-sm_port_guid )
- {
-/* they have same priority. Local SM has lower GUID */
-return( NULL );
- }
-}
osm_log( p_mgr-p_log, OSM_LOG_DEBUG,
__osm_state_mgr_get_highest_sm:
Found higher SM with guid: %016 PRIx64 \n,
--- osm_state_mgr.h 23 Sep 2004 18:43:08 - 1.2
+++ osm_state_mgr.h 5 Mar 2005 00:45:03 -
@@ -495,6 +495,62 @@ osm_state_mgr_process(
* SEE ALSO
* State Manager
*/
+/f* OpenSM: State Manager/osm_sm_is_greater_than
+* NAME
+* osm_sm_is_greater_than
+*
+* DESCRIPTION
+* Compares two SM's (14.4.1.2)
+*
+* SYNOPSIS
+*/
+static inline boolean_t
+osm_sm_is_greater_than (
+ IN const uint8_tl_priority,
+ IN const ib_net64_t l_guid,
+ IN const uint8_tr_priority,
+ IN const ib_net64_t r_guid )
+{
+ if( l_priority r_priority )
+ {
+return( TRUE );
+ }
+ else
+ {
+if( l_priority == r_priority )
+{
+ if( cl_ntoh64(l_guid) cl_ntoh64(r_guid) )
+ {
+return( TRUE );
+ }
+}
+ }
+ return( FALSE );
+}
Re: [openib-general] IB Address Translation service
On Fri, Mar 04, 2005 at 11:58:33AM -0800, 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. Much more important is understanding the role of RARP in the ethernet world. It is *not* something you do to find _someone else's_ IP addr from their MAC addr. It's what you do to find your _own_ IP addr because you're booting. Ethernet protocols such as IP include enough IP information to talk back to someone who sent you a packet. So you don't need to find out an IP addr from a MAC for remote nodes on a regular basis. Instead, you find out a MAC addr from an IP address, which is ARP. RARP is little used now that DHCP is popular. Now it would be nice for ethernet broadcast packets to just work(tm) with IPoIB. ping -b is an example of a user-level program that generates a broadcast packet. DHCP clients also generate such packets, and DHCP servers listen for them. Getting a RARP client and server to work ought to be the same as a DHCP client and server. -- greg ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
RE: [openib-general] IB Address Translation service
On Fri, 2005-03-04 at 16:06 -0500, Talpey, Thomas wrote: 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-something. Since DHCP, I don't think there's a reason for hosts to do it. I guess Sun is stuck in the 80's -- big hair and new age music. All the sparc openboot systems rarp/bootp to network start. -tduffy signature.asc Description: This is a digitally signed message part ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
