Re: [openib-general] mthca and DDR not hidden
On Tue, 5 Oct 2004 17:34:32 +0200 Michael S. Tsirkin [EMAIL PROTECTED] wrote: Hello! Quoting r. Sean Hefty ([EMAIL PROTECTED]) Re: [openib-general] mthca and DDR not hidden: Having an allocator routine might force users to perform data copies when sending data. Well, no one is running MPI over MADs - its for setup and management, anyway. I guess I should have been clearer. I was only refering to data copies when sending MADs. Obviously, data sent on other QPs would not be affected. ___ openib-general mailing list [EMAIL PROTECTED] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] mthca and DDR not hidden
Michael Actually saw some mail on lkml the other day about a 64 Michael bit system where memory is fragmented - PCI at 0 and Michael actual memory near -1. Anyway, Tavor is likely not only Michael device with restrictions on maximum region size? Right, that's why there's pci_set_dma_mask() etc. Michael Are you saying consumer shall play with IOMMU? But then Michael PCI addresses of memory will change each time consumer Michael does this and you wont be able to use your default Michael region? Not play with IOMMU but use pci_map_single() etc. The PCI address may change but as long as it is in the low 0x part of memory we're fine. - Roland ___ openib-general mailing list [EMAIL PROTECTED] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] mthca and DDR not hidden
On Tue, Oct 05, 2004 at 05:32:26PM +0200, Michael S. Tsirkin wrote: The argument about IOMMU resources seems to be an argument in favor of letting the consumer handle allocation. Are you saying consumer shall play with IOMMU? Yes, if play with means something above the HCA driver deals with DMA mappings. But then PCI addresses of memory will change each time consumer does this and you wont be able to use your default region? Are regions defined by physical (DMA) or virtual addresses? In any case, a default region implies a long term DMA mapping. Documentation/DMA-mapping.txt is pretty clear that streaming DMA mappings are only intended for transient use - ie map something, do the DMA, then unmap. Coherent DMA mappings are intended to live longer periods but only for control structures like descriptor rings or other shared data. Linux tries to be stingy with DMA mappings because they are a scarce resource on some platforms. hth, grant ___ openib-general mailing list [EMAIL PROTECTED] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] mthca and DDR not hidden
Hello! Quoting r. Sean Hefty ([EMAIL PROTECTED]) Re: [openib-general] mthca and DDR not hidden: On Tue, 5 Oct 2004 17:34:32 +0200 Michael S. Tsirkin [EMAIL PROTECTED] wrote: Hello! Quoting r. Sean Hefty ([EMAIL PROTECTED]) Re: [openib-general] mthca and DDR not hidden: Having an allocator routine might force users to perform data copies when sending data. Well, no one is running MPI over MADs - its for setup and management, anyway. I guess I should have been clearer. I was only refering to data copies when sending MADs. Obviously, data sent on other QPs would not be affected. Right, thats why another copy shouldnt be such a big deal. mst ___ openib-general mailing list [EMAIL PROTECTED] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] Re: ib_mad: Scenarios for returning posted send MADs
On Tue, 05 Oct 2004 09:31:43 -0400 Hal Rosenstock [EMAIL PROTECTED] wrote: Do you mean that you should never get a callback for a mad_send_wr if (rather than unless) it's reference count is at least one ? There will never be a completion callback associated with a mad_send_wr unless its reference count is = 1. Cancelling the MAD decrements the reference count which has the effect of moving the callback one stage ahead. Either the send completion has already occurred in which case the reference count will be 0 or negative and the callback will be invoked immediately or it has not yet occurred so is invoked when the send completion occurs subsequently. The latter case leaves the MAD on both the port and agent send lists until it occurs. There are the other removal scenarios which interplay with this. The reference count for a canceled MAD is only decremented *if there is a timeout specified*. The existence of a timeout value indicates that a response is expected. A mad_send_wr with a timeout has a reference count of 2 initially. It is decremented by one when the send completion callback is invoked. It is decremented if a response matches the request. In order for the request to match, it must still have a timeout value. If a MAD is canceled, its reference count is decremented if a timeout is given. The timeout is set to 0 in this case to prevent responses from matching with the MAD. In any case, what should the MAD layer do when there are posted sends on an agent list ? Should it just dump them and not attempt to make a callback ? The bad side of this is that there are legitimate scenarios where this might occur. Not making the send callback has a number of side effects beyond the individual client (in terms of PCI mapping and memory leakage). Currently, the MAD layer cancels all outstanding sends when the client deregisters, then waits for those sends to complete. The client receives a callback for all sends that it has posted, including those posted when it calls deregister. ___ openib-general mailing list [EMAIL PROTECTED] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] [PATCH] ib_mad.c: Fix request/response matching
Fix endian of high tid so responses are properly matched to requests
Index: access/ib_mad.c
===
--- access/ib_mad.c (revision 923)
+++ access/ib_mad.c (working copy)
@@ -346,7 +346,7 @@
}
mad_send_wr-tid = ((struct ib_mad_hdr*)
- bus_to_virt(cur_send_wr-sg_list-addr))-tid;
+ bus_to_virt(cur_send_wr-sg_list-addr))-tid.id;
mad_send_wr-agent = mad_agent;
mad_send_wr-timeout_ms = cur_send_wr-wr.ud.timeout_ms;
if (mad_send_wr-timeout_ms)
@@ -420,7 +420,7 @@
void ib_coalesce_recv_mad(struct ib_mad_recv_wc *mad_recv_wc,
void *buf)
{
- printk(KERN_ERR ib_coalesce_recv_mad() not implemented as yet\n);
+ printk(KERN_ERR ib_coalesce_recv_mad() not implemented yet\n);
}
EXPORT_SYMBOL(ib_coalesce_recv_mad);
@@ -437,7 +437,7 @@
int ib_process_mad_wc(struct ib_mad_agent *mad_agent,
struct ib_wc *wc)
{
- printk(KERN_ERR ib_process_mad_wc() not implemented as yet\n);
+ printk(KERN_ERR ib_process_mad_wc() not implemented yet\n);
return 0;
}
EXPORT_SYMBOL(ib_process_mad_wc);
@@ -684,7 +684,7 @@
/* Whether MAD was solicited determines type of routing to MAD client
*/
if (solicited) {
/* Routing is based on high 32 bits of transaction ID of MAD */
- hi_tid = mad-mad_hdr.tid 32;
+ hi_tid = be32_to_cpu(mad-mad_hdr.tid.tid_field.hi_tid);
list_for_each_entry(entry, port_priv-agent_list, agent_list) {
if (entry-agent.hi_tid == hi_tid) {
mad_agent = entry;
@@ -693,7 +693,7 @@
}
if (!mad_agent) {
printk(KERN_ERR No client 0x%x for received MAD\n,
- (u32)(mad-mad_hdr.tid 32));
+ hi_tid);
goto ret;
}
} else {
@@ -795,7 +795,7 @@
if (solicited) {
spin_lock_irqsave(mad_agent_priv-send_list_lock, flags);
mad_send_wr = find_send_req(mad_agent_priv,
- recv-mad.mad.mad_hdr.tid);
+ recv-mad.mad.mad_hdr.tid.id);
if (!mad_send_wr) {
spin_unlock_irqrestore(mad_agent_priv-send_list_lock,
flags);
@@ -936,6 +936,11 @@
}
}
+ /*
+* Leave sends with timeouts on the send list
+* until either matching response is received
+* or timeout occurs
+*/
if (--mad_send_wr-refcount 0) {
spin_unlock_irqrestore(mad_agent_priv-send_list_lock, flags);
return;
@@ -1332,6 +1337,7 @@
list_del(port_priv-recv_posted_mad_list[i]);
}
+
INIT_LIST_HEAD(port_priv-recv_posted_mad_list[i]);
port_priv-recv_posted_mad_count[i] = 0;
spin_unlock_irqrestore(port_priv-recv_list_lock, flags);
@@ -1353,6 +1359,7 @@
/* Call completion handler with flushed status !!! */
}
+
INIT_LIST_HEAD(port_priv-send_posted_mad_list);
port_priv-send_posted_mad_count = 0;
spin_unlock_irqrestore(port_priv-send_list_lock, flags);
Index: include/ib_mad.h
===
--- include/ib_mad.h(revision 923)
+++ include/ib_mad.h(working copy)
@@ -69,6 +69,14 @@
union ib_giddgid;
} __attribute__ ((packed));
+union ib_tid {
+ u64 id;
+ struct {
+ u32 hi_tid;
+ u32 lo_tid;
+ } tid_field;
+};
+
struct ib_mad_hdr {
u8 base_version;
u8 mgmt_class;
@@ -76,7 +84,7 @@
u8 method;
u16 status;
u16 class_specific;
- u64 tid;
+ union ib_tid tid;
u16 attr_id;
u16 resv;
u32 attr_mod;
Index: include/ib_smi.h
===
--- include/ib_smi.h(revision 923)
+++ include/ib_smi.h(working copy)
@@ -41,7 +41,7 @@
u16 status;
u8 hop_ptr;
u8 hop_cnt;
- u64 tid;
+ union ib_tid tid;
u16 attr_id;
u16 resv;
u32 attr_mod;
___
openib-general mailing list
[EMAIL PROTECTED]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH] ib_mad.c: Fix request/response matching
+ bus_to_virt(cur_send_wr-sg_list-addr))-tid.id; Didn't notice this before but any use of bus_to_virt() is broken. We need to figure out a different way to do whatever you're trying to do here. - R. ___ openib-general mailing list [EMAIL PROTECTED] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH] ib_mad.c: Fix request/response matching
On Tue, 2004-10-05 at 15:01, Roland Dreier wrote: +bus_to_virt(cur_send_wr-sg_list-addr))-tid.id; Didn't notice this before but any use of bus_to_virt() is broken. We need to figure out a different way to do whatever you're trying to do here. Can you explain why using bus_to_virt() is broken ? The tid of a requests is needed so responses can be matched. One way around this would be to pass the TID as a separate parameter in the ib_post_send_mad call. Maybe there are other less brute force ways. -- Hal ___ openib-general mailing list [EMAIL PROTECTED] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH] ib_mad.c: Fix request/response matching
Hal Can you explain why using bus_to_virt() is broken ? See Documentation/DMA-mapping.txt: It is planned to completely remove virt_to_bus() and bus_to_virt() as they are entirely deprecated. Some ports already do not provide these as it is impossible to correctly support them. (for example ppc64 does not have bus_to_virt). Hal The tid of a requests is needed so responses can be matched. Hal One way around this would be to pass the TID as a separate Hal parameter in the ib_post_send_mad call. Maybe there are other Hal less brute force ways. I don't see a way around adding a TID parameter to ib_post_send_mad or adding a TID member to the ib_send_wr.wr.ud union. - R. ___ openib-general mailing list [EMAIL PROTECTED] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH] ib_mad.c: Fix request/response matching
On Tue, 2004-10-05 at 16:04, Roland Dreier wrote: I don't see a way around adding a TID parameter to ib_post_send_mad or adding a TID member to the ib_send_wr.wr.ud union. Adding another member into the ud union seems better than another parameter for this. I will generate a patch for this soon. -- Hal ___ openib-general mailing list [EMAIL PROTECTED] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
RE: [openib-general] [PATCH] ib_mad.c: Fix request/response matching
Hal The tid of a requests is needed so responses can be matched. Hal One way around this would be to pass the TID as a separate Hal parameter in the ib_post_send_mad call. Maybe there are other Hal less brute force ways. I don't see a way around adding a TID parameter to ib_post_send_mad or adding a TID member to the ib_send_wr.wr.ud union. Are you saying that there's no way to access the MAD data itself from the access layer? RMPP will be extremely difficult to support if that's the case. ___ openib-general mailing list [EMAIL PROTECTED] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
RE: [openib-general] [PATCH] ib_mad.c: Fix request/response matching
On Tue, 2004-10-05 at 16:25, Sean Hefty wrote: Hal The tid of a requests is needed so responses can be matched. Hal One way around this would be to pass the TID as a separate Hal parameter in the ib_post_send_mad call. Maybe there are other Hal less brute force ways. I don't see a way around adding a TID parameter to ib_post_send_mad or adding a TID member to the ib_send_wr.wr.ud union. Are you saying that there's no way to access the MAD data itself from the access layer? RMPP will be extremely difficult to support if that's the case. Good point. We will need more than access to the TID for RMPP. We need a replacement for bus_to_virt. Is there an approved way to get from DMA address to VA ? -- Hal ___ openib-general mailing list [EMAIL PROTECTED] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
RE: [openib-general] [PATCH] ib_mad.c: Fix request/response matching
Fix endian of high tid so responses are properly matched to requests
n the TID is in the MAD and goes on the wire.
Please, do not use CPU endian!
mad_send_wr-tid = ((struct ib_mad_hdr*)
-
bus_to_virt(cur_send_wr-sg_list-addr))-tid;
+ bus_to_virt(cur_send_wr-sg_list-addr))-
tid.id;
A response MAD should have exactly the same TID as what was sent. Not sure
why we aren't matching against the entire TID.
if (solicited) {
/* Routing is based on high 32 bits of transaction ID of MAD
*/
- hi_tid = mad-mad_hdr.tid 32;
+ hi_tid = be32_to_cpu(mad-mad_hdr.tid.tid_field.hi_tid);
This shouldn't be necessary:
Sender of request (system 1):
mad.tid = (mad_agent.hi_tid 32) | user_tid;
send mad
Receiver of response (system 1):
hi_tid = mad.tid 32
The receiver of the request should just return the same TID that it
received.
+ /*
+ * Leave sends with timeouts on the send list
+ * until either matching response is received
+ * or timeout occurs
+ */
FYI - this is about to change in my next patch.
+union ib_tid {
+ u64 id;
+ struct {
+ u32 hi_tid;
+ u32 lo_tid;
+ } tid_field;
+};
+
I don't see why TID can't be u64 everywhere. We shouldn't have to make it a
union.
___
openib-general mailing list
[EMAIL PROTECTED]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH] ib_mad: Fix return posted receive MAD routine
On Tue, 5 Oct 2004 13:42:54 -0700 Sean Hefty [EMAIL PROTECTED] wrote: On Tue, 05 Oct 2004 15:03:12 -0400 Hal Rosenstock [EMAIL PROTECTED] wrote: + rbuf = list_entry(port_priv-recv_posted_mad_list[i], + struct ib_mad_recv_buf, list); + rbuf = (struct ib_mad_recv_buf *)rbuf-list.next; Can we change this, and similar occurrences, to use -next in the list_entry macro call itself? Currently, after the execution of the first statement, rbuf does not reference struct ib_mad_recv_buf. It references the port_priv routine. - Er... structure that is, not routine... too much multitasking on my brain at the moment. ___ openib-general mailing list [EMAIL PROTECTED] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
RE: [openib-general] [PATCH] ib_mad.c: Fix request/response matching
On Tue, 2004-10-05 at 16:34, Sean Hefty wrote:
Fix endian of high tid so responses are properly matched to requests
n the TID is in the MAD and goes on the wire.
Please, do not use CPU endian!
mad_send_wr-tid = ((struct ib_mad_hdr*)
-
bus_to_virt(cur_send_wr-sg_list-addr))-tid;
+ bus_to_virt(cur_send_wr-sg_list-addr))-
tid.id;
A response MAD should have exactly the same TID as what was sent. Not sure
why we aren't matching against the entire TID.
It's only done for comparison purposes (taking the TID off the wire in
network endian and converting to CPU endian);
hi_tid = be32_to_cpu(mad-mad_hdr.tid.tid_field.hi_tid);
list_for_each_entry(entry, port_priv-agent_list,
agent_list) {if (entry-agent.hi_tid == hi_tid)
{
...
if (solicited) {
/* Routing is based on high 32 bits of transaction ID of MAD
*/
-hi_tid = mad-mad_hdr.tid 32;
+hi_tid = be32_to_cpu(mad-mad_hdr.tid.tid_field.hi_tid);
This shouldn't be necessary:
The comparison failed when the code was without the conversion.
Sender of request (system 1):
mad.tid = (mad_agent.hi_tid 32) | user_tid;
send mad
Receiver of response (system 1):
hi_tid = mad.tid 32
The receiver of the request should just return the same TID that it
received.
It does.
+/*
+ * Leave sends with timeouts on the send list
+ * until either matching response is received
+ * or timeout occurs
+ */
FYI - this is about to change in my next patch.
+union ib_tid {
+u64 id;
+struct {
+u32 hi_tid;
+u32 lo_tid;
+} tid_field;
+};
+
I don't see why TID can't be u64 everywhere. We shouldn't have to make it a
union.
-- Hal
___
openib-general mailing list
[EMAIL PROTECTED]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH] ib_mad.c: Fix request/response matching
Hal Good point. We will need more than access to the TID for Hal RMPP. We need a replacement for bus_to_virt. Is there an Hal approved way to get from DMA address to VA ? No, you just need to save off the VA if you need to use it later. So maybe we need to add a pointer to the MAD header in ib_send_wr.wr.ud. - Roland ___ openib-general mailing list [EMAIL PROTECTED] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH] ib_mad.c: Fix request/response matching
On Tue, 05 Oct 2004 16:57:58 -0400 Hal Rosenstock [EMAIL PROTECTED] wrote: mad_send_wr-tid = ((struct ib_mad_hdr*) - bus_to_virt(cur_send_wr-sg_list-addr))-tid; + bus_to_virt(cur_send_wr-sg_list-addr))- tid.id; A response MAD should have exactly the same TID as what was sent. Not sure why we aren't matching against the entire TID. It's only done for comparison purposes (taking the TID off the wire in network endian and converting to CPU endian); The sender of the request should be able to set the TID to whatever value it wants. The responder should just echo that TID. I don't understand why byte-swapping is needed at all on the TID. - hi_tid = mad-mad_hdr.tid 32; + hi_tid = be32_to_cpu(mad-mad_hdr.tid.tid_field.hi_tid); This shouldn't be necessary: The comparison failed when the code was without the conversion. Why did the comparison fail? Was the client setting the upper 32-bits of the TID correctly, or was the client swapping the bits when setting it? ___ openib-general mailing list [EMAIL PROTECTED] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH] ib_mad.c: Fix request/response matching
On Tue, 05 Oct 2004 13:59:37 -0700 Roland Dreier [EMAIL PROTECTED] wrote: Hal Good point. We will need more than access to the TID for Hal RMPP. We need a replacement for bus_to_virt. Is there an Hal approved way to get from DMA address to VA ? No, you just need to save off the VA if you need to use it later. So maybe we need to add a pointer to the MAD header in ib_send_wr.wr.ud. Would we need multiple VAs if scatter-gather is used by the client? ___ openib-general mailing list [EMAIL PROTECTED] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH] ib_mad.c: Fix request/response matching
Sean Would we need multiple VAs if scatter-gather is used by the client? Yep. Or we could just say that all the fields the access layer needs to look at must be in the first s/g entry. - R. ___ openib-general mailing list [EMAIL PROTECTED] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH] ib_mad.c: Fix request/response matching
On Tue, 05 Oct 2004 14:06:13 -0700 Roland Dreier [EMAIL PROTECTED] wrote: Sean Would we need multiple VAs if scatter-gather is used by the client? Yep. Or we could just say that all the fields the access layer needs to look at must be in the first s/g entry. You're right, and thinking about it more, we'd probably want that anyway. ___ openib-general mailing list [EMAIL PROTECTED] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] [PATCH] ib_smi: First working version of SMI/SMA
ib_smi: First working version of SMI/SMA (port gets to active)
There is a workaround for the hop pointer in the response which I will
work on tomorrow.
Index: ib_smi.c
===
--- ib_smi.c(revision 923)
+++ ib_smi.c(working copy)
@@ -24,13 +24,24 @@
*/
#include ib_smi.h
+#include ib_smi_priv.h
#include ib_mad_priv.h
+
+MODULE_LICENSE(Dual BSD/GPL);
+MODULE_DESCRIPTION(kernel IB SMI);
+MODULE_AUTHOR(Sean Hefty);
+MODULE_AUTHOR(Hal Rosenstock);
+
+
+static spinlock_t ib_smi_port_list_lock = SPIN_LOCK_UNLOCKED;
+static struct list_head ib_smi_port_list;
+
/*
* Fixup a directed route SMP for sending. Return 0 if the SMP should
be
* discarded.
*/
-static int smi_handle_dr_smp_send(struct ib_mad_port_private
*port_priv,
+static int smi_handle_dr_smp_send(struct ib_mad_agent *mad_agent,
struct ib_smp *smp)
{
u8 hop_ptr, hop_cnt;
@@ -44,25 +55,25 @@
if (hop_cnt hop_ptr == 0) {
smp-hop_ptr++;
return (smp-initial_path[smp-hop_ptr] ==
- port_priv-port_num);
+ mad_agent-port_num);
}
/* C14-9:2 */
if (hop_ptr hop_ptr hop_cnt) {
- if (port_priv-device-node_type != IB_NODE_SWITCH)
+ if (mad_agent-device-node_type != IB_NODE_SWITCH)
return 0;
/* smp-return_path set when received */
smp-hop_ptr++;
return (smp-initial_path[smp-hop_ptr] ==
- port_priv-port_num);
+ mad_agent-port_num);
}
/* C14-9:3 -- We're at the end of the DR segment of path */
if (hop_ptr == hop_cnt) {
/* smp-return_path set when received */
smp-hop_ptr++;
- return (port_priv-device-node_type != IB_NODE_CA ||
+ return (mad_agent-device-node_type != IB_NODE_CA ||
smp-dr_dlid == IB_LID_PERMISSIVE);
}
@@ -75,24 +86,24 @@
if (hop_cnt hop_ptr == hop_cnt + 1) {
smp-hop_ptr--;
return (smp-return_path[smp-hop_ptr] ==
- port_priv-port_num);
+ mad_agent-port_num);
}
/* C14-13:2 */
if (2 = hop_ptr hop_ptr = hop_cnt) {
- if (port_priv-device-node_type != IB_NODE_SWITCH)
+ if (mad_agent-device-node_type != IB_NODE_SWITCH)
return 0;
smp-hop_ptr--;
return (smp-return_path[smp-hop_ptr] ==
- port_priv-port_num);
+ mad_agent-port_num);
}
/* C14-13:3 -- at the end of the DR segment of path */
if (hop_ptr == 1) {
smp-hop_ptr--;
/* C14-13:3 -- SMPs destined for SM shouldn't be here */
- return (port_priv-device-node_type == IB_NODE_SWITCH
+ return (mad_agent-device-node_type == IB_NODE_SWITCH
smp-dr_slid != IB_LID_PERMISSIVE);
}
@@ -106,13 +117,13 @@
* Sender side handling of outgoing SMPs. Fixup the SMP as required by
* the spec. Return 0 if the SMP should be dropped.
*/
-static int smi_handle_smp_send(struct ib_mad_port_private *port_priv,
+static int smi_handle_smp_send(struct ib_mad_agent *mad_agent,
struct ib_smp *smp)
{
switch (smp-mgmt_class)
{
case IB_MGMT_CLASS_SUBN_DIRECTED_ROUTE:
- return smi_handle_dr_smp_send(port_priv, smp);
+ return smi_handle_dr_smp_send(mad_agent, smp);
default:
return 0; /* write me... */
}
@@ -121,12 +132,12 @@
/*
* Return 1 if the SMP should be handled by the local SMA via
process_mad.
*/
-static inline int smi_check_local_smp(struct ib_mad_port_private
*port_priv,
+static inline int smi_check_local_smp(struct ib_mad_agent *mad_agent,
struct ib_smp *smp)
{
/* C14-9:3 -- We're at the end of the DR segment of path */
/* C14-9:4 -- Hop Pointer = Hop Count + 1 - give to SMA/SM. */
- return (port_priv-device-process_mad
+ return (mad_agent-device-process_mad
!ib_get_smp_direction(smp)
(smp-hop_ptr == smp-hop_cnt + 1));
}
@@ -135,7 +146,7 @@
* Adjust information for a received SMP. Return 0 if the SMP should
be
* dropped.
*/
-static int
[openib-general] [ANNOUNCEMENT]: MAD layer with SMI/SMA Pre Release
All the bits for the MAD layer with SMI/SMA are now in the openib-candidate branch. The OpenIB access layer is comprised of the MAD layer and the SMI/SMA. These are currently implemented as separate modules. These are layered on top of the mthca driver and cannot run currently with the MAD layer from the roland_merge branch. These directions are how to combine the two for building and running. Note also that the stack currently ends here (e.g. don't expect to run IPoIB right now, although we are heading to this; especially don't expect to run SRP or SDP or u/kDAPL right now either). There is a README in src/linux-kernel/infiniband/access which also contains building and using instructions. There are a number of things I would like to do before formally announcing it but for anyone who is adventurous: Run through install and build process from scratch. Test GSI sending and matching now that port is active. Other Pending Items: Add virtual address to the ud parameter in ib_mad_send. There is a workaround on the hop pointer in ib_smi.c which needs a real fix. Investigate TID endian. Redo MAD completion handler error handling. Trim method mask used in ib_smi.c Undo commenting out of ib_mad_send in mthca_mad.c I will knock some of these off by early tomorrow. -- Hal ___ openib-general mailing list [EMAIL PROTECTED] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
