Re: [openib-general] Re: [PATCH] fix race in mad.c

[Michael S. Tsirkin]

Quoting r. Sean Hefty <[EMAIL PROTECTED]>:
> Why wouldn't this work?
> 
> lock - check state - queue work - unlock
> 
> It shouldn't matter if ib_mad_thread_completion_handler() is running or not.

Right, I just tried to say you need to lock.

-- 
MST
___
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] typo fix in the description of ibv_modify_srq

[Dotan Barak]

Title: typo fix in the description of ibv_modify_srq






Mask names were fixed.


Signed-off-by: Dotan Barak <[EMAIL PROTECTED]>


Index: last_stable/src/userspace/libibverbs/include/infiniband/verbs.h

===

--- last_stable.orig/src/userspace/libibverbs/include/infiniband/verbs.h

+++ last_stable/src/userspace/libibverbs/include/infiniband/verbs.h

@@ -796,8 +796,8 @@ struct ibv_srq *ibv_create_srq(struct ib

  * @srq_attr_mask: A bit-mask used to specify which attributes of the SRQ

  *   are being modified.

  *

- * The mask may contain IB_SRQ_MAX_WR to resize the SRQ and/or

- * IB_SRQ_LIMIT to set the SRQ's limit and request notification when

+ * The mask may contain IBV_SRQ_MAX_WR to resize the SRQ and/or

+ * IBV_SRQ_LIMIT to set the SRQ's limit and request notification when

  * the number of receives queued drops below the limit.

  */

 int ibv_modify_srq(struct ibv_srq *srq,



Dotan Barak

Software Verification Engineer

Mellanox Technologies LTD

Tel: +972-4-9097200 Ext: 231 Fax: +972-4-9593245

P.O. Box 86 Yokneam 20692 ISRAEL.

Home: +972-77-8841095  Cell: 052-4222383


[ May the fork be with you ]



___
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] Patch for possible bug in ib_create_ah_from_wc()

[Ralph Campbell]

It looks like ib_create_ah_from_wc() doesn't create the correct
return address (AH) when there is a GRH present (source & dest GIDs
need to be swapped).

I think the following patch will fix the problem but I haven't
been able to test it yet.

Index: gen2/trunk/src/linux-kernel/infiniband/core/verbs.c
===
--- verbs.c (revision 4718)
+++ verbs.c (working copy)
@@ -106,9 +106,9 @@
 
if (wc->wc_flags & IB_WC_GRH) {
ah_attr.ah_flags = IB_AH_GRH;
-   ah_attr.grh.dgid = grh->dgid;
+   ah_attr.grh.dgid = grh->sgid;
 
-   ret = ib_find_cached_gid(pd->device, &grh->sgid, &port_num,
+   ret = ib_find_cached_gid(pd->device, &grh->dgid, &port_num,
 &gid_index);
if (ret)
return ERR_PTR(ret);

-- 
Ralph Campbell <[EMAIL PROTECTED]>

___
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] SA cache design

[Sean Hefty]

Hal Rosenstock wrote:
I've been given the task of trying to come up with an implementation for an SA 
cache.  The intent is to increase the scalability and performance of the openib 
stack.  My current thoughts on the implementation are below.  Any feedback is 
welcome.


To keep the design as flexible as possible, my plan is to implement the cache in 
userspace.  The interface to the cache would be via MADs.


Would this be another MAD class which mimics the SA class ?


I hadn't fully figured this out yet.  I'm not sure if another MAD class is 
needed or not.  My goal is to implement this as transparent to the application 
as possible without violating the spec, perhaps appearing as an SA on a 
different LID.


 Clients would send 
their queries to the sa_cache instead of the SA itself.  The format of the MADs 
would be essentially identical to those used to query the SA itself.  Response 
MADs would contain any requested information.  If the cache could not satisfy a 
request, the sa_cache would query the SA, update its cache, then return a reply.


The benefits that I see with this approach are:

+ Clients would only need to send requests to the sa_cache.
+ The sa_cache can be implemented in stages.  Requests that it cannot handle 
would just be forwarded to the SA.


Another option would be for the SA cache to indicate what requests its
handles (some MADs for this) and have the clients only go to the cache
for those queries (and direct to the SA for the others).


I thought about this, but this puts an additional burden on the clients. 
Letting the sa_cache forward the request allows it to send the requests to 
another sa_cache, rather than directly to the SA.  There's some additional 
flexibility that we gain in the long term design by forwarding requests.  (I'm 
thinking of the possibility of having an sa_cache hierarchy.)



+ The sa_cache could be implemented on each host, or a select number of hosts.
+ The interface to the sa_cache is similar to that used by the SA.
+ The cache would use virtual memory and could be saved to disk.

Some drawbacks specific to this method are:

- The MAD interface will result in additional data copies and userspace to 
kernel transitions for clients residing on the local system.
- Clients require a mechanism to locate the sa_cache, or need to make 
assumptions about its location.


Would SA caching be a service ID or set of IDs ?


I'd like the sa_cache to give the appearance of being a standard SA as much as 
possible.  One effect is that an sa_cache may not be able to run on the same 
node as the actual SA, but that restriction seems desirable to me.



Are there also issues around cache invalidation ?


I didn't list cache synchronization as an issue because I couldn't think of any 
problems that were specific to this design, versus being a general issue.


- 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] RE: [PATCH] [TRIVIAL] OpenSM: Separate out OSM_VERSION

[Hal Rosenstock]

Hi Troy,

On Tue, 2006-01-03 at 14:44, Troy Benjegerdes wrote:
> On Tue, Jan 03, 2006 at 11:01:43AM -0500, Hal Rosenstock wrote:
> > On Tue, 2006-01-03 at 10:43, Eitan Zahavi wrote:
> > > Hi Hal,
> > > 
> > > Sounds good.
> > > I think you should be able to use the .svn/entries to get the last
> > > update revision and then use svn diff (or diff) to see if local mods are
> > > done on top of it...
> > 
> > I'm using .svn/entries at the osm level.
> > 
> > > So we do not get caught by surprise when something broke due to
> > > un-committed mod in the local directory
> > > Thanks
> 
> The 'svnversion' command gives you the version, and then checks for
> local mods. No need to reinvent how to do that.

I think svnversion works off the ,svn/entries file anyhow so this is not
reinventing the how. It is slightly more flexible to rely on the actual
file than the command but I'm not adverse to using the command if there
is consensus from others on this.

-- 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] SA cache design

[Hal Rosenstock]

Hi Sean,

On Tue, 2006-01-03 at 19:42, Sean Hefty wrote:
> I've been given the task of trying to come up with an implementation for an 
> SA 
> cache.  The intent is to increase the scalability and performance of the 
> openib 
> stack.  My current thoughts on the implementation are below.  Any feedback is 
> welcome.
> 
> To keep the design as flexible as possible, my plan is to implement the cache 
> in 
> userspace.  The interface to the cache would be via MADs.

Would this be another MAD class which mimics the SA class ?

>   Clients would send 
> their queries to the sa_cache instead of the SA itself.  The format of the 
> MADs 
> would be essentially identical to those used to query the SA itself.  
> Response 
> MADs would contain any requested information.  If the cache could not satisfy 
> a 
> request, the sa_cache would query the SA, update its cache, then return a 
> reply.
> 
> The benefits that I see with this approach are:
> 
> + Clients would only need to send requests to the sa_cache.
> + The sa_cache can be implemented in stages.  Requests that it cannot handle 
> would just be forwarded to the SA.

Another option would be for the SA cache to indicate what requests its
handles (some MADs for this) and have the clients only go to the cache
for those queries (and direct to the SA for the others).

> + The sa_cache could be implemented on each host, or a select number of hosts.
> + The interface to the sa_cache is similar to that used by the SA.
> + The cache would use virtual memory and could be saved to disk.
> 
> Some drawbacks specific to this method are:
> 
> - The MAD interface will result in additional data copies and userspace to 
> kernel transitions for clients residing on the local system.
> - Clients require a mechanism to locate the sa_cache, or need to make 
> assumptions about its location.

Would SA caching be a service ID or set of IDs ?

Are there also issues around cache invalidation ?

-- 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

[openib-general] SA cache design

[Sean Hefty]

I've been given the task of trying to come up with an implementation for an SA 
cache.  The intent is to increase the scalability and performance of the openib 
stack.  My current thoughts on the implementation are below.  Any feedback is 
welcome.


To keep the design as flexible as possible, my plan is to implement the cache in 
userspace.  The interface to the cache would be via MADs.  Clients would send 
their queries to the sa_cache instead of the SA itself.  The format of the MADs 
would be essentially identical to those used to query the SA itself.  Response 
MADs would contain any requested information.  If the cache could not satisfy a 
request, the sa_cache would query the SA, update its cache, then return a reply.


The benefits that I see with this approach are:

+ Clients would only need to send requests to the sa_cache.
+ The sa_cache can be implemented in stages.  Requests that it cannot handle 
would just be forwarded to the SA.

+ The sa_cache could be implemented on each host, or a select number of hosts.
+ The interface to the sa_cache is similar to that used by the SA.
+ The cache would use virtual memory and could be saved to disk.

Some drawbacks specific to this method are:

- The MAD interface will result in additional data copies and userspace to 
kernel transitions for clients residing on the local system.
- Clients require a mechanism to locate the sa_cache, or need to make 
assumptions about its location.


I'm sure that there are other benefits and drawbacks that I'm missing.

- 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] [ANNOUNCE] Updated OpenIB diagnostics

[Hal Rosenstock]

Hi Eitan,

On Sun, 2006-01-01 at 05:12, Eitan Zahavi wrote:
> Hi Hal,
> 
> Do you expect the system administrator to manually fill in the
> discover.map including ALL nodes in the fabric, their guids and "name"? 

Yes, although tools can assist with extracting the GUIDs, the names need
annotation.

> For a large cluster that number is quite large.
> 
> In the past I was proposing using "system IB connectivity model"* (IBNL)
> for providing similar but superior capability.

How are the names configured using this approach ?

>  Using IBNL describing
> each system type (should be provided by the system vendor - or extracted
> once for each system type) the administrator can avoid the need to fill
> in the data (guid and name) for every node in the cluster. 

The names in the discover tool are not system type. They are more like
system location (descriptive name) although there is no requirement.

> The administrator can select one of two** options:
> 1. Write a "system-level-topology"*** file to describe the expected
> topology instantiating systems only (not devices). This topology file is
> then compared versus the discovered topology and used (the names from
> the file as well as link width and speed) by all diagnostic tools for
> reporting errors.

How are board swaps within a system reported ?

> 2. Write "annotation" file (ala discover.map syntax) that includes as
> few as one device per system such that the extracted node level topology
> could be matched against that spec and mapped dynamically.

This seems to me like the analog. The difference is that one device gets
a name. That will occur within OpenIB once the system boundary work is
implemented (logical to physical mapping).

> * IBNL is describes the IB connectivity inside a system in a
> hierarchical manner.

Yes, it needs to be hierarchial.

>   It enables specifying link width and speed inside the box and on the
> system interface. 
>   These properties are automatically propagated to the created topology
> - and enables   
>   their validation on the extracted topology.
>   The topology created hold both the system-to-system connectivity layer
> as well as the 
>   flattened IB node and link layer (the later is similar to the
> discover.topo). As IBNL is 
>   describing the systems a common naming scheme for the devices in each
> such system 
>   is provided by the system vendor and not freely annotated by the
> system dministrator. 

Why shouldn't the system admin be allowed to use a name friendly to them
? It should point to a device type which is supplied by the vendor.

-- Hal

>   Such that any error reported (like bad internal link or device) can be
> easily understood 
>   by the vendor too. Furthermore, when several devices misbehave - the
> code can 
>   correlate them to a specific board in the system  and report the
> problem once for that 
>   entire board (this is demonstrated today by code under the ibdm tree -
> see below).
> 
> ** Having a "spec topology" has great advantages over extracted one:
>   Several utilities let you:
>   + Analyze your topology even before one cable is laid out for credit
> loops, num hops,
>  asymmetrical routing patterns, etc
>   + Find routing errors that may very well happen on large cluster due
> to the 
>  human process of connecting thousand of cables.
>   + Find links that did not start up in the right speed or width due to
> bad cables or their
>  connections.
> 
> *** By "system-level-topology" I mean a file that is made of the list of
> systems and not the list of IB nodes (embedded within this system). For
> large cluster using 288 port switch systems the number of elements in
> the file is reduced 32 times...
> 
> The code to allow the option 1 is available under:
> https://openib.org/svn/gen2/utils/src/linux-user/ibdm
> 
> To support option 2 this code could be easily enhanced with a new
> "annotation" algorithm.
> 
> 
> Eitan Zahavi
> Design Technology Director
> Mellanox Technologies LTD
> Tel:+972-4-9097208
> Fax:+972-4-9593245
> P.O. Box 586 Yokneam 20692 ISRAEL
> 
> 
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:openib-general-
> > [EMAIL PROTECTED] On Behalf Of Hal Rosenstock
> > Sent: Saturday, December 31, 2005 8:07 PM
> > To: openib-general@openib.org
> > Subject: [openib-general] [ANNOUNCE] Updated OpenIB diagnostics
> > 
> > Hi,
> > 
> > The OpenIB diagnostics
> > (https://openib.org/svn/gen2/trunk/src/userspace/management/diags)
> have
> > been updated as follows:
> > 
> > 1. discover.pl diagnostic tool added
> > discover.pl uses a topology file create by ibnetdiscover and a
> discover.map
> > file which the network administrator creates which indicates the nodes
> > to be expected and a discover.topo file which is the expected
> connectivity
> > and produces a new connectivity file (discover.topo.new) and outputs
> > the changes to stdout. The network administrator can choose to replace
> > the "old" topo file with the new one or certai

[openib-general] Re: iSer SVN 4714 does not compile on 2.6.15

[Hal Rosenstock]

Hi Woody,

On Tue, 2006-01-03 at 19:13, Woodruff, Robert J wrote:
>  I tried to compile iSer SVN 4714 against the released 2.6.15 kernel
> and get the following compile errors.
> 
>   CC [M]  drivers/infiniband/ulp/iser/iscsi_iser.o
> drivers/infiniband/ulp/iser/iscsi_iser.c: In function
> `iscsi_iser_conn_set_param':
> drivers/infiniband/ulp/iser/iscsi_iser.c:1437: error:
> `ISCSI_PARAM_RDMAEXTENSIONS' undeclared (first use in this function)
> drivers/infiniband/ulp/iser/iscsi_iser.c:1437: error: (Each undeclared
> identifier is reported only once
> drivers/infiniband/ulp/iser/iscsi_iser.c:1437: error: for each function
> it appears in.)
> drivers/infiniband/ulp/iser/iscsi_iser.c: In function
> `iscsi_iser_conn_get_param':
> drivers/infiniband/ulp/iser/iscsi_iser.c:1497: error:
> `ISCSI_PARAM_RDMAEXTENSIONS' undeclared (first use in this function)
> drivers/infiniband/ulp/iser/iscsi_iser.c: At top level:
> drivers/infiniband/ulp/iser/iscsi_iser.c:1635: error: unknown field `af'
> specified in initializer
> drivers/infiniband/ulp/iser/iscsi_iser.c:1635: warning: initialization
> makes pointer from integer without a cast
> drivers/infiniband/ulp/iser/iscsi_iser.c:1636: error: unknown field
> `rdma' specified in initializer
> make[3]: *** [drivers/infiniband/ulp/iser/iscsi_iser.o] Error 1

Did you apply linux-2.6.15-rc7-iscsi_iser.diff ? Please read the iser
wiki page.

-- 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

[openib-general] iSer SVN 4714 does not compile on 2.6.15

[Woodruff, Robert J]

 
I tried to compile iSer SVN 4714 against the released 2.6.15 kernel
and get the following compile errors.

  CC [M]  drivers/infiniband/ulp/iser/iscsi_iser.o
drivers/infiniband/ulp/iser/iscsi_iser.c: In function
`iscsi_iser_conn_set_param':
drivers/infiniband/ulp/iser/iscsi_iser.c:1437: error:
`ISCSI_PARAM_RDMAEXTENSIONS' undeclared (first use in this function)
drivers/infiniband/ulp/iser/iscsi_iser.c:1437: error: (Each undeclared
identifier is reported only once
drivers/infiniband/ulp/iser/iscsi_iser.c:1437: error: for each function
it appears in.)
drivers/infiniband/ulp/iser/iscsi_iser.c: In function
`iscsi_iser_conn_get_param':
drivers/infiniband/ulp/iser/iscsi_iser.c:1497: error:
`ISCSI_PARAM_RDMAEXTENSIONS' undeclared (first use in this function)
drivers/infiniband/ulp/iser/iscsi_iser.c: At top level:
drivers/infiniband/ulp/iser/iscsi_iser.c:1635: error: unknown field `af'
specified in initializer
drivers/infiniband/ulp/iser/iscsi_iser.c:1635: warning: initialization
makes pointer from integer without a cast
drivers/infiniband/ulp/iser/iscsi_iser.c:1636: error: unknown field
`rdma' specified in initializer
make[3]: *** [drivers/infiniband/ulp/iser/iscsi_iser.o] Error 1

___
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] uDAPL disconnect events

[Arlin Davis]

Jimmy Hill wrote:

I'm running with the latest OpenIB Gen2 uDAPL code (CMA version) and 
have encountered a problem with disconnect events. The basic problem 
is that both sides have to call dat_ep_disconnect in order to break 
down a connection cleanly. It should be possible for just one side 
(i.e., client) to call disconnect and the other side wait for and see 
the disconnect event. That does not appear to be working. It does 
however work that way in the old reference implementation (as it 
should). I have code that depends on that functionality and as a 
result, can not move it to OpenIB Gen2 uDAPL yet. Is this a known problem?


Yes, this is a problem. The uDAPL event should be processed from the 
uCMA event callback. I will work on a fix.




Changing the flag to DAT_CLOSE_GRACEFUL_FLAG does not change the 
behavior.  The attached copy of dtest.c is still using the default 
flag value.


I have attached a modified version of the "dtest" test program which 
demonstrates the problem. The "client" will disconnect and exit 
cleanly. The "server" will hang waiting for the disconnect event.


thanks,
jimmy

Jimmy Hill
[EMAIL PROTECTED] 
[EMAIL PROTECTED] 



___
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 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][PATCH] OpenIB uDAPL extension proposal - sample immed data and atomic api's

[Arlin Davis]

James Lentini wrote:


On Fri, 23 Dec 2005, Arlin Davis wrote:

arlin>
arlin> A single entry point is still there with this patch, I just 
arlin> defined it a little different with a function definition for 
arlin> better DAT API mappings. The idea was to replace the existing 
arlin> pvoid extension definition with this new one. Can you give me 
arlin> an idea of how you would map these extended DAT calls to this 
arlin> pvoid function definition?


For uDAPL, the DAT_PROVIDER structure is defined as follows:

struct dat_provider
{
   const char *device_name;
   DAT_PVOID   extension;
   ...

You could create a well known extensions API by defining a structure 
with several function pointers


struct dat_atomic_extensions
{
   DAT_RETURN (*cmp_and_swap_func)(IN DAT_EP_HANDLE ep_handle,
   IN DAT_UINT64 cmp_value,
   IN DAT_UINT64 swap_value, 
   IN DAT_LMR_TRIPLE *local_iov, 
   IN DAT_DTO_COOKIE user_cookie, 
   IN DAT_RMR_TRIPLE *remote_iov, 
   IN DAT_COMPLETION_FLAGS completion_flags);

   ...
}

and require the dat_provider's extensions member to point to your new 
extension struct.


To make the API easier to use, you could also create macros, similar 
to the standard DAT macros, to reach inside an objects provider 
structure and call the correct extension function.


#define dat_ep_post_cmp_and_swap(ep, cmp, swap, local_iov, cookie, 
remote_iov, flags) \

   (*DAT_HANDLE_TO_EXTENSION (ep)->cmp_and_swap_func) (\
   (ep),   \
   (cmp),  \
   (swap), \
   (local_iov),\
   (cookie),   \
   (remote_iov),   \
   (flags))

A drawback to this approach is that adding new extensions requires 
synchronizing with the original extension specification document. To 
eliminate that issue, you could require that the dat_provider's 
extension member point to a typed list of these sorts of extension 
structures.
 

The other drawback is that the consumer calls directly into a table with 
no validation of provider extensions nor handles. The method I am 
proposing uses the existing dat_api layer for handle validation, a 
provider extension validation during the open, and provider extension 
operation validation with the extension operation parameter in the new 
DAT_EXTENSION_FUNC typedef.




___
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: [PATCH] [ib_addr] generalize address to RDMA device translation

[Caitlin Bestler]

[EMAIL PROTECTED] wrote:
> On Tue, 2006-01-03 at 12:05 -0800, Sean Hefty wrote:
>> Tom Tucker wrote:
>>> ARP Resolve
>>> 
>>> The iWARP side needs to be able to resolve an IP address to an
>>> Ethernet address. Today this is not done for iWARP and it works
>>> because the AMSO1100 does this itself in the hardware. Other iWARP
>>> devices probably don't. This means that the logic in ib_at needs to
>>> be extended on the iWARP side to call neigh_event_send (instead of
>>> arp_send) to resolve an IP to an Ethernet address.  The current
>>> method of calling arp_send directly and "sniffing" for arp replies
>>> is probably not the best way to go long term. It would be better to
>>> register for neighbor update events (new mechanism) and
> be notified when the neighbor entry gets resolved.
>>> This is better for two reasons: 1) it doesn't duplicate code already
>>> in Linux, and 2) unlike IB, Ethernet MAC addresses may change for
>>> the next hop while the connection is still active. The provider
>>> needs to know this so it's hardware ARP tables can be updated.
>> 
>> To be clear, the CMA uses ib_addr, and not ib_at, which is a
>> different module. 
> 
> Absolutely. I was dumping a bunch of loosely related concerns...
> 
>> 
>> I'm not sure I understand what's wrong with sniffing arp replies.
>> There's very little code (about a dozen lines) in ib_addr to handle
>> arps.  It also seems that it's just as unlikely that the mapping from
>> an IP address to a hardware address will change for Ethernet as it
>> does for IB. 
> 
> Agreed -- It is unlikely. The more common case is a re-arp
> when the arp entry times out (typically 15 minutes).
> 
> 

It is unlikely, but it is also crucial. IP failover within a subnet
is dependent on arp updates.

Manual entering new ARP translations is even rarer (I think I've done
it about six times in nearly 20 years of working with IP networks),
but it is legal. And it is something that IP network administrators
can do now, and they do not expect RDMA to break it.


>> Are you trying to deal with a destination IP address of a connection
>> that is not on the local subnet?  If this is the case, then this
>> seems like a separate issue than address resolution.
> 
> Yes, and no. The IP address being resolved is the peer if it
> is on the same subnet. If it is not, then the IP address
> being resolved is for the next hop.
> 
>> 
>>> ROUTE Changes
>>> 
>>> Two obvious cases, 1) the next hop changes due to normal network
>>> least- cost routing, and 2) the user changes a route manually. Both
>>> events would require the iWARP provider to be notified (via an event
>>> again) and update its hardware
>> 
>> Maybe this can be included as part of some sort of automatic
>> "failover"? Otherwise, I'm not sure how this functionality maps to
>> IB. It's not a big deal if it doesn't, but it'd be nice to keep
>> similarities where possible. 

The key point is that the IP layer implemented by the RNIC has
to be working from the same data as the IP layer implemented by
Linux. Since Linux does not implement the IB transport layer 
the same issue is not likely to come up.

In an IP network, changing routes is supposed to be transparent
to established connections, especially if there is no PMTU decrease.
So trying to map it to IB APM won't be a fit.

> 
>>> PathMTU
>>> 
>>> The new route to the remote peer has a hop with a smaller MTU than
>>> we're currently using. Ouch! All my packets are going to be dropped
>>> until I reduce my path MTU. The provider can't know unless he is
>>> either filtering all ICMP traffic himself ("evil") or is notified
>>> via an event ("nice"). 
>>> 
>>> So all this said, my little brain had imagined this logic going in
>>> and around the ib_at module in a wonderfully crafted bit of
>>> algorithmic art -- once I figured out how to do it all ;-)
>>> 
>>> It sounds like you're beating the same bushes. How would you like to
>>> proceed?
>> 
>> I'd like to define a set of changes to ib_addr and the rdma_cm that
>> makes it easier to support multiple RDMA devices, then
> evolve the codebase from there.
>> My hope is to keep the network addressing ugliness in ib_addr.
>> 
>> The changes to the ib_addr interface is based on trying to determine
>> what might help support iWarp after looking at your patch.  If the
>> changes appear to be a step in the right direction, then I will
>> commit them.  The essence of the change is that ib_addr leaves the
>> interpretation of the addresses up to the caller, which may still be
>> a good thing even if it doesn't directly make supporting iWarp any
>> easier. 
> 
> My 2 cents is that it's a good thing. Sorry to throw 10 lbs
> of @#^$ in with this bag... I was core dumping.
> 

I agree with Tom's assessment here. Leaving the interpretation of
the rdma_addr up to the rdma transport device is a necessary
and solid first step, but it should be understood that there
are some related issues that will also have to be addressed.
A major part of the sema

Re: [openib-general] Re: [PATCH] fix race in mad.c

[Sean Hefty]

Michael S. Tsirkin wrote:

We also need a way to make sure that ib_mad_thread_completion_handler is
not currently running.


Why wouldn't this work?

lock - check state - queue work - unlock

It shouldn't matter if ib_mad_thread_completion_handler() is running or not.

- 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] Re: [PATCH] fix race in mad.c

[Michael S. Tsirkin]

Quoting r. Sean Hefty <[EMAIL PROTECTED]>:
> Subject: Re: [openib-general] Re: [PATCH] fix race in mad.c
> 
> Michael S. Tsirkin wrote:
> >>There should be some way to fix this that doesn't involve walking a list on
> >>every completion.  Can't the cleanup be changed?  Either move destroying 
> >>the QP
> >>after the workqueue flush or transition it to the error state before 
> >>flushing.
> > 
> > What about resurrecting my idea to have ib_cq_sync()?
> > Then we could just set a flag to suppress queueing more work.
> 
> I don't remember the details of ib_cq_sync() off the top of my head.
> 
> I think that we need to add a state to struct ib_mad_port_private that can be 
> checked in ib_mad_thread_completion_handler().  I don't think that a new call 
> is 
> needed though.
> 
> - Sean
> 

We also need a way to make sure that ib_mad_thread_completion_handler is
not currently running.

Thats what the proposed ib_cq_sync could do.

-- 
MST
___
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 0 of 20] [RFC] ipath - PathScale InfiniPath driver

[Arjan van de Ven]

On Tue, 2006-01-03 at 12:54 -0800, Bryan O'Sullivan wrote:
> On Tue, 2006-01-03 at 09:27 -0800, Greg KH wrote:
> 
> > Idealy, nothing should be new ioctls.  But in the end, it all depends on
> > exactly what you are trying to do with each different one.
> 
> Fair enough.
> 
> > I really don't know what the subnet management stuff involves, sorry.
> > But doesn't the open-ib layer handle that all for you already?
> 
> It does when our OpenIB driver is being used.  But our lower level
> driver is independent of OpenIB (and is often used without the
> infiniband stuff even configured into the kernel), and needs to provide
> some way for a userspace subnet management agent to send and receive
> packets.

that sounds like your driver should mimic the openIB userspace ABI for
this *exactly* so that you can use the same management tools for either
scenario...


___
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 0 of 20] [RFC] ipath - PathScale InfiniPath driver

[Bryan O'Sullivan]

On Tue, 2006-01-03 at 09:27 -0800, Greg KH wrote:

> Idealy, nothing should be new ioctls.  But in the end, it all depends on
> exactly what you are trying to do with each different one.

Fair enough.

> I really don't know what the subnet management stuff involves, sorry.
> But doesn't the open-ib layer handle that all for you already?

It does when our OpenIB driver is being used.  But our lower level
driver is independent of OpenIB (and is often used without the
infiniband stuff even configured into the kernel), and needs to provide
some way for a userspace subnet management agent to send and receive
packets.

http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

[openib-general] RE: [PATCH] [TRIVIAL] OpenSM: Separate out OSM_VERSION

[Eitan Zahavi]

Hal
> Yes, but I'm not sure what you are proposing here.

[EZ] Troy gave us the answer. What I now propose is to use:
svnversion .
(at the osm dir)
___
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: [PATCH] fix race in mad.c

[Sean Hefty]

Michael S. Tsirkin wrote:

There should be some way to fix this that doesn't involve walking a list on
every completion.  Can't the cleanup be changed?  Either move destroying the QP
after the workqueue flush or transition it to the error state before flushing.


What about resurrecting my idea to have ib_cq_sync()?
Then we could just set a flag to suppress queueing more work.


I don't remember the details of ib_cq_sync() off the top of my head.

I think that we need to add a state to struct ib_mad_port_private that can be 
checked in ib_mad_thread_completion_handler().  I don't think that a new call is 
needed though.


- 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] RE: [PATCH] [ib_addr] generalize address to RDMA device translation

[Steve Wise]

On Tue, 2006-01-03 at 12:25 -0800, Sean Hefty wrote:
> Caitlin Bestler wrote:
> > Sniffing is a workaround. Subscription is the correct
> > solution here for long term stability.
> > 
> > Subscription is also the only solution that will correctly
> > respond when the system administrator has manually loaded
> > an ARP entry.
> > 
> > This also applies to Routing and ICMP.
> 
> To clarify, ib_addr does not actually "sniff" ARPs.  It simply uses them to 
> schedule its workqueue thread to check for updates.  Manually loaded ARP 
> entries 
> would the same as any previously loaded entries.  If there is a subscription 
> based mechanism that can be used as well or instead, it should be 
> straightforward to update ib_addr.  I am just not familiar enough with the 
> Linux 
> network stack to know if such a mechanism exists.

There is a subscription service that is used for notification of netdev
events.  It uses the base notifier_block services (see
include/linux/notifier.h and net/core/dev.c).  

Our thoughts were to enhance this to allow notifications of neighbour,
route, and pmtu events as well.


Steve.

___
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] fix race in mad.c

[Michael S. Tsirkin]

Quoting r. Sean Hefty <[EMAIL PROTECTED]>:
> There should be some way to fix this that doesn't involve walking a list on
> every completion.  Can't the cleanup be changed?  Either move destroying the 
> QP
> after the workqueue flush or transition it to the error state before flushing.
> 
> - Sean
> 

What about resurrecting my idea to have ib_cq_sync()?
Then we could just set a flag to suppress queueing more work.

-- 
MST
___
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: [PATCH] [ib_addr] generalize address to RDMA device translation

[Sean Hefty]

Caitlin Bestler wrote:

Sniffing is a workaround. Subscription is the correct
solution here for long term stability.

Subscription is also the only solution that will correctly
respond when the system administrator has manually loaded
an ARP entry.

This also applies to Routing and ICMP.


To clarify, ib_addr does not actually "sniff" ARPs.  It simply uses them to 
schedule its workqueue thread to check for updates.  Manually loaded ARP entries 
would the same as any previously loaded entries.  If there is a subscription 
based mechanism that can be used as well or instead, it should be 
straightforward to update ib_addr.  I am just not familiar enough with the Linux 
network stack to know if such a mechanism exists.


- 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] Re: [PATCH] [ib_addr] generalize address to RDMA device translation

[Tom Tucker]

On Tue, 2006-01-03 at 12:05 -0800, Sean Hefty wrote:
> Tom Tucker wrote:
> > ARP Resolve
> > 
> > The iWARP side needs to be able to resolve an IP address to an Ethernet
> > address. Today this is not done for iWARP and it works because the
> > AMSO1100 does this itself in the hardware. Other iWARP devices probably
> > don't. This means that the logic in ib_at needs to be extended on the
> > iWARP side to call neigh_event_send (instead of arp_send) to resolve an
> > IP to an Ethernet address.  The current method of calling arp_send
> > directly and "sniffing" for arp replies is probably not the best way to
> > go long term. It would be better to register for neighbor update events
> > (new mechanism) and be notified when the neighbor entry gets resolved.
> > This is better for two reasons: 1) it doesn't duplicate code already in
> > Linux, and 2) unlike IB, Ethernet MAC addresses may change for the next
> > hop while the connection is still active. The provider needs to know
> > this so it's hardware ARP tables can be updated.
> 
> To be clear, the CMA uses ib_addr, and not ib_at, which is a different module.

Absolutely. I was dumping a bunch of loosely related concerns...

> 
> I'm not sure I understand what's wrong with sniffing arp replies.  There's 
> very 
> little code (about a dozen lines) in ib_addr to handle arps.  It also seems 
> that 
> it's just as unlikely that the mapping from an IP address to a hardware 
> address 
> will change for Ethernet as it does for IB.

Agreed -- It is unlikely. The more common case is a re-arp when the arp
entry times out (typically 15 minutes).


> Are you trying to deal with a destination IP address of a connection that is 
> not 
> on the local subnet?  If this is the case, then this seems like a separate 
> issue 
> than address resolution.

Yes, and no. The IP address being resolved is the peer if it is on the
same subnet. If it is not, then the IP address being resolved is for the
next hop.

> 
> > ROUTE Changes
> > 
> > Two obvious cases, 1) the next hop changes due to normal network least-
> > cost routing, and 2) the user changes a route manually. Both events
> > would require the iWARP provider to be notified (via an event again) and
> > update its hardware
> 
> Maybe this can be included as part of some sort of automatic "failover"? 
> Otherwise, I'm not sure how this functionality maps to IB.  It's not a big 
> deal 
> if it doesn't, but it'd be nice to keep similarities where possible.

> > PathMTU
> > 
> > The new route to the remote peer has a hop with a smaller MTU than we're
> > currently using. Ouch! All my packets are going to be dropped until I
> > reduce my path MTU. The provider can't know unless he is either
> > filtering all ICMP traffic himself ("evil") or is notified via an event
> > ("nice"). 
> > 
> > So all this said, my little brain had imagined this logic going in and
> > around the ib_at module in a wonderfully crafted bit of algorithmic art
> > -- once I figured out how to do it all ;-)
> > 
> > It sounds like you're beating the same bushes. How would you like to
> > proceed?
> 
> I'd like to define a set of changes to ib_addr and the rdma_cm that makes it 
> easier to support multiple RDMA devices, then evolve the codebase from there. 
> My hope is to keep the network addressing ugliness in ib_addr.
> 
> The changes to the ib_addr interface is based on trying to determine what 
> might 
> help support iWarp after looking at your patch.  If the changes appear to be 
> a 
> step in the right direction, then I will commit them.  The essence of the 
> change 
> is that ib_addr leaves the interpretation of the addresses up to the caller, 
> which may still be a good thing even if it doesn't directly make supporting 
> iWarp any easier.

My 2 cents is that it's a good thing. Sorry to throw 10 lbs of @#^$ in
with this bag... I was core dumping.

> 
> - 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] Re: [PATCH] [ib_addr] generalize address to RDMA device translation

[Sean Hefty]

Tom Tucker wrote:

ARP Resolve

The iWARP side needs to be able to resolve an IP address to an Ethernet
address. Today this is not done for iWARP and it works because the
AMSO1100 does this itself in the hardware. Other iWARP devices probably
don't. This means that the logic in ib_at needs to be extended on the
iWARP side to call neigh_event_send (instead of arp_send) to resolve an
IP to an Ethernet address.  The current method of calling arp_send
directly and "sniffing" for arp replies is probably not the best way to
go long term. It would be better to register for neighbor update events
(new mechanism) and be notified when the neighbor entry gets resolved.
This is better for two reasons: 1) it doesn't duplicate code already in
Linux, and 2) unlike IB, Ethernet MAC addresses may change for the next
hop while the connection is still active. The provider needs to know
this so it's hardware ARP tables can be updated.


To be clear, the CMA uses ib_addr, and not ib_at, which is a different module.

I'm not sure I understand what's wrong with sniffing arp replies.  There's very 
little code (about a dozen lines) in ib_addr to handle arps.  It also seems that 
it's just as unlikely that the mapping from an IP address to a hardware address 
will change for Ethernet as it does for IB.


Are you trying to deal with a destination IP address of a connection that is not 
on the local subnet?  If this is the case, then this seems like a separate issue 
than address resolution.



ROUTE Changes

Two obvious cases, 1) the next hop changes due to normal network least-
cost routing, and 2) the user changes a route manually. Both events
would require the iWARP provider to be notified (via an event again) and
update its hardware


Maybe this can be included as part of some sort of automatic "failover"? 
Otherwise, I'm not sure how this functionality maps to IB.  It's not a big deal 
if it doesn't, but it'd be nice to keep similarities where possible.



PathMTU

The new route to the remote peer has a hop with a smaller MTU than we're
currently using. Ouch! All my packets are going to be dropped until I
reduce my path MTU. The provider can't know unless he is either
filtering all ICMP traffic himself ("evil") or is notified via an event
("nice"). 


So all this said, my little brain had imagined this logic going in and
around the ib_at module in a wonderfully crafted bit of algorithmic art
-- once I figured out how to do it all ;-)

It sounds like you're beating the same bushes. How would you like to
proceed?


I'd like to define a set of changes to ib_addr and the rdma_cm that makes it 
easier to support multiple RDMA devices, then evolve the codebase from there. 
My hope is to keep the network addressing ugliness in ib_addr.


The changes to the ib_addr interface is based on trying to determine what might 
help support iWarp after looking at your patch.  If the changes appear to be a 
step in the right direction, then I will commit them.  The essence of the change 
is that ib_addr leaves the interpretation of the addresses up to the caller, 
which may still be a good thing even if it doesn't directly make supporting 
iWarp any easier.


- 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] RE: [PATCH] [TRIVIAL] OpenSM: Separate out OSM_VERSION

[Troy Benjegerdes]

On Tue, Jan 03, 2006 at 11:01:43AM -0500, Hal Rosenstock wrote:
> On Tue, 2006-01-03 at 10:43, Eitan Zahavi wrote:
> > Hi Hal,
> > 
> > Sounds good.
> > I think you should be able to use the .svn/entries to get the last
> > update revision and then use svn diff (or diff) to see if local mods are
> > done on top of it...
> 
> I'm using .svn/entries at the osm level.
> 
> > So we do not get caught by surprise when something broke due to
> > un-committed mod in the local directory
> > Thanks

The 'svnversion' command gives you the version, and then checks for
local mods. No need to reinvent how to do that.
___
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] [ib_addr] generalize address to RDMA device translation

[Caitlin Bestler]

Tom Tucker wrote:
> Sean:
> 
> This is a good start towards generalizing the IP address translation
> service. 
> 
> I think there is quite a bit of "hair" in this area that is
> "Part 2" of the iWARP integration -- after the integration of
> the current stuff into the trunk. I was going to introduce
> some of this "hair" at the face to face in Sonoma, but we
> should probably get it going now.
> 
> There are three areas that need attention:
> - ARP resolution
> - ROUTE changes
> - Path MTU changes
> 
> ARP Resolve
> 
> The iWARP side needs to be able to resolve an IP address to
> an Ethernet address. Today this is not done for iWARP and it
> works because the AMSO1100 does this itself in the hardware.
> Other iWARP devices probably don't. This means that the logic
> in ib_at needs to be extended on the iWARP side to call
> neigh_event_send (instead of arp_send) to resolve an IP to an
> Ethernet address.  The current method of calling arp_send
> directly and "sniffing" for arp replies is probably not the
> best way to go long term. It would be better to register for
> neighbor update events (new mechanism) and be notified when
> the neighbor entry gets resolved.
> This is better for two reasons: 1) it doesn't duplicate code
> already in Linux, and 2) unlike IB, Ethernet MAC addresses
> may change for the next hop while the connection is still
> active. The provider needs to know this so it's hardware ARP tables
> can be updated. 
> 

Agreed, an iWARP NIC *might* need to receive these notices,
so subscribing is an excellent approach.

Typically the iWARP RNIC is also a plain Ethernet NIC,
where ARP,etc. are being handled by the network stack.
It is a major problem if the RNIC and NIC are out of
sync on an L3 issue (like what the MAC address of a
local peer is, or what the next hop to reach a given
IP address is).

Sniffing is a workaround. Subscription is the correct
solution here for long term stability.

Subscription is also the only solution that will correctly
respond when the system administrator has manually loaded
an ARP entry.

This also applies to Routing and ICMP.



___
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] [ib_addr] generalize address to RDMA device translation

[Tom Tucker]

Sean:

This is a good start towards generalizing the IP address translation
service. 

I think there is quite a bit of "hair" in this area that is "Part 2" of
the iWARP integration -- after the integration of the current stuff into
the trunk. I was going to introduce some of this "hair" at the face to
face in Sonoma, but we should probably get it going now. 

There are three areas that need attention:
- ARP resolution 
- ROUTE changes
- Path MTU changes

ARP Resolve

The iWARP side needs to be able to resolve an IP address to an Ethernet
address. Today this is not done for iWARP and it works because the
AMSO1100 does this itself in the hardware. Other iWARP devices probably
don't. This means that the logic in ib_at needs to be extended on the
iWARP side to call neigh_event_send (instead of arp_send) to resolve an
IP to an Ethernet address.  The current method of calling arp_send
directly and "sniffing" for arp replies is probably not the best way to
go long term. It would be better to register for neighbor update events
(new mechanism) and be notified when the neighbor entry gets resolved.
This is better for two reasons: 1) it doesn't duplicate code already in
Linux, and 2) unlike IB, Ethernet MAC addresses may change for the next
hop while the connection is still active. The provider needs to know
this so it's hardware ARP tables can be updated.

ROUTE Changes

Two obvious cases, 1) the next hop changes due to normal network least-
cost routing, and 2) the user changes a route manually. Both events
would require the iWARP provider to be notified (via an event again) and
update its hardware

PathMTU

The new route to the remote peer has a hop with a smaller MTU than we're
currently using. Ouch! All my packets are going to be dropped until I
reduce my path MTU. The provider can't know unless he is either
filtering all ICMP traffic himself ("evil") or is notified via an event
("nice"). 

So all this said, my little brain had imagined this logic going in and
around the ib_at module in a wonderfully crafted bit of algorithmic art
-- once I figured out how to do it all ;-)

It sounds like you're beating the same bushes. How would you like to
proceed?

Tom

On Tue, 2006-01-03 at 10:13 -0800, Sean Hefty wrote:
> The following patch changes the ib_addr interface to make it more generic.
> The interface now translates IP addresses directly into source and destination
> device and broadcast addresses.  The CMA is then responsible for interpreting
> these addresses as GIDs/PKey or MAC addresses.  The intent is that this will
> simplify integrating support for other RDMA devices in the CMA.
> 
> I'd like to get some feedback from the iWarp community on whether this 
> approach
> works for them, or if different/additional changes are needed.
> 
> Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
> 
> 
> Index: include/rdma/rdma_cm.h
> ===
> --- include/rdma/rdma_cm.h(revision 4651)
> +++ include/rdma/rdma_cm.h(working copy)
> @@ -68,9 +68,7 @@ struct rdma_addr {
>   struct sockaddr dst_addr;
>   u8  dst_pad[sizeof(struct sockaddr_in6) -
>   sizeof(struct sockaddr)];
> - union {
> - struct ib_addr  ibaddr;
> - } addr;
> + struct rdma_dev_addr dev_addr;
>  };
>  
>  struct rdma_route {
> Index: include/rdma/ib_addr.h
> ===
> --- include/rdma/ib_addr.h(revision 4654)
> +++ include/rdma/ib_addr.h(working copy)
> @@ -32,26 +32,28 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
>  extern struct workqueue_struct *rdma_wq;
>  
> -struct ib_addr {
> - union ib_gidsgid;
> - union ib_giddgid;
> - u16 pkey;
> +struct rdma_dev_addr {
> + unsigned char src_dev_addr[MAX_ADDR_LEN];
> + unsigned char dst_dev_addr[MAX_ADDR_LEN];
> + unsigned char broadcast[MAX_ADDR_LEN];
> + enum ib_node_type dev_type;
>  };
>  
>  /**
> - * ib_translate_addr - Translate a local IP address to an Infiniband GID and
> - *   PKey.
> + * rdma_translate_ip - Translate a local IP address to an RDMA hardware
> + *   address.
>   */
> -int ib_translate_addr(struct sockaddr *addr, union ib_gid *gid, u16 *pkey);
> +int rdma_translate_ip(struct sockaddr *addr, struct rdma_dev_addr *dev_addr);
>  
>  /**
> - * ib_resolve_addr - Resolve source and destination IP addresses to
> - *   Infiniband network addresses.
> + * rdma_resolve_ip - Resolve source and destination IP addresses to
> + *   RDMA hardware addresses.
>   * @src_addr: An optional source address to use in the resolution.  If a
>   *   source address is not provided, a usable address will be returned via
>   *   the callback.
> @@ -64,13 +66,13 @@ int ib_translate_addr(struct sockaddr *a
>   *   or been canceled.  A status of 0 indicates success.
>   * @context: User-specified context associated with the call.
>   */
> -in

RE: [openib-general] [PATCH] [ib_addr] generalize address to RDMA device translation

[Caitlin Bestler]

[EMAIL PROTECTED] wrote:
> The following patch changes the ib_addr interface to make it
> more generic.
> The interface now translates IP addresses directly into
> source and destination device and broadcast addresses.  The
> CMA is then responsible for interpreting these addresses as
> GIDs/PKey or MAC addresses.  The intent is that this will
> simplify integrating support for other RDMA devices in the CMA.
> 

My understanding of these is that they should all translate
pretty much to nops for IP networks. But I'd like to review
that, and have defintions that make that clear.

There are times where fetching lower, say to fetch an
Ethernet MAC address of a VLAN ID, could violate layering
in an iWARP implmenetaiton and might have actual performance
hits to fetch data that was not naturally available to the
RDMA layer.

More in-line.

> I'd like to get some feedback from the iWarp community on
> whether this approach works for them, or if
> different/additional changes are needed.
> 
> Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
> 
> 
> Index: include/rdma/rdma_cm.h
> ===
> --- include/rdma/rdma_cm.h(revision 4651)
> +++ include/rdma/rdma_cm.h(working copy)
> @@ -68,9 +68,7 @@ struct rdma_addr {
>   struct sockaddr dst_addr;
>   u8  dst_pad[sizeof(struct sockaddr_in6) -
>   sizeof(struct sockaddr)];
> - union {
> - struct ib_addr  ibaddr;
> - } addr;
> + struct rdma_dev_addr dev_addr;
>  };
>

"dev_addr" is any clarifying/lower layer address that matches
the sockaddr *and is required by the RDMA layer*.

If the rdma layer does not require this data the contents
may be logically void. This interface MUST NOT be used to
query for a deterministic lower layer address.

Rationale: if the RDMA layer is cleanly layered over IP
then the MAC layer address is not accessible to it without
doing additional queries. It is not a natural by-product
and should not be automatically fetched, at extra cost,
when most applications do not care.

 
>  struct rdma_route {
> Index: include/rdma/ib_addr.h
> ===
> --- include/rdma/ib_addr.h(revision 4654)
> +++ include/rdma/ib_addr.h(working copy)
> @@ -32,26 +32,28 @@
> 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> 
>  extern struct workqueue_struct *rdma_wq;
> 
> -struct ib_addr {
> - union ib_gidsgid;
> - union ib_giddgid;
> - u16 pkey;
> +struct rdma_dev_addr {
> + unsigned char src_dev_addr[MAX_ADDR_LEN];
> + unsigned char dst_dev_addr[MAX_ADDR_LEN];
> + unsigned char broadcast[MAX_ADDR_LEN];
> + enum ib_node_type dev_type;
>  };
> 
>  /**
> - * ib_translate_addr - Translate a local IP address to an
> Infiniband GID and
> - *   PKey.
> + * rdma_translate_ip - Translate a local IP address to an
> RDMA hardware
> + *   address.
>   */
> -int ib_translate_addr(struct sockaddr *addr, union ib_gid *gid, u16
> *pkey); +int rdma_translate_ip(struct sockaddr *addr, struct
> rdma_dev_addr +*dev_addr); 
> 
>  /**
> - * ib_resolve_addr - Resolve source and destination IP addresses to
> - *   Infiniband network addresses.
> + * rdma_resolve_ip - Resolve source and destination IP addresses to
> + *   RDMA hardware addresses.
>   * @src_addr: An optional source address to use in the
> resolution.  If a
>   *   source address is not provided, a usable address will
> be returned via
>   *   the callback.
> @@ -64,13 +66,13 @@ int ib_translate_addr(struct sockaddr *a
>   *   or been canceled.  A status of 0 indicates success.
>   * @context: User-specified context associated with the call.   */
> -int ib_resolve_addr(struct sockaddr *src_addr, struct
> sockaddr *dst_addr,
> - struct ib_addr *addr, int timeout_ms,
> +int rdma_resolve_ip(struct sockaddr *src_addr, struct
> sockaddr *dst_addr,
> + struct rdma_dev_addr *addr, int timeout_ms,
>   void (*callback)(int status, struct
> sockaddr *src_addr,
> -  struct ib_addr *addr, void
> *context),
> +  struct rdma_dev_addr
> *addr, void *context),
>   void *context);
> 
> -void ib_addr_cancel(struct ib_addr *addr);
> +void rdma_addr_cancel(struct rdma_dev_addr *addr);
> 
>  static inline int ip_addr_size(struct sockaddr *addr)  { @@
> -78,5 +80,38 @@ static inline int ip_addr_size(struct so
>  sizeof(struct sockaddr_in6) : sizeof(struct
> sockaddr_in);  }
> 
> +static inline u16 ib_addr_get_pkey(struct rdma_dev_addr *dev_addr) {
> + return ((u16)dev_addr->broadcast[8] << 8) |
> +(u16)dev_addr->broadcast[9]; }
> +
> +static inline void ib_addr_set_pkey(struct rdma_dev_addr *dev_addr,
> u16 +pkey) {
> + dev_addr->broadcast[8] = pkey >> 8;
> + dev_addr->broadcast[9] = (unsigned char) pkey; }
> +

The closest IP equivalent

[openib-general] [PATCH] [ib_addr] generalize address to RDMA device translation

[Sean Hefty]

The following patch changes the ib_addr interface to make it more generic.
The interface now translates IP addresses directly into source and destination
device and broadcast addresses.  The CMA is then responsible for interpreting
these addresses as GIDs/PKey or MAC addresses.  The intent is that this will
simplify integrating support for other RDMA devices in the CMA.

I'd like to get some feedback from the iWarp community on whether this approach
works for them, or if different/additional changes are needed.

Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>


Index: include/rdma/rdma_cm.h
===
--- include/rdma/rdma_cm.h  (revision 4651)
+++ include/rdma/rdma_cm.h  (working copy)
@@ -68,9 +68,7 @@ struct rdma_addr {
struct sockaddr dst_addr;
u8  dst_pad[sizeof(struct sockaddr_in6) -
sizeof(struct sockaddr)];
-   union {
-   struct ib_addr  ibaddr;
-   } addr;
+   struct rdma_dev_addr dev_addr;
 };
 
 struct rdma_route {
Index: include/rdma/ib_addr.h
===
--- include/rdma/ib_addr.h  (revision 4654)
+++ include/rdma/ib_addr.h  (working copy)
@@ -32,26 +32,28 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
 extern struct workqueue_struct *rdma_wq;
 
-struct ib_addr {
-   union ib_gidsgid;
-   union ib_giddgid;
-   u16 pkey;
+struct rdma_dev_addr {
+   unsigned char src_dev_addr[MAX_ADDR_LEN];
+   unsigned char dst_dev_addr[MAX_ADDR_LEN];
+   unsigned char broadcast[MAX_ADDR_LEN];
+   enum ib_node_type dev_type;
 };
 
 /**
- * ib_translate_addr - Translate a local IP address to an Infiniband GID and
- *   PKey.
+ * rdma_translate_ip - Translate a local IP address to an RDMA hardware
+ *   address.
  */
-int ib_translate_addr(struct sockaddr *addr, union ib_gid *gid, u16 *pkey);
+int rdma_translate_ip(struct sockaddr *addr, struct rdma_dev_addr *dev_addr);
 
 /**
- * ib_resolve_addr - Resolve source and destination IP addresses to
- *   Infiniband network addresses.
+ * rdma_resolve_ip - Resolve source and destination IP addresses to
+ *   RDMA hardware addresses.
  * @src_addr: An optional source address to use in the resolution.  If a
  *   source address is not provided, a usable address will be returned via
  *   the callback.
@@ -64,13 +66,13 @@ int ib_translate_addr(struct sockaddr *a
  *   or been canceled.  A status of 0 indicates success.
  * @context: User-specified context associated with the call.
  */
-int ib_resolve_addr(struct sockaddr *src_addr, struct sockaddr *dst_addr,
-   struct ib_addr *addr, int timeout_ms,
+int rdma_resolve_ip(struct sockaddr *src_addr, struct sockaddr *dst_addr,
+   struct rdma_dev_addr *addr, int timeout_ms,
void (*callback)(int status, struct sockaddr *src_addr,
-struct ib_addr *addr, void *context),
+struct rdma_dev_addr *addr, void *context),
void *context);
 
-void ib_addr_cancel(struct ib_addr *addr);
+void rdma_addr_cancel(struct rdma_dev_addr *addr);
 
 static inline int ip_addr_size(struct sockaddr *addr)
 {
@@ -78,5 +80,38 @@ static inline int ip_addr_size(struct so
   sizeof(struct sockaddr_in6) : sizeof(struct sockaddr_in);
 }
 
+static inline u16 ib_addr_get_pkey(struct rdma_dev_addr *dev_addr)
+{
+   return ((u16)dev_addr->broadcast[8] << 8) | (u16)dev_addr->broadcast[9];
+}
+
+static inline void ib_addr_set_pkey(struct rdma_dev_addr *dev_addr, u16 pkey)
+{
+   dev_addr->broadcast[8] = pkey >> 8;
+   dev_addr->broadcast[9] = (unsigned char) pkey;
+}
+
+static inline union ib_gid* ib_addr_get_sgid(struct rdma_dev_addr *dev_addr)
+{
+   return  (union ib_gid *) (dev_addr->src_dev_addr + 4);
+}
+
+static inline void ib_addr_set_sgid(struct rdma_dev_addr *dev_addr,
+   union ib_gid *gid)
+{
+   memcpy(dev_addr->src_dev_addr + 4, gid, sizeof *gid);
+}
+
+static inline union ib_gid* ib_addr_get_dgid(struct rdma_dev_addr *dev_addr)
+{
+   return  (union ib_gid *) (dev_addr->dst_dev_addr + 4);
+}
+
+static inline void ib_addr_set_dgid(struct rdma_dev_addr *dev_addr,
+   union ib_gid *gid)
+{
+   memcpy(dev_addr->dst_dev_addr + 4, gid, sizeof *gid);
+}
+
 #endif /* IB_ADDR_H */
 
Index: core/addr.c
===
--- core/addr.c (revision 4654)
+++ core/addr.c (working copy)
@@ -42,10 +42,10 @@ struct addr_req {
struct list_head list;
struct sockaddr src_addr;
struct sockaddr dst_addr;
-   struct ib_addr *addr;
+   struct rdma_dev_addr *addr;
void *context;
void (*callback)(int status, struct sockaddr *src_addr,
-struc

Re: [openib-general] [kernel verbs] u64 vs dma_addr_t

[James Lentini]

On Fri, 30 Dec 2005, Caitlin Bestler wrote:

caitlin> On 12/30/05, James Lentini <[EMAIL PROTECTED]> wrote:
caitlin> >
caitlin> >
caitlin> > caitlin> > One more question on this topic.
caitlin> > caitlin> >
caitlin> > caitlin> > Why is the ib_sge's addr a u64 and not a dma_addr_t?
caitlin> > caitlin>
caitlin> > caitlin> Because the hardware may need for it to be a 64 bit
caitlin> > caitlin> IO Address accessible on the system bus. That applies
caitlin> > caitlin> to the whole system bus, no matter how many PCI roots
caitlin> > caitlin> or virtual OSs there are.
caitlin> > caitlin>
caitlin> > caitlin> In particular there could be a guest OS that was
caitlin> > caitlin> running in 32-bit mode, and the RDMA hardware receiving
caitlin> > caitlin> fast path requests will not support different
caitlin> > caitlin> work request formats for each guest OS.
caitlin> >
caitlin> > Let me back up a step and explain the context for this question.
caitlin> >
caitlin> > As you know, our goal is to use the Linux IB verbs as a
caitlin> > hardware/protocol independent RDMA API. I'm reviewing my use of the
caitlin> > API to make sure that it does not make any particular assumptions.
caitlin> >
caitlin> > Roland stated that a scatter/gather list's address value should be a
caitlin> > bus address:
caitlin> >
caitlin> > http://openib.org/pipermail/openib-general/2005-August/009748.html
caitlin> >
caitlin> 
caitlin> That depends on whether it is part of a registered memory space,
caitlin> or being used to specify a new registered memory space (i.e. it is
caitlin> for a memory register operation).

That is not an issue. The memory registration functions 
(ib_reg_phys_mr(), etc.) describe memory regions using a ib_phys_buf 
structure.

caitlin> When *using* an already established memory region, the address
caitlin> is interpreted in the context of that memory region. The size of
caitlin> address within an RDMA managed memory regions is always
caitlin> 64 bits. No matter which transport or what processor. That is
caitlin> extremely unlikely to change (in fact I think the R-Key/L-Key/
caitlin> STag size would increase to 64-bits before the address size
caitlin> itself changed. But I'm expecting that a 96-bit logical address
caitlin> space should be adequate for quite some time).
caitlin> 
caitlin> When creating a memory region the "physical address" is 
caitlin> really a bus address, which on a strictly local basis could 
caitlin> be 32 or 64 bits. If you were trying to generalize that, the 
caitlin> "physical address" is a "RDMA Device accessible address", 
caitlin> which on anything even vaguely PCI-ish is a bus address.
caitlin> 
caitlin> But just as the distinction between "physical address" and 
caitlin> "bus address" would not have been anticipated in the past, 
caitlin> there may be some other distinction that we are not 
caitlin> anticipating yet. So, in that context, the Memory Region 
caitlin> defines the translation from logical addresses with the 
caitlin> context of a Memory Region (most typically a subset of an 
caitlin> existing virtual memory map) to addresses that the RDMA 
caitlin> device can use to access the same memory. Whatever that 
caitlin> distinction is, I'm sure it will be relevant before another 
caitlin> decade goes by.

Are you arguing that an ib_sge addr should be a u64 or a dma_addr_t?
___
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] fix race in mad.c

[Michael S. Tsirkin]

Quoting Sean Hefty <[EMAIL PROTECTED]>:
> There should be some way to fix this that doesn't involve walking a list on
> every completion.  Can't the cleanup be changed?

I guess we could set some kind of flag. Is this better?
And we still have to take a spinlock across the entire operation.

> Either move destroying the QP after the workqueue flush or transition it to
> the error state before flushing.

How would this help? As far as I know neither will flush completion events.
You'd have to destroy the CQ for this.



-- 
MST
___
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] [kernel verbs] u64 vs dma_addr_t

[Caitlin Bestler]

James Lentini wrote:
> On Fri, 30 Dec 2005, Caitlin Bestler wrote:
> 
>> [EMAIL PROTECTED] wrote:
>>> sean> James Lentini wrote:
>>> sean> > Why is the ib_sge's addr a u64 and not a dma_addr_t? sean>
>>> sean> It's the same address that the user can transfer to the
>>> remote sean> side. 
>>> 
>>> It can be the same address, but does it have to be?
>>> 
>>> A user can directly map local addresses to InfiniBand I/O virtual
>>> addresses, but I don't think it is a requirement. In other words, I
>>> thought that user could register address x and request an InfiniBand
>>> I/O virtual address of y, x != y, for the mapping.
>>> 
>>> I understand why the ib_send_wr's rdma.remote_addr needs to be a
>>> u64, since it ultimately winds up on the wire.
>>> 
>>> In the case of the ib_sge's addr, I didn't think these values left
>>> the local node. My assumption (based on looking at the mthca driver)
>>> is that they are supposed to contain "local"
>>> I/O addresses (bus addresses). Therefore, my confusion over why
>>> dma_addr_t wasn't used.
>> 
>> A privileged user, such as an NFS Daemon or iSER iSCSI Target, can
>> and will create Memory Regions that are not part of its own address
>> space out of page buffers. Even running on a 32-bit kernel it might
>> create a memory region larger than 2**32.
>> 
>> Admittedly, that isn't very likely unless it is the *only* daemon
>> running on the machine. But it is legal.
> 
> How does the size of a region relate to my original question
> on the type of an ib_sge.addr?

The address has to be big enough to enumerate all bytes in the region.

If a region is not constrained to fit within an existing virtual
memory map then it is not constrained by the size of a virtual address,
only by the size of MRs and of physical addresses.

___
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 0 of 20] [RFC] ipath - PathScale InfiniPath driver

[Greg KH]

On Fri, Dec 30, 2005 at 05:40:50PM -0800, Bryan O'Sullivan wrote:
> On Fri, 2005-12-30 at 16:10 -0800, Greg KH wrote:
> 
> > But we (the kernel community), don't really accept that as a valid
> > reason to accept this kind of code, sorry.
> 
> Fair enough.  I'd like some guidance in that case.  Some of our ioctls
> access the hardware more or less directly, while others do things like
> read or reset counters.
> 
> Which of these kinds of operations are appropriate to retain as ioctls,
> in your eyes, and which are best converted to sysfs or configfs
> alternatives?

Idealy, nothing should be new ioctls.  But in the end, it all depends on
exactly what you are trying to do with each different one.

> As an example, take a look at ipath_sma_ioctl.  It seems to me that
> receiving or sending subnet management packets ought to remain as
> ioctls, while getting port or node data could be turned into sysfs
> attributes.  Lane identification could live in configfs.  If you think
> otherwise, please let me know what's more appropriate.

I really don't know what the subnet management stuff involves, sorry.
But doesn't the open-ib layer handle that all for you already?

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] [PATCH] OpenSM: include OpenIB svn version when OpenIB build

[Hal Rosenstock]

OpenSM: include OpenIB svn version when OpenIB build

Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>

Index: osm_opensm.c
===
--- osm_opensm.c(revision 4716)
+++ osm_opensm.c(working copy)
@@ -59,6 +59,9 @@
 #include 
 #include 
 #include 
+#ifdef OSM_VENDOR_INTF_OPENIB
+#include 
+#endif
 #include 
 #include 
 #include 
@@ -206,12 +209,33 @@ osm_opensm_init(
if( status != IB_SUCCESS )
   return ( status );
 
+#ifndef OSM_VENDOR_INTF_OPENIB
/* If there is a log level defined - add the OSM_VERSION to it. */
osm_log( &p_osm->log,
 osm_log_get_level( &p_osm->log ) & ( OSM_LOG_SYS ^ 0xFF ), "%s\n",
 OSM_VERSION );
/* Write the OSM_VERSION to the SYS_LOG */
osm_log( &p_osm->log, OSM_LOG_SYS, "%s\n", OSM_VERSION );   /* Format 
Waived */
+#else
+   if (strlen(OSM_SVN_REVISION))
+   {
+  /* If there is a log level defined - add OSM_VERSION and 
OSM_SVN_REVISION to it. */
+  osm_log( &p_osm->log,
+   osm_log_get_level( &p_osm->log ) & ( OSM_LOG_SYS ^ 0xFF ), "%s 
OpenIB svn %s\n",
+   OSM_VERSION, OSM_SVN_REVISION );
+  /* Write the OSM_VERSION and OSM_SVN_REVISION to the SYS_LOG */
+  osm_log( &p_osm->log, OSM_LOG_SYS, "%s OpenIB svn %s\n", OSM_VERSION, 
OSM_SVN_REVISION );   /* Format Waived */
+   }
+   else
+   {
+  /* If there is a log level defined - add the OSM_VERSION to it. */
+  osm_log( &p_osm->log,
+   osm_log_get_level( &p_osm->log ) & ( OSM_LOG_SYS ^ 0xFF ), 
"%s\n",
+   OSM_VERSION );
+  /* Write the OSM_VERSION to the SYS_LOG */
+  osm_log( &p_osm->log, OSM_LOG_SYS, "%s\n", OSM_VERSION );   /* Format 
Waived */
+   }
+#endif
 
osm_log( &p_osm->log, OSM_LOG_FUNCS, "osm_opensm_init: [\n" ); /* Format 
Waived */
 
Index: main.c
===
--- main.c  (revision 4716)
+++ main.c  (working copy)
@@ -57,6 +57,9 @@
 #include 
 #include 
 #include 
+#ifdef OSM_VENDOR_INTF_OPENIB
+#include 
+#endif
 #include 
 #include 
 #include 
@@ -522,6 +525,10 @@ main(
 
   printf("-\n");
   printf("%s\n", OSM_VERSION);
+#if defined ( OSM_VENDOR_INTF_OPENIB )
+  if (strlen(OSM_SVN_REVISION))
+ printf("Based on OpenIB svn %s\n", OSM_SVN_REVISION);
+#endif
 
   osm_subn_set_default_opt(&opt);
   osm_subn_parse_conf_file(&opt);
Index: Makefile.am
===
--- Makefile.am (revision 4716)
+++ Makefile.am (working copy)
@@ -9,6 +9,22 @@ else
 DBGFLAGS = -g -O2
 endif
 
+if OSMV_OPENIB
+$(srcdir)/../include/opensm/osm_svn_revision.h:
+   if test -f $(srcdir)/../.svn/entries; then \
+   grep revision $(srcdir)/../.svn/entries | sed 
's/revision=/#define OSM_SVN_REVISION /' | sed 's/\/>//' 
>$(srcdir)/../include/opensm/osm_svn_revision.h; \
+   else \
+   echo "#define OSM_SVN_REVISION \"\"" 
>$(srcdir)/../include/opensm/osm_svn_revision.h; \
+   fi
+
+main.c: $(srcdir)/../include/opensm/osm_svn_revision.h
+   if test -f $(srcdir)/../include/opensm/osm_svn_revision.h; then \
+   if test -f  $(srcdir)/../.svn/entries; then \
+   grep revision $(srcdir)/../.svn/entries | sed 
's/revision=/#define OSM_SVN_REVISION /' | sed 's/\/>//' 
>$(srcdir)/../include/opensm/osm_svn_revision.h; \
+   fi \
+   fi
+endif
+
 libopensm_la_CFLAGS = -Wall $(OSMV_CFLAGS) -DVENDOR_RMPP_SUPPORT $(DBGFLAGS) 
-D_XOPEN_SOURCE=600 -D_BSD_SOURCE=1
 
 if HAVE_LD_VERSION_SCRIPT



___
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] [kernel verbs] u64 vs dma_addr_t

[James Lentini]

On Fri, 30 Dec 2005, Caitlin Bestler wrote:

> [EMAIL PROTECTED] wrote:
> > sean> James Lentini wrote:
> > sean> > Why is the ib_sge's addr a u64 and not a dma_addr_t?
> > sean>
> > sean> It's the same address that the user can transfer to the remote
> > sean> side. 
> > 
> > It can be the same address, but does it have to be?
> > 
> > A user can directly map local addresses to InfiniBand I/O
> > virtual addresses, but I don't think it is a requirement. In
> > other words, I thought that user could register address x and
> > request an InfiniBand I/O virtual address of y, x != y, for
> > the mapping.
> > 
> > I understand why the ib_send_wr's rdma.remote_addr needs to
> > be a u64, since it ultimately winds up on the wire.
> > 
> > In the case of the ib_sge's addr, I didn't think these values
> > left the local node. My assumption (based on looking at the
> > mthca driver) is that they are supposed to contain "local"
> > I/O addresses (bus addresses). Therefore, my confusion over
> > why dma_addr_t wasn't used.
> 
> A privileged user, such as an NFS Daemon or iSER iSCSI Target, can 
> and will create Memory Regions that are not part of its own address 
> space out of page buffers. Even running on a 32-bit kernel it might 
> create a memory region larger than 2**32.
> 
> Admittedly, that isn't very likely unless it is the *only* daemon 
> running on the machine. But it is legal.

How does the size of a region relate to my original question on the 
type of an ib_sge.addr?
___
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] fix race in mad.c

[Sean Hefty]

>After removing the port from port_list, ib_mad_port_close flushes port_priv->wq
>before destroying the special QPs. This means that a completion event could
>arrive, and queue a new work in this work queue after flush.
>
>Signed-off-by: Eli Cohen <[EMAIL PROTECTED]>
>Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>
>
>Index: latest/drivers/infiniband/core/mad.c
>===
>--- latest.orig/drivers/infiniband/core/mad.c
>+++ latest/drivers/infiniband/core/mad.c
>@@ -2285,8 +2285,17 @@ static void timeout_sends(void *data)
> static void ib_mad_thread_completion_handler(struct ib_cq *cq, void *arg)
> {
>   struct ib_mad_port_private *port_priv = cq->cq_context;
>+  struct ib_mad_port_private *entry;
>+  unsigned long flags;
>+
>+  spin_lock_irqsave(&ib_mad_port_list_lock, flags);
>+  list_for_each_entry(entry, &ib_mad_port_list, port_list)
>+  if (entry == port_priv) {
>+  queue_work(port_priv->wq, &port_priv->work);
>+  break;
>+  }
>
>-  queue_work(port_priv->wq, &port_priv->work);
>+  spin_unlock_irqrestore(&ib_mad_port_list_lock, flags);
> }

There should be some way to fix this that doesn't involve walking a list on
every completion.  Can't the cleanup be changed?  Either move destroying the QP
after the workqueue flush or transition it to the error state before flushing.

- 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: [PATCH] [TRIVIAL] OpenSM: Separate out OSM_VERSION

[Hal Rosenstock]

On Tue, 2006-01-03 at 12:00, Eitan Zahavi wrote:
> > 
> > On Tue, 2006-01-03 at 10:43, Eitan Zahavi wrote:
> > > Hi Hal,
> > >
> > > Sounds good.
> > > I think you should be able to use the .svn/entries to get the last
> > > update revision and then use svn diff (or diff) to see if local mods
> are
> > > done on top of it...
> > 
> > I'm using .svn/entries at the osm level.
> > 
> [EZ] Do you agree flagging local modifications (that happened after the
> svn up) is important?

Yes, but I'm not sure what you are proposing here.

> > > So we do not get caught by surprise when something broke due to
> > > un-committed mod in the local directory
> > > Thanks
> > >
> > > Eitan Zahavi
> > > Design Technology Director
> > > Mellanox Technologies LTD
> > > Tel:+972-4-9097208
> > > Fax:+972-4-9593245
> > > P.O. Box 586 Yokneam 20692 ISRAEL
> > >
> > >
> > > > -Original Message-
> > > > From: Hal Rosenstock [mailto:[EMAIL PROTECTED]
> > > > Sent: Tuesday, January 03, 2006 5:17 PM
> > > > To: Eitan Zahavi
> > > > Cc: openib-general@openib.org
> > > > Subject: RE: [PATCH] [TRIVIAL] OpenSM: Separate out OSM_VERSION
> > > >
> > > > On Tue, 2006-01-03 at 09:42, Eitan Zahavi wrote:
> > > > > Thanks. Can you elaborate for how that file "
> osm_svn_revision.h"
> > > will
> > > > > be updated?
> > > > > Is it going to be updated by the "autogen.sh" ? or by a checkin
> > > trigger?
> > > >
> > > > Neither; I'm planning to have it updated by the make when needed.
> > > >
> > > > -- Hal
> > > >
> > > > > > -Original Message-
> > > > > > From: Hal Rosenstock [mailto:[EMAIL PROTECTED]
> > > > > > Sent: Tuesday, January 03, 2006 2:25 PM
> > > > > > To: Eitan Zahavi
> > > > > > Cc: openib-general@openib.org
> > > > > > Subject: RE: [PATCH] [TRIVIAL] OpenSM: Separate out
> OSM_VERSION
> > > > > >
> > > > > > Hi Eitan,
> > > > > >
> > > > > > On Tue, 2006-01-03 at 06:55, Eitan Zahavi wrote:
> > > > > > > Hi Hal,
> > > > > > >
> > > > > > > This patch is fine with me and Yael, and Ofer.
> > > > > >
> > > > > > Thanks.
> > > > > >
> > > > > > > We will use some scripts to automatically update the version
> > > info
> > > > > with
> > > > > > > the "build name" and SVN version. We plan to do that for the
> > > > > > > osm_version.h as well as the configure.in files. This will
> > > happen
> > > > > when
> > > > > > > building a distribution of OpenSM code as part of the OpenIB
> > > > > > > distribution or standalone OpenSM drop.
> > > > > >
> > > > > > I will shortly have a patch along these lines which I will
> send to
> > > the
> > > > > > list. It creates a separate osm_svn_revision.h if
> > > > > > userspace/management/osm/.svn/entries is present.
> > > > > >
> > > > > > -- Hal
> > > > > >
> > > > > > > EZ
> > > > > > > Eitan Zahavi
> > > > > > > Design Technology Director
> > > > > > > Mellanox Technologies LTD
> > > > > > > Tel:+972-4-9097208
> > > > > > > Fax:+972-4-9593245
> > > > > > > P.O. Box 586 Yokneam 20692 ISRAEL
> > > > > > >
> > > > > > >
> > > > > > > > -Original Message-
> > > > > > > > From: Hal Rosenstock [mailto:[EMAIL PROTECTED]
> > > > > > > > Sent: Monday, January 02, 2006 4:41 PM
> > > > > > > > To: Yael Kalka; Eitan Zahavi
> > > > > > > > Cc: openib-general@openib.org
> > > > > > > > Subject: [PATCH] [TRIVIAL] OpenSM: Separate out
> OSM_VERSION
> > > > > > > >
> > > > > > > > OpenSM: Separate out OSM_VERSION so when changing only
> needed
> > > > > files
> > > > > > > are
> > > > > > > > recompiled rather than everything
> > > > > > > >
> > > > > > > > Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>
> > > > > > > >
> > > > > > > > Index: osm/include/opensm/osm_version.h
> > > > > > > >
> > > > >
> ===
> > > > > > > > --- osm/include/opensm/osm_version.h(revision 0)
> > > > > > > > +++ osm/include/opensm/osm_version.h(revision 0)
> > > > > > > > @@ -0,0 +1,65 @@
> > > > > > > > +/*
> > > > > > > > + * Copyright (c) 2004, 2005 Voltaire, Inc. All rights
> > > reserved.
> > > > > > > > + * Copyright (c) 2002-2005 Mellanox Technologies LTD. All
> > > rights
> > > > > > > reserved.
> > > > > > > > + * Copyright (c) 1996-2003 Intel Corporation. All rights
> > > > > reserved.
> > > > > > > > + *
> > > > > > > > + * This software is available to you under a choice of
> one of
> > > two
> > > > > > > > + * licenses.  You may choose to be licensed under the
> terms
> > > of
> > > > > the
> > > > > > > GNU
> > > > > > > > + * General Public License (GPL) Version 2, available from
> the
> > > > > file
> > > > > > > > + * COPYING in the main directory of this source tree, or
> the
> > > > > > > > + * OpenIB.org BSD license below:
> > > > > > > > + *
> > > > > > > > + * Redistribution and use in source and binary forms,
> > > with or
> > > > > > > > + * without modification, are permitted provided that
> the
> > > > > > > following
> > > > > > > > + * conditions are met:
> > > > > > > > + *
> > > > > > > > + *  -

[openib-general] Re: strange behaviour in svn 4706 libibverbs/init.cwith two adapters

[Michael S. Tsirkin]

Quoting r. Christoph Raisch <[EMAIL PROTECTED]>:
> libibverbs/src/init.c:271 *list[num_devices++]

wc -l libibverbs/src/init.c
260 libibverbs/src/init.c

Hmm?

-- 
MST
___
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] strange behaviour in svn 4706 libibverbs/init.c with two adapters

[Christoph Raisch]

Hi Roland,
could it be that
libibverbs/src/init.c:271 *list[num_devices++]
actually should be a (*list)[num_devices++]
for num_devices>1 ?

I personally can't follow anymore when I see a ***list,
but my system here thinks that
&(*list[num_devices++]) for num_devices=0 is 0x10017c10
&(*list[num_devices++]) for num_devices=1 is (nil)

&((*list)[num_devices++]) for num_devices=0 is 0x10017c10
&((*list)[num_devices++]) for num_devices=1 is 0x10017c18
To me the second one looks better...

If you just have one IB adapter you won't see a difference...

Gruss / Regards . . . Christoph 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] [TRIVIAL] OpenSM: Separate out OSM_VERSION

[Eitan Zahavi]

> 
> On Tue, 2006-01-03 at 10:43, Eitan Zahavi wrote:
> > Hi Hal,
> >
> > Sounds good.
> > I think you should be able to use the .svn/entries to get the last
> > update revision and then use svn diff (or diff) to see if local mods
are
> > done on top of it...
> 
> I'm using .svn/entries at the osm level.
> 
[EZ] Do you agree flagging local modifications (that happened after the
svn up) is important?

> > So we do not get caught by surprise when something broke due to
> > un-committed mod in the local directory
> > Thanks
> >
> > Eitan Zahavi
> > Design Technology Director
> > Mellanox Technologies LTD
> > Tel:+972-4-9097208
> > Fax:+972-4-9593245
> > P.O. Box 586 Yokneam 20692 ISRAEL
> >
> >
> > > -Original Message-
> > > From: Hal Rosenstock [mailto:[EMAIL PROTECTED]
> > > Sent: Tuesday, January 03, 2006 5:17 PM
> > > To: Eitan Zahavi
> > > Cc: openib-general@openib.org
> > > Subject: RE: [PATCH] [TRIVIAL] OpenSM: Separate out OSM_VERSION
> > >
> > > On Tue, 2006-01-03 at 09:42, Eitan Zahavi wrote:
> > > > Thanks. Can you elaborate for how that file "
osm_svn_revision.h"
> > will
> > > > be updated?
> > > > Is it going to be updated by the "autogen.sh" ? or by a checkin
> > trigger?
> > >
> > > Neither; I'm planning to have it updated by the make when needed.
> > >
> > > -- Hal
> > >
> > > > > -Original Message-
> > > > > From: Hal Rosenstock [mailto:[EMAIL PROTECTED]
> > > > > Sent: Tuesday, January 03, 2006 2:25 PM
> > > > > To: Eitan Zahavi
> > > > > Cc: openib-general@openib.org
> > > > > Subject: RE: [PATCH] [TRIVIAL] OpenSM: Separate out
OSM_VERSION
> > > > >
> > > > > Hi Eitan,
> > > > >
> > > > > On Tue, 2006-01-03 at 06:55, Eitan Zahavi wrote:
> > > > > > Hi Hal,
> > > > > >
> > > > > > This patch is fine with me and Yael, and Ofer.
> > > > >
> > > > > Thanks.
> > > > >
> > > > > > We will use some scripts to automatically update the version
> > info
> > > > with
> > > > > > the "build name" and SVN version. We plan to do that for the
> > > > > > osm_version.h as well as the configure.in files. This will
> > happen
> > > > when
> > > > > > building a distribution of OpenSM code as part of the OpenIB
> > > > > > distribution or standalone OpenSM drop.
> > > > >
> > > > > I will shortly have a patch along these lines which I will
send to
> > the
> > > > > list. It creates a separate osm_svn_revision.h if
> > > > > userspace/management/osm/.svn/entries is present.
> > > > >
> > > > > -- Hal
> > > > >
> > > > > > EZ
> > > > > > Eitan Zahavi
> > > > > > Design Technology Director
> > > > > > Mellanox Technologies LTD
> > > > > > Tel:+972-4-9097208
> > > > > > Fax:+972-4-9593245
> > > > > > P.O. Box 586 Yokneam 20692 ISRAEL
> > > > > >
> > > > > >
> > > > > > > -Original Message-
> > > > > > > From: Hal Rosenstock [mailto:[EMAIL PROTECTED]
> > > > > > > Sent: Monday, January 02, 2006 4:41 PM
> > > > > > > To: Yael Kalka; Eitan Zahavi
> > > > > > > Cc: openib-general@openib.org
> > > > > > > Subject: [PATCH] [TRIVIAL] OpenSM: Separate out
OSM_VERSION
> > > > > > >
> > > > > > > OpenSM: Separate out OSM_VERSION so when changing only
needed
> > > > files
> > > > > > are
> > > > > > > recompiled rather than everything
> > > > > > >
> > > > > > > Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>
> > > > > > >
> > > > > > > Index: osm/include/opensm/osm_version.h
> > > > > > >
> > > >
===
> > > > > > > --- osm/include/opensm/osm_version.h  (revision 0)
> > > > > > > +++ osm/include/opensm/osm_version.h  (revision 0)
> > > > > > > @@ -0,0 +1,65 @@
> > > > > > > +/*
> > > > > > > + * Copyright (c) 2004, 2005 Voltaire, Inc. All rights
> > reserved.
> > > > > > > + * Copyright (c) 2002-2005 Mellanox Technologies LTD. All
> > rights
> > > > > > reserved.
> > > > > > > + * Copyright (c) 1996-2003 Intel Corporation. All rights
> > > > reserved.
> > > > > > > + *
> > > > > > > + * This software is available to you under a choice of
one of
> > two
> > > > > > > + * licenses.  You may choose to be licensed under the
terms
> > of
> > > > the
> > > > > > GNU
> > > > > > > + * General Public License (GPL) Version 2, available from
the
> > > > file
> > > > > > > + * COPYING in the main directory of this source tree, or
the
> > > > > > > + * OpenIB.org BSD license below:
> > > > > > > + *
> > > > > > > + * Redistribution and use in source and binary forms,
> > with or
> > > > > > > + * without modification, are permitted provided that
the
> > > > > > following
> > > > > > > + * conditions are met:
> > > > > > > + *
> > > > > > > + *  - Redistributions of source code must retain the
> > above
> > > > > > > + *copyright notice, this list of conditions and
the
> > > > following
> > > > > > > + *disclaimer.
> > > > > > > + *
> > > > > > > + *  - Redistributions in binary form must reproduce
the
> > above
> > > > > > > + *copyright notice, this list of conditions and
the
> > > > following
>

[openib-general] RE: [PATCH] osm: support for trivial PKey manager

[Hal Rosenstock]

On Sun, 2006-01-01 at 03:14, Ofer Gigi wrote:
> Hi Hal,
> 
> 1. About the osm_indent - you are correct - it should have been in
> another patch.

Thanks. Applied.

> 2. Extra spaces - please remove - thanks.

Done.

> 3. > +   /* signal = osm_lid_mgr_process_sm( p_mgr->p_lid_mgr ); */
> 
> Why add this commented out line ?
> 
> My mistake, I commented the original code and forgot to remove - please
> remove it. 
> 4. >  # -i3   Substitute indent with 3 spaces
> >  # -npcsNo space after procedure calls
> >  # -prs Space after parenthesis
> > -# -nsaiNo space after if keyword
> > -# -nsawNo space after while keyword
> > +# -nsaiNo space after if keyword - removed
> > +# -nsawNo space after while keyword - removed
> 
> Should these comments just be removed ?
> No, please leave them, so people will know what they mean.

Thanks. Applied.

-- 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

[openib-general] RE: [PATCH] [TRIVIAL] OpenSM: Separate out OSM_VERSION

[Hal Rosenstock]

On Tue, 2006-01-03 at 10:43, Eitan Zahavi wrote:
> Hi Hal,
> 
> Sounds good.
> I think you should be able to use the .svn/entries to get the last
> update revision and then use svn diff (or diff) to see if local mods are
> done on top of it...

I'm using .svn/entries at the osm level.

> So we do not get caught by surprise when something broke due to
> un-committed mod in the local directory
> Thanks
> 
> Eitan Zahavi
> Design Technology Director
> Mellanox Technologies LTD
> Tel:+972-4-9097208
> Fax:+972-4-9593245
> P.O. Box 586 Yokneam 20692 ISRAEL
> 
> 
> > -Original Message-
> > From: Hal Rosenstock [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, January 03, 2006 5:17 PM
> > To: Eitan Zahavi
> > Cc: openib-general@openib.org
> > Subject: RE: [PATCH] [TRIVIAL] OpenSM: Separate out OSM_VERSION
> > 
> > On Tue, 2006-01-03 at 09:42, Eitan Zahavi wrote:
> > > Thanks. Can you elaborate for how that file " osm_svn_revision.h"
> will
> > > be updated?
> > > Is it going to be updated by the "autogen.sh" ? or by a checkin
> trigger?
> > 
> > Neither; I'm planning to have it updated by the make when needed.
> > 
> > -- Hal
> > 
> > > > -Original Message-
> > > > From: Hal Rosenstock [mailto:[EMAIL PROTECTED]
> > > > Sent: Tuesday, January 03, 2006 2:25 PM
> > > > To: Eitan Zahavi
> > > > Cc: openib-general@openib.org
> > > > Subject: RE: [PATCH] [TRIVIAL] OpenSM: Separate out OSM_VERSION
> > > >
> > > > Hi Eitan,
> > > >
> > > > On Tue, 2006-01-03 at 06:55, Eitan Zahavi wrote:
> > > > > Hi Hal,
> > > > >
> > > > > This patch is fine with me and Yael, and Ofer.
> > > >
> > > > Thanks.
> > > >
> > > > > We will use some scripts to automatically update the version
> info
> > > with
> > > > > the "build name" and SVN version. We plan to do that for the
> > > > > osm_version.h as well as the configure.in files. This will
> happen
> > > when
> > > > > building a distribution of OpenSM code as part of the OpenIB
> > > > > distribution or standalone OpenSM drop.
> > > >
> > > > I will shortly have a patch along these lines which I will send to
> the
> > > > list. It creates a separate osm_svn_revision.h if
> > > > userspace/management/osm/.svn/entries is present.
> > > >
> > > > -- Hal
> > > >
> > > > > EZ
> > > > > Eitan Zahavi
> > > > > Design Technology Director
> > > > > Mellanox Technologies LTD
> > > > > Tel:+972-4-9097208
> > > > > Fax:+972-4-9593245
> > > > > P.O. Box 586 Yokneam 20692 ISRAEL
> > > > >
> > > > >
> > > > > > -Original Message-
> > > > > > From: Hal Rosenstock [mailto:[EMAIL PROTECTED]
> > > > > > Sent: Monday, January 02, 2006 4:41 PM
> > > > > > To: Yael Kalka; Eitan Zahavi
> > > > > > Cc: openib-general@openib.org
> > > > > > Subject: [PATCH] [TRIVIAL] OpenSM: Separate out OSM_VERSION
> > > > > >
> > > > > > OpenSM: Separate out OSM_VERSION so when changing only needed
> > > files
> > > > > are
> > > > > > recompiled rather than everything
> > > > > >
> > > > > > Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>
> > > > > >
> > > > > > Index: osm/include/opensm/osm_version.h
> > > > > >
> > > ===
> > > > > > --- osm/include/opensm/osm_version.h(revision 0)
> > > > > > +++ osm/include/opensm/osm_version.h(revision 0)
> > > > > > @@ -0,0 +1,65 @@
> > > > > > +/*
> > > > > > + * Copyright (c) 2004, 2005 Voltaire, Inc. All rights
> reserved.
> > > > > > + * Copyright (c) 2002-2005 Mellanox Technologies LTD. All
> rights
> > > > > reserved.
> > > > > > + * Copyright (c) 1996-2003 Intel Corporation. All rights
> > > reserved.
> > > > > > + *
> > > > > > + * This software is available to you under a choice of one of
> two
> > > > > > + * licenses.  You may choose to be licensed under the terms
> of
> > > the
> > > > > GNU
> > > > > > + * General Public License (GPL) Version 2, available from the
> > > file
> > > > > > + * COPYING in the main directory of this source tree, or the
> > > > > > + * OpenIB.org BSD license below:
> > > > > > + *
> > > > > > + * Redistribution and use in source and binary forms,
> with or
> > > > > > + * without modification, are permitted provided that the
> > > > > following
> > > > > > + * conditions are met:
> > > > > > + *
> > > > > > + *  - Redistributions of source code must retain the
> above
> > > > > > + *copyright notice, this list of conditions and the
> > > following
> > > > > > + *disclaimer.
> > > > > > + *
> > > > > > + *  - Redistributions in binary form must reproduce the
> above
> > > > > > + *copyright notice, this list of conditions and the
> > > following
> > > > > > + *disclaimer in the documentation and/or other
> materials
> > > > > > + *provided with the distribution.
> > > > > > + *
> > > > > > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
> > > > > > KIND,
> > > > > > + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE
> > > > > > WARRANTIES OF
> > > > > > + * MERCHANTA

[openib-general] RE: [PATCH] [TRIVIAL] OpenSM: Separate out OSM_VERSION

[Eitan Zahavi]

Hi Hal,

Sounds good.
I think you should be able to use the .svn/entries to get the last
update revision and then use svn diff (or diff) to see if local mods are
done on top of it...
So we do not get caught by surprise when something broke due to
un-committed mod in the local directory

Thanks

Eitan Zahavi
Design Technology Director
Mellanox Technologies LTD
Tel:+972-4-9097208
Fax:+972-4-9593245
P.O. Box 586 Yokneam 20692 ISRAEL


> -Original Message-
> From: Hal Rosenstock [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, January 03, 2006 5:17 PM
> To: Eitan Zahavi
> Cc: openib-general@openib.org
> Subject: RE: [PATCH] [TRIVIAL] OpenSM: Separate out OSM_VERSION
> 
> On Tue, 2006-01-03 at 09:42, Eitan Zahavi wrote:
> > Thanks. Can you elaborate for how that file " osm_svn_revision.h"
will
> > be updated?
> > Is it going to be updated by the "autogen.sh" ? or by a checkin
trigger?
> 
> Neither; I'm planning to have it updated by the make when needed.
> 
> -- Hal
> 
> > > -Original Message-
> > > From: Hal Rosenstock [mailto:[EMAIL PROTECTED]
> > > Sent: Tuesday, January 03, 2006 2:25 PM
> > > To: Eitan Zahavi
> > > Cc: openib-general@openib.org
> > > Subject: RE: [PATCH] [TRIVIAL] OpenSM: Separate out OSM_VERSION
> > >
> > > Hi Eitan,
> > >
> > > On Tue, 2006-01-03 at 06:55, Eitan Zahavi wrote:
> > > > Hi Hal,
> > > >
> > > > This patch is fine with me and Yael, and Ofer.
> > >
> > > Thanks.
> > >
> > > > We will use some scripts to automatically update the version
info
> > with
> > > > the "build name" and SVN version. We plan to do that for the
> > > > osm_version.h as well as the configure.in files. This will
happen
> > when
> > > > building a distribution of OpenSM code as part of the OpenIB
> > > > distribution or standalone OpenSM drop.
> > >
> > > I will shortly have a patch along these lines which I will send to
the
> > > list. It creates a separate osm_svn_revision.h if
> > > userspace/management/osm/.svn/entries is present.
> > >
> > > -- Hal
> > >
> > > > EZ
> > > > Eitan Zahavi
> > > > Design Technology Director
> > > > Mellanox Technologies LTD
> > > > Tel:+972-4-9097208
> > > > Fax:+972-4-9593245
> > > > P.O. Box 586 Yokneam 20692 ISRAEL
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Hal Rosenstock [mailto:[EMAIL PROTECTED]
> > > > > Sent: Monday, January 02, 2006 4:41 PM
> > > > > To: Yael Kalka; Eitan Zahavi
> > > > > Cc: openib-general@openib.org
> > > > > Subject: [PATCH] [TRIVIAL] OpenSM: Separate out OSM_VERSION
> > > > >
> > > > > OpenSM: Separate out OSM_VERSION so when changing only needed
> > files
> > > > are
> > > > > recompiled rather than everything
> > > > >
> > > > > Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>
> > > > >
> > > > > Index: osm/include/opensm/osm_version.h
> > > > >
> > ===
> > > > > --- osm/include/opensm/osm_version.h  (revision 0)
> > > > > +++ osm/include/opensm/osm_version.h  (revision 0)
> > > > > @@ -0,0 +1,65 @@
> > > > > +/*
> > > > > + * Copyright (c) 2004, 2005 Voltaire, Inc. All rights
reserved.
> > > > > + * Copyright (c) 2002-2005 Mellanox Technologies LTD. All
rights
> > > > reserved.
> > > > > + * Copyright (c) 1996-2003 Intel Corporation. All rights
> > reserved.
> > > > > + *
> > > > > + * This software is available to you under a choice of one of
two
> > > > > + * licenses.  You may choose to be licensed under the terms
of
> > the
> > > > GNU
> > > > > + * General Public License (GPL) Version 2, available from the
> > file
> > > > > + * COPYING in the main directory of this source tree, or the
> > > > > + * OpenIB.org BSD license below:
> > > > > + *
> > > > > + * Redistribution and use in source and binary forms,
with or
> > > > > + * without modification, are permitted provided that the
> > > > following
> > > > > + * conditions are met:
> > > > > + *
> > > > > + *  - Redistributions of source code must retain the
above
> > > > > + *copyright notice, this list of conditions and the
> > following
> > > > > + *disclaimer.
> > > > > + *
> > > > > + *  - Redistributions in binary form must reproduce the
above
> > > > > + *copyright notice, this list of conditions and the
> > following
> > > > > + *disclaimer in the documentation and/or other
materials
> > > > > + *provided with the distribution.
> > > > > + *
> > > > > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
> > > > > KIND,
> > > > > + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE
> > > > > WARRANTIES OF
> > > > > + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> > > > > + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR
> > > COPYRIGHT
> > > > > HOLDERS
> > > > > + * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> > > WHETHER
> > > > > IN AN
> > > > > + * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT
> OF
> > > OR
> > > > > IN
> > > > > + * CONNECTION WITH THE SOFTWARE OR THE U

[openib-general] [PATCH] fix race in mad.c

[Michael S. Tsirkin]

After removing the port from port_list, ib_mad_port_close flushes port_priv->wq
before destroying the special QPs. This means that a completion event could
arrive, and queue a new work in this work queue after flush.

Signed-off-by: Eli Cohen <[EMAIL PROTECTED]>
Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>

Index: latest/drivers/infiniband/core/mad.c
===
--- latest.orig/drivers/infiniband/core/mad.c
+++ latest/drivers/infiniband/core/mad.c
@@ -2285,8 +2285,17 @@ static void timeout_sends(void *data)
 static void ib_mad_thread_completion_handler(struct ib_cq *cq, void *arg)
 {
struct ib_mad_port_private *port_priv = cq->cq_context;
+   struct ib_mad_port_private *entry;
+   unsigned long flags;
+
+   spin_lock_irqsave(&ib_mad_port_list_lock, flags);
+   list_for_each_entry(entry, &ib_mad_port_list, port_list)
+   if (entry == port_priv) {
+   queue_work(port_priv->wq, &port_priv->work);
+   break;
+   }
 
-   queue_work(port_priv->wq, &port_priv->work);
+   spin_unlock_irqrestore(&ib_mad_port_list_lock, flags);
 }
 
 /*

-- 
MST
___
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] [TRIVIAL] OpenSM: Separate out OSM_VERSION

[Hal Rosenstock]

On Tue, 2006-01-03 at 09:42, Eitan Zahavi wrote:
> Thanks. Can you elaborate for how that file " osm_svn_revision.h" will
> be updated?
> Is it going to be updated by the "autogen.sh" ? or by a checkin trigger?

Neither; I'm planning to have it updated by the make when needed.

-- Hal

> > -Original Message-
> > From: Hal Rosenstock [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, January 03, 2006 2:25 PM
> > To: Eitan Zahavi
> > Cc: openib-general@openib.org
> > Subject: RE: [PATCH] [TRIVIAL] OpenSM: Separate out OSM_VERSION
> > 
> > Hi Eitan,
> > 
> > On Tue, 2006-01-03 at 06:55, Eitan Zahavi wrote:
> > > Hi Hal,
> > >
> > > This patch is fine with me and Yael, and Ofer.
> > 
> > Thanks.
> > 
> > > We will use some scripts to automatically update the version info
> with
> > > the "build name" and SVN version. We plan to do that for the
> > > osm_version.h as well as the configure.in files. This will happen
> when
> > > building a distribution of OpenSM code as part of the OpenIB
> > > distribution or standalone OpenSM drop.
> > 
> > I will shortly have a patch along these lines which I will send to the
> > list. It creates a separate osm_svn_revision.h if
> > userspace/management/osm/.svn/entries is present.
> > 
> > -- Hal
> > 
> > > EZ
> > > Eitan Zahavi
> > > Design Technology Director
> > > Mellanox Technologies LTD
> > > Tel:+972-4-9097208
> > > Fax:+972-4-9593245
> > > P.O. Box 586 Yokneam 20692 ISRAEL
> > >
> > >
> > > > -Original Message-
> > > > From: Hal Rosenstock [mailto:[EMAIL PROTECTED]
> > > > Sent: Monday, January 02, 2006 4:41 PM
> > > > To: Yael Kalka; Eitan Zahavi
> > > > Cc: openib-general@openib.org
> > > > Subject: [PATCH] [TRIVIAL] OpenSM: Separate out OSM_VERSION
> > > >
> > > > OpenSM: Separate out OSM_VERSION so when changing only needed
> files
> > > are
> > > > recompiled rather than everything
> > > >
> > > > Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>
> > > >
> > > > Index: osm/include/opensm/osm_version.h
> > > >
> ===
> > > > --- osm/include/opensm/osm_version.h(revision 0)
> > > > +++ osm/include/opensm/osm_version.h(revision 0)
> > > > @@ -0,0 +1,65 @@
> > > > +/*
> > > > + * Copyright (c) 2004, 2005 Voltaire, Inc. All rights reserved.
> > > > + * Copyright (c) 2002-2005 Mellanox Technologies LTD. All rights
> > > reserved.
> > > > + * Copyright (c) 1996-2003 Intel Corporation. All rights
> reserved.
> > > > + *
> > > > + * This software is available to you under a choice of one of two
> > > > + * licenses.  You may choose to be licensed under the terms of
> the
> > > GNU
> > > > + * General Public License (GPL) Version 2, available from the
> file
> > > > + * COPYING in the main directory of this source tree, or the
> > > > + * OpenIB.org BSD license below:
> > > > + *
> > > > + * Redistribution and use in source and binary forms, with or
> > > > + * without modification, are permitted provided that the
> > > following
> > > > + * conditions are met:
> > > > + *
> > > > + *  - Redistributions of source code must retain the above
> > > > + *copyright notice, this list of conditions and the
> following
> > > > + *disclaimer.
> > > > + *
> > > > + *  - Redistributions in binary form must reproduce the above
> > > > + *copyright notice, this list of conditions and the
> following
> > > > + *disclaimer in the documentation and/or other materials
> > > > + *provided with the distribution.
> > > > + *
> > > > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
> > > > KIND,
> > > > + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE
> > > > WARRANTIES OF
> > > > + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> > > > + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR
> > COPYRIGHT
> > > > HOLDERS
> > > > + * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> > WHETHER
> > > > IN AN
> > > > + * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF
> > OR
> > > > IN
> > > > + * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
> > IN
> > > > THE
> > > > + * SOFTWARE.
> > > > + *
> > > > + * $Id$
> > > > + */
> > > > +
> > > > +
> > > > +#ifndef _OSM_VERSION_H_
> > > > +#define _OSM_VERSION_H_
> > > > +
> > > > +#ifdef __cplusplus
> > > > +#  define BEGIN_C_DECLS extern "C" {
> > > > +#  define END_C_DECLS   }
> > > > +#else /* !__cplusplus */
> > > > +#  define BEGIN_C_DECLS
> > > > +#  define END_C_DECLS
> > > > +#endif /* __cplusplus */
> > > > +
> > > > +BEGIN_C_DECLS
> > > > +
> > > > +/s* OpenSM: Base/OSM_VERSION
> > > > +* NAME
> > > > +*  OSM_VERSION
> > > > +*
> > > > +* DESCRIPTION
> > > > +*  The version string for OpenSM
> > > > +*
> > > > +* SYNOPSIS
> > > > +*/
> > > > +#define OSM_VERSION "OpenSM Rev:openib-1.1.0"
> > > > +//
> > > > +
> > > > +END_C_DECLS
> > > > +
> > > > +#endif /* _OSM_VERSION_H_ */
> > > >
> > > > Property changes on: osm/include/o

Out of Office AutoReply: [openib-general] [EMAIL PROTECTED] rg

[Wayne Augsburger]

Title: Out of Office AutoReply: [openib-general] openib-general@openib.org





I will be out of the office for the Christmas/new years holidays; returning on January 3.  During this time I will have limited access to email.  If you need immediate assistance, please contact [EMAIL PROTECTED] 

Thanks,
Wayne



___
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

Out of Office AutoReply: [openib-general] [EMAIL PROTECTED] rg

[Trevor Caulder]

Title: Out of Office AutoReply: [openib-general] openib-general@openib.org





I will be out of the office until Tuesday 1/3.  If you have an urgent issues, please contact Todd Wilde ([EMAIL PROTECTED]) or Matt Finlay ([EMAIL PROTECTED])

Thanks,


Trevor



___
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] [TRIVIAL] OpenSM: Separate out OSM_VERSION

[Eitan Zahavi]

Thanks. Can you elaborate for how that file " osm_svn_revision.h" will
be updated?
Is it going to be updated by the "autogen.sh" ? or by a checkin trigger?


> -Original Message-
> From: Hal Rosenstock [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, January 03, 2006 2:25 PM
> To: Eitan Zahavi
> Cc: openib-general@openib.org
> Subject: RE: [PATCH] [TRIVIAL] OpenSM: Separate out OSM_VERSION
> 
> Hi Eitan,
> 
> On Tue, 2006-01-03 at 06:55, Eitan Zahavi wrote:
> > Hi Hal,
> >
> > This patch is fine with me and Yael, and Ofer.
> 
> Thanks.
> 
> > We will use some scripts to automatically update the version info
with
> > the "build name" and SVN version. We plan to do that for the
> > osm_version.h as well as the configure.in files. This will happen
when
> > building a distribution of OpenSM code as part of the OpenIB
> > distribution or standalone OpenSM drop.
> 
> I will shortly have a patch along these lines which I will send to the
> list. It creates a separate osm_svn_revision.h if
> userspace/management/osm/.svn/entries is present.
> 
> -- Hal
> 
> > EZ
> > Eitan Zahavi
> > Design Technology Director
> > Mellanox Technologies LTD
> > Tel:+972-4-9097208
> > Fax:+972-4-9593245
> > P.O. Box 586 Yokneam 20692 ISRAEL
> >
> >
> > > -Original Message-
> > > From: Hal Rosenstock [mailto:[EMAIL PROTECTED]
> > > Sent: Monday, January 02, 2006 4:41 PM
> > > To: Yael Kalka; Eitan Zahavi
> > > Cc: openib-general@openib.org
> > > Subject: [PATCH] [TRIVIAL] OpenSM: Separate out OSM_VERSION
> > >
> > > OpenSM: Separate out OSM_VERSION so when changing only needed
files
> > are
> > > recompiled rather than everything
> > >
> > > Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>
> > >
> > > Index: osm/include/opensm/osm_version.h
> > >
===
> > > --- osm/include/opensm/osm_version.h  (revision 0)
> > > +++ osm/include/opensm/osm_version.h  (revision 0)
> > > @@ -0,0 +1,65 @@
> > > +/*
> > > + * Copyright (c) 2004, 2005 Voltaire, Inc. All rights reserved.
> > > + * Copyright (c) 2002-2005 Mellanox Technologies LTD. All rights
> > reserved.
> > > + * Copyright (c) 1996-2003 Intel Corporation. All rights
reserved.
> > > + *
> > > + * This software is available to you under a choice of one of two
> > > + * licenses.  You may choose to be licensed under the terms of
the
> > GNU
> > > + * General Public License (GPL) Version 2, available from the
file
> > > + * COPYING in the main directory of this source tree, or the
> > > + * OpenIB.org BSD license below:
> > > + *
> > > + * Redistribution and use in source and binary forms, with or
> > > + * without modification, are permitted provided that the
> > following
> > > + * conditions are met:
> > > + *
> > > + *  - Redistributions of source code must retain the above
> > > + *copyright notice, this list of conditions and the
following
> > > + *disclaimer.
> > > + *
> > > + *  - Redistributions in binary form must reproduce the above
> > > + *copyright notice, this list of conditions and the
following
> > > + *disclaimer in the documentation and/or other materials
> > > + *provided with the distribution.
> > > + *
> > > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
> > > KIND,
> > > + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE
> > > WARRANTIES OF
> > > + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> > > + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR
> COPYRIGHT
> > > HOLDERS
> > > + * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> WHETHER
> > > IN AN
> > > + * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF
> OR
> > > IN
> > > + * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
> IN
> > > THE
> > > + * SOFTWARE.
> > > + *
> > > + * $Id$
> > > + */
> > > +
> > > +
> > > +#ifndef _OSM_VERSION_H_
> > > +#define _OSM_VERSION_H_
> > > +
> > > +#ifdef __cplusplus
> > > +#  define BEGIN_C_DECLS extern "C" {
> > > +#  define END_C_DECLS   }
> > > +#else /* !__cplusplus */
> > > +#  define BEGIN_C_DECLS
> > > +#  define END_C_DECLS
> > > +#endif /* __cplusplus */
> > > +
> > > +BEGIN_C_DECLS
> > > +
> > > +/s* OpenSM: Base/OSM_VERSION
> > > +* NAME
> > > +*OSM_VERSION
> > > +*
> > > +* DESCRIPTION
> > > +*The version string for OpenSM
> > > +*
> > > +* SYNOPSIS
> > > +*/
> > > +#define OSM_VERSION "OpenSM Rev:openib-1.1.0"
> > > +//
> > > +
> > > +END_C_DECLS
> > > +
> > > +#endif   /* _OSM_VERSION_H_ */
> > >
> > > Property changes on: osm/include/opensm/osm_version.h
> > >
___
> > > Name: svn:keywords
> > >+ Id
> > >
> > > Index: osm/include/opensm/osm_base.h
> > >
===
> > > --- osm/include/opensm/osm_base.h (revision 4686)
> > > +++ osm/include/opensm/osm_base.h (working copy)
> > > @@ -89,18 +89,6 @@ BEGIN_C_DECLS
>

[openib-general] $B$b$7$+$7$F!D(B

[info]

$B!X$b$7$+$7$F2?EY$b$*4j$$$7$A$c$C$F$b$&7y$o$l$A$c$C$?$+$J!D(B
[EMAIL PROTECTED]@[EMAIL PROTECTED](B
[EMAIL PROTECTED],[EMAIL PROTECTED]!G$C$F$F!D(B
$BJV;[EMAIL PROTECTED];$a$F2?$+O"MmM_$7$$$G$9!#!Y(B
http://www.megabazooka.com/?num=6565
$B$"$J$?$O!Z(B332743$B!!(B $B?pJf![MM$+$i;XL>$5$l$?0Y!"(B
$B%K%C%/%M!<%`$N:G8e$K!V(B102$B!W$rIU$1$FD:$1$l$P!"(B
$BEPO?$NMxMQL5NA$HD>$,$G$-$^$9!#(B



$B5qH](B
___
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] [TRIVIAL] OpenSM: Separate out OSM_VERSION

[Hal Rosenstock]

Hi Eitan,

On Tue, 2006-01-03 at 06:55, Eitan Zahavi wrote:
> Hi Hal,
> 
> This patch is fine with me and Yael, and Ofer.

Thanks.

> We will use some scripts to automatically update the version info with
> the "build name" and SVN version. We plan to do that for the
> osm_version.h as well as the configure.in files. This will happen when
> building a distribution of OpenSM code as part of the OpenIB
> distribution or standalone OpenSM drop.

I will shortly have a patch along these lines which I will send to the
list. It creates a separate osm_svn_revision.h if
userspace/management/osm/.svn/entries is present.

-- Hal

> EZ
> Eitan Zahavi
> Design Technology Director
> Mellanox Technologies LTD
> Tel:+972-4-9097208
> Fax:+972-4-9593245
> P.O. Box 586 Yokneam 20692 ISRAEL
> 
> 
> > -Original Message-
> > From: Hal Rosenstock [mailto:[EMAIL PROTECTED]
> > Sent: Monday, January 02, 2006 4:41 PM
> > To: Yael Kalka; Eitan Zahavi
> > Cc: openib-general@openib.org
> > Subject: [PATCH] [TRIVIAL] OpenSM: Separate out OSM_VERSION
> > 
> > OpenSM: Separate out OSM_VERSION so when changing only needed files
> are
> > recompiled rather than everything
> > 
> > Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>
> > 
> > Index: osm/include/opensm/osm_version.h
> > ===
> > --- osm/include/opensm/osm_version.h(revision 0)
> > +++ osm/include/opensm/osm_version.h(revision 0)
> > @@ -0,0 +1,65 @@
> > +/*
> > + * Copyright (c) 2004, 2005 Voltaire, Inc. All rights reserved.
> > + * Copyright (c) 2002-2005 Mellanox Technologies LTD. All rights
> reserved.
> > + * Copyright (c) 1996-2003 Intel Corporation. All rights reserved.
> > + *
> > + * This software is available to you under a choice of one of two
> > + * licenses.  You may choose to be licensed under the terms of the
> GNU
> > + * General Public License (GPL) Version 2, available from the file
> > + * COPYING in the main directory of this source tree, or the
> > + * OpenIB.org BSD license below:
> > + *
> > + * Redistribution and use in source and binary forms, with or
> > + * without modification, are permitted provided that the
> following
> > + * conditions are met:
> > + *
> > + *  - Redistributions of source code must retain the above
> > + *copyright notice, this list of conditions and the following
> > + *disclaimer.
> > + *
> > + *  - Redistributions in binary form must reproduce the above
> > + *copyright notice, this list of conditions and the following
> > + *disclaimer in the documentation and/or other materials
> > + *provided with the distribution.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
> > KIND,
> > + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE
> > WARRANTIES OF
> > + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> > + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> > HOLDERS
> > + * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
> > IN AN
> > + * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR
> > IN
> > + * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
> > THE
> > + * SOFTWARE.
> > + *
> > + * $Id$
> > + */
> > +
> > +
> > +#ifndef _OSM_VERSION_H_
> > +#define _OSM_VERSION_H_
> > +
> > +#ifdef __cplusplus
> > +#  define BEGIN_C_DECLS extern "C" {
> > +#  define END_C_DECLS   }
> > +#else /* !__cplusplus */
> > +#  define BEGIN_C_DECLS
> > +#  define END_C_DECLS
> > +#endif /* __cplusplus */
> > +
> > +BEGIN_C_DECLS
> > +
> > +/s* OpenSM: Base/OSM_VERSION
> > +* NAME
> > +*  OSM_VERSION
> > +*
> > +* DESCRIPTION
> > +*  The version string for OpenSM
> > +*
> > +* SYNOPSIS
> > +*/
> > +#define OSM_VERSION "OpenSM Rev:openib-1.1.0"
> > +//
> > +
> > +END_C_DECLS
> > +
> > +#endif /* _OSM_VERSION_H_ */
> > 
> > Property changes on: osm/include/opensm/osm_version.h
> > ___
> > Name: svn:keywords
> >+ Id
> > 
> > Index: osm/include/opensm/osm_base.h
> > ===
> > --- osm/include/opensm/osm_base.h   (revision 4686)
> > +++ osm/include/opensm/osm_base.h   (working copy)
> > @@ -89,18 +89,6 @@ BEGIN_C_DECLS
> >  *  Steve King, Intel
> >  *
> >  */
> > -/s* OpenSM: Base/OSM_VERSION
> > -* NAME
> > -*  OSM_VERSION
> > -*
> > -* DESCRIPTION
> > -*  The version string for OpenSM
> > -*
> > -* SYNOPSIS
> > -*/
> > -#define OSM_VERSION "OpenSM Rev:openib-1.1.0"
> > -//
> > -
> >  /s* OpenSM: Base/OSM_DEFAULT_M_KEY
> >  * NAME
> >  *  OSM_DEFAULT_M_KEY
> > Index: osm/opensm/osm_opensm.c
> > ===
> > --- osm/opensm/osm_opensm.c (revision 4686)
> > +++ osm/opensm/osm_opensm.c (working copy)
> > @@ -58,6 +58,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 

[openib-general] RE: [PATCH] [TRIVIAL] OpenSM: Separate out OSM_VERSION

[Eitan Zahavi]

Hi Hal,

This patch is fine with me and Yael, and Ofer.

We will use some scripts to automatically update the version info with
the "build name" and SVN version. We plan to do that for the
osm_version.h as well as the configure.in files. This will happen when
building a distribution of OpenSM code as part of the OpenIB
distribution or standalone OpenSM drop.

EZ
Eitan Zahavi
Design Technology Director
Mellanox Technologies LTD
Tel:+972-4-9097208
Fax:+972-4-9593245
P.O. Box 586 Yokneam 20692 ISRAEL


> -Original Message-
> From: Hal Rosenstock [mailto:[EMAIL PROTECTED]
> Sent: Monday, January 02, 2006 4:41 PM
> To: Yael Kalka; Eitan Zahavi
> Cc: openib-general@openib.org
> Subject: [PATCH] [TRIVIAL] OpenSM: Separate out OSM_VERSION
> 
> OpenSM: Separate out OSM_VERSION so when changing only needed files
are
> recompiled rather than everything
> 
> Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>
> 
> Index: osm/include/opensm/osm_version.h
> ===
> --- osm/include/opensm/osm_version.h  (revision 0)
> +++ osm/include/opensm/osm_version.h  (revision 0)
> @@ -0,0 +1,65 @@
> +/*
> + * Copyright (c) 2004, 2005 Voltaire, Inc. All rights reserved.
> + * Copyright (c) 2002-2005 Mellanox Technologies LTD. All rights
reserved.
> + * Copyright (c) 1996-2003 Intel Corporation. All rights reserved.
> + *
> + * This software is available to you under a choice of one of two
> + * licenses.  You may choose to be licensed under the terms of the
GNU
> + * General Public License (GPL) Version 2, available from the file
> + * COPYING in the main directory of this source tree, or the
> + * OpenIB.org BSD license below:
> + *
> + * Redistribution and use in source and binary forms, with or
> + * without modification, are permitted provided that the
following
> + * conditions are met:
> + *
> + *  - Redistributions of source code must retain the above
> + *copyright notice, this list of conditions and the following
> + *disclaimer.
> + *
> + *  - Redistributions in binary form must reproduce the above
> + *copyright notice, this list of conditions and the following
> + *disclaimer in the documentation and/or other materials
> + *provided with the distribution.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
> KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE
> WARRANTIES OF
> + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> HOLDERS
> + * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
> IN AN
> + * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR
> IN
> + * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
> THE
> + * SOFTWARE.
> + *
> + * $Id$
> + */
> +
> +
> +#ifndef _OSM_VERSION_H_
> +#define _OSM_VERSION_H_
> +
> +#ifdef __cplusplus
> +#  define BEGIN_C_DECLS extern "C" {
> +#  define END_C_DECLS   }
> +#else /* !__cplusplus */
> +#  define BEGIN_C_DECLS
> +#  define END_C_DECLS
> +#endif /* __cplusplus */
> +
> +BEGIN_C_DECLS
> +
> +/s* OpenSM: Base/OSM_VERSION
> +* NAME
> +*OSM_VERSION
> +*
> +* DESCRIPTION
> +*The version string for OpenSM
> +*
> +* SYNOPSIS
> +*/
> +#define OSM_VERSION "OpenSM Rev:openib-1.1.0"
> +//
> +
> +END_C_DECLS
> +
> +#endif   /* _OSM_VERSION_H_ */
> 
> Property changes on: osm/include/opensm/osm_version.h
> ___
> Name: svn:keywords
>+ Id
> 
> Index: osm/include/opensm/osm_base.h
> ===
> --- osm/include/opensm/osm_base.h (revision 4686)
> +++ osm/include/opensm/osm_base.h (working copy)
> @@ -89,18 +89,6 @@ BEGIN_C_DECLS
>  *Steve King, Intel
>  *
>  */
> -/s* OpenSM: Base/OSM_VERSION
> -* NAME
> -*OSM_VERSION
> -*
> -* DESCRIPTION
> -*The version string for OpenSM
> -*
> -* SYNOPSIS
> -*/
> -#define OSM_VERSION "OpenSM Rev:openib-1.1.0"
> -//
> -
>  /s* OpenSM: Base/OSM_DEFAULT_M_KEY
>  * NAME
>  *OSM_DEFAULT_M_KEY
> Index: osm/opensm/osm_opensm.c
> ===
> --- osm/opensm/osm_opensm.c   (revision 4686)
> +++ osm/opensm/osm_opensm.c   (working copy)
> @@ -58,6 +58,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> Index: osm/opensm/main.c
> ===
> --- osm/opensm/main.c (revision 4686)
> +++ osm/opensm/main.c (working copy)
> @@ -56,6 +56,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> 
> 

___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listin

[openib-general] [PATCH] iser: simplify handling of iscsi unsolicited data

[Or Gerlitz]

The patch below eliminates the special handling of memory to be used for 
iscsi unsolicited data write, instead all the command data is registered 
for rdma. The descriptors holding the rdma registration info were much 
simplified, the fields rdma_read/write_dto and send/recv_buff_list were 
removed from struct iscsi_iser_cmd_task and are now replaced with rdma_regd.

Signed-off-by: Alex Nezhinsky <[EMAIL PROTECTED]>
Signed-off-by: Or Gerlitz <[EMAIL PROTECTED]>


Index: ulp/iser/iser_memory.h
===
--- ulp/iser/iser_memory.h  (revision 4622)
+++ ulp/iser/iser_memory.h  (working copy)
@@ -54,13 +54,6 @@ void iser_reg_single(struct iser_adaptor
 struct iser_regd_buf *p_regd_buf,
 enum dma_data_direction direction);
 
-void iser_reg_single_task(struct iser_adaptor *p_iser_adaptor,
-struct iser_regd_buf *p_regd_buf,
-void *virt_addr,
-dma_addr_t dma_addr,
-unsigned long data_size,
-enum dma_data_direction direction);
-
 /* scatterlist */
 int iser_sg_size(struct iser_data_buf *p_mem);
 
@@ -70,11 +63,6 @@ void iser_start_rdma_unaligned_sg(struct
 void iser_finalize_rdma_unaligned_sg(struct iscsi_iser_cmd_task  *p_iser_task);
 
 /* iser_data_buf */
-unsigned int iser_data_buf_contig_len(struct iser_data_buf *p_data,
-int skip,
-dma_addr_t *chunk_dma_addr,
-int *chink_sz);
-
 unsigned int iser_data_buf_aligned_len(struct iser_data_buf *p_data,
  int skip);
 
Index: ulp/iser/iscsi_iser.h
===
--- ulp/iser/iscsi_iser.h   (revision 4622)
+++ ulp/iser/iscsi_iser.h   (working copy)
@@ -277,16 +277,8 @@ struct iscsi_iser_cmd_task {
 
unsigned int post_send_count; /* posted send buffers pending completion 
*/
 
-   /* buffers, to release when the task is complete */
-   struct list_head send_buff_list;
-   struct list_head rcv_buff_list;
-   struct iser_dto  rdma_read_dto;
-   struct iser_dto  rdma_write_dto;
-
-   struct list_head conn_list; /* Tasks list of the conn */
-   struct list_head hash_list; /* Hash table bucket entry */
-
int dir[ISER_DIRS_NUM]; /* set if direction used */
+   struct iser_regd_buf *rdma_regd[ISER_DIRS_NUM]; /* regd rdma buffer */
unsigned long data_len[ISER_DIRS_NUM];  /* total data length */
struct iser_data_buf data[ISER_DIRS_NUM]; /* orig. data descriptor */
struct iser_data_buf data_copy[ISER_DIRS_NUM]; /* contig. copy */
Index: ulp/iser/iser.h
===
--- ulp/iser/iser.h (revision 4622)
+++ ulp/iser/iser.h (working copy)
@@ -63,16 +63,9 @@
 #define ISER_TOTAL_HEADERS_LEN \
(ISER_HDR_LEN + ISER_PDU_BHS_LENGTH)
 
-/* Hash tables */
-#define HASH_TABLE_SIZE256
-
 /* Various size limits */
 #define ISER_LOGIN_PHASE_PDU_DATA_LEN  (8*1024)/* 8K */
 
-struct hash_table {
-   struct list_head bucket_head[HASH_TABLE_SIZE];
-   spinlock_t lock;
-};
 
 struct iser_page_vec {
u64 *pages;
@@ -99,9 +92,6 @@ struct iser_regd_buf {
enum dma_data_direction direction; /* direction for dma_unmap */
unsigned int data_size;
 
-
-   /* To be chained here, if freeing upon completion is signaled */
-   struct list_head free_upon_comp_list;
/* Reference count, memory freed when decremented to 0 */
atomic_t ref_count;
 };
@@ -149,8 +139,6 @@ struct iser_global {
 
kmem_cache_t *login_cache;
kmem_cache_t *header_cache;
-
-   struct hash_table task_hash;/* hash table for tasks */
 }; /* iser_global */
 
 extern struct iser_global ig;
Index: ulp/iser/iser_dto.c
===
--- ulp/iser/iser_dto.c (revision 4622)
+++ ulp/iser/iser_dto.c (working copy)
@@ -79,152 +79,6 @@ int iser_dto_add_regd_buff(struct iser_d
 }
 
 /**
- * iser_dto_clone_regd_buffs - creates a dto (dst) which refers to a subrange
- * of the memory referenced by another dto (src).
- */
-void iser_dto_clone_regd_buffs(struct iser_dto *p_dst,
-  struct iser_dto *p_src,
-  unsigned long offset,
-  unsigned long size)
-{
-   unsigned long remaining_offset = offset;
-   unsigned long remaining_size = size;
-   unsigned long regd_buf_size;
-   unsigned long used_size;
-   int i;
-
-   for (i = 0; i < p_src->regd_vector_len; i++) {
-   regd_buf_size = p_src->used_sz[i] > 0 ?
-   p_src->used_sz[i] :
-   

Re: [openib-general] Kickstart over OpenIB?

[Roland Dreier]

Brian> I would like to know how difficult it would be to modify
Brian> kickstart such that it would work over Infiniband.  I've
Brian> asked the Red Hat anaconda developers about this and, as
Brian> you can see in the attached email, they believe IB only
Brian> accepts netlink and no ioctls for network setup.  Is this
Brian> true?

No, I think RH support is a little confused.  A few ioctls having to
do with hardware addresses (eg SIOCGIFHWADDR) don't work for IB,
because IPoIB hardware addresses are 20 bytes while the ioctl ABI can
only handle 14 bytes.  The practical impact is that ifconfig will not
show the correct HW address for an IPoIB interface.

Other than that, any strictly IP-related ioctls will work fine -- for
example, something like "ifconfig ib0 192.168.1.2" works.

With that said I don't have much experience with kickstart, so I have
no idea if there are any other glitches that you might run into.

 - 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