linux 3.8.6 and srp backports
Hello. Some times ago, when i'm use kernel 3.6 i'm use https://github.com/bvanassche/ib_srp-backport/ for srp drivers on my linux server. Now i'm using 3.8.6, does i need something from https://github.com/bvanassche/ib_srp-backport/ or all patches already applied in upstream? -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru jabber: v...@selfip.ru -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux 3.8.6 and srp backports
On 04/08/13 10:00, Vasiliy Tolstov wrote: Hello. Some times ago, when i'm use kernel 3.6 i'm use https://github.com/bvanassche/ib_srp-backport/ for srp drivers on my linux server. Now i'm using 3.8.6, does i need something from https://github.com/bvanassche/ib_srp-backport/ or all patches already applied in upstream? Unfortunately not all patches present in the ib_srp-backport project are already upstream. If you want to avoid that in a multipath setup sooner or later failover or failback fails with a SCSI device in the offline state you will still need the ib_srp-backport project. I'm currently working on converting that project into a new patch series intended for inclusion in the mainline kernel. Bart. -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux 3.8.6 and srp backports
2013/4/8 Bart Van Assche bvanass...@acm.org: Unfortunately not all patches present in the ib_srp-backport project are already upstream. If you want to avoid that in a multipath setup sooner or later failover or failback fails with a SCSI device in the offline state you will still need the ib_srp-backport project. I'm currently working on converting that project into a new patch series intended for inclusion in the mainline kernel. Thanks. I'm already check and approve that i need you github branch =). Thanks for great work! -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru jabber: v...@selfip.ru -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH opensm] osm_sa_mcmember_record.c: Improve debug log message in validate_modify
to include subnet prefix and not just GUID and display GID in IPv6 format
Signed-off-by: Hal Rosenstock h...@mellanox.com
---
diff --git a/opensm/osm_sa_mcmember_record.c b/opensm/osm_sa_mcmember_record.c
index 4a9ad71..0857a66 100644
--- a/opensm/osm_sa_mcmember_record.c
+++ b/opensm/osm_sa_mcmember_record.c
@@ -406,11 +406,19 @@ static boolean_t validate_modify(IN osm_sa_t * sa, IN
osm_mgrp_t * p_mgrp,
request_gid.unicast.interface_id ||
(*pp_mcm_alias_guid)-port_gid.unicast.prefix !=
request_gid.unicast.prefix) {
+ ib_gid_t base_port_gid;
+ char gid_str[INET6_ADDRSTRLEN];
+ char gid_str2[INET6_ADDRSTRLEN];
+
+ base_port_gid.unicast.prefix =
(*pp_mcm_alias_guid)-port_gid.unicast.prefix;
+ base_port_gid.unicast.interface_id =
(*pp_mcm_alias_guid)-p_base_mcm_port-port-guid;
OSM_LOG(sa-p_log, OSM_LOG_DEBUG,
No ProxyJoin but different ports: stored:
- 0x%016 PRIx64 request:0x%016 PRIx64 \n,
-
cl_ntoh64((*pp_mcm_alias_guid)-p_base_mcm_port-port-guid),
- cl_ntoh64(request_gid.unicast.interface_id));
+ %s request:%s\n,
+ inet_ntop(AF_INET6, base_port_gid.raw, gid_str,
+ sizeof gid_str),
+ inet_ntop(AF_INET6, request_gid.raw, gid_str2,
+ sizeof gid_str2));
return FALSE;
}
} else {
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH opensm] osm_sa_mcmember_record.c: On join and leave, validate subnet prefix in port GID
Signed-off-by: Hal Rosenstock h...@mellanox.com
---
diff --git a/opensm/osm_sa_mcmember_record.c b/opensm/osm_sa_mcmember_record.c
index 4a9ad71..242fcde 100644
--- a/opensm/osm_sa_mcmember_record.c
+++ b/opensm/osm_sa_mcmember_record.c
@@ -911,6 +919,18 @@ static void mcmr_rcv_leave_mgrp(IN osm_sa_t * sa, IN
osm_madw_t * p_madw)
mcmember_rec = *p_recvd_mcmember_rec;
+ /* Validate the subnet prefix in the PortGID */
+ if (p_recvd_mcmember_rec-port_gid.unicast.prefix !=
+ sa-p_subn-opt.subnet_prefix) {
+ OSM_LOG(sa-p_log, OSM_LOG_DEBUG,
+ PortGID subnet prefix 0x% PRIx64
+does not match configured prefix 0x% PRIx64 \n,
+
cl_ntoh64(p_recvd_mcmember_rec-port_gid.unicast.prefix),
+ cl_ntoh64(sa-p_subn-opt.subnet_prefix));
+ osm_sa_send_error(sa, p_madw, IB_SA_MAD_STATUS_INVALID_GID);
+ goto Exit;
+ }
+
if (OSM_LOG_IS_ACTIVE_V2(sa-p_log, OSM_LOG_DEBUG)) {
osm_physp_t *p_req_physp;
@@ -998,6 +1018,18 @@ static void mcmr_rcv_join_mgrp(IN osm_sa_t * sa, IN
osm_madw_t * p_madw)
mcmember_rec = *p_recvd_mcmember_rec;
+/* Validate the subnet prefix in the PortGID */
+ if (p_recvd_mcmember_rec-port_gid.unicast.prefix !=
+ sa-p_subn-opt.subnet_prefix) {
+ OSM_LOG(sa-p_log, OSM_LOG_DEBUG,
+ PortGID subnet prefix 0x% PRIx64
+does not match configured prefix 0x% PRIx64 \n,
+
cl_ntoh64(p_recvd_mcmember_rec-port_gid.unicast.prefix),
+ cl_ntoh64(sa-p_subn-opt.subnet_prefix));
+ osm_sa_send_error(sa, p_madw, IB_SA_MAD_STATUS_INVALID_GID);
+ goto Exit;
+ }
+
if (OSM_LOG_IS_ACTIVE_V2(sa-p_log, OSM_LOG_DEBUG)) {
osm_physp_t *p_req_physp;
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH opensm] osm_log.c: Remove unnecessary initialization in osm_log
Signed-off-by: Hal Rosenstock h...@mellanox.com --- diff --git a/opensm/osm_log.c b/opensm/osm_log.c index 327a89a..3460cc5 100644 --- a/opensm/osm_log.c +++ b/opensm/osm_log.c @@ -119,7 +119,7 @@ void osm_log(IN osm_log_t * p_log, IN osm_log_level_t verbosity, SYSTEMTIME st; uint32_t pid = GetCurrentThreadId(); #else - pid_t pid = 0; + pid_t pid; time_t tim; struct tm result; uint64_t time_usecs; -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] IB/mlx4: Fail post send command on error recovery
On 04/04/2013 06:45 PM, Or Gerlitz wrote: Kleber , as for the 1st problem, which kernel consumers are hanging for ever on their CQs? IPoIB is giving up after sometime e.g see in ipoib_ib.c assume the HW is wedged and just free up all our pending work requests Or, I don't have a very comprehensive testcase to stress most part of the IB stack during error recovery, but during my tests the kernel consumer that are still hanging is the ib_sa module, mcast_remove_one() is waiting for the port completion queue: INFO: task eehd:4689 blocked for more than 30 seconds. echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. eehdD 0 4689 2 0x0001 Call Trace: [c000fba83190] [0001] 0x1 (unreliable) [c000fba83360] [c0016188] .__switch_to+0x140/0x268 [c000fba83410] [c0674f28] .__schedule+0x570/0x8f0 [c000fba836b0] [c0675bc4] .schedule_timeout+0x334/0x3c8 [c000fba837c0] [c0674738] .wait_for_common+0x1c0/0x238 [c000fba838a0] [d2ca230c] .mcast_remove_one+0xfc/0x168 [ib_sa] [c000fba83940] [d2bc4f60] .ib_unregister_device+0x78/0x170 [ib_core] ... Or rdma_cm waiting for the cma_dev completion: Call Trace: [c000f8fc70f0] [0001] 0x1 (unreliable) [c000f8fc72c0] [c0016188] .__switch_to+0x140/0x268 [c000f8fc7370] [c0674f28] .__schedule+0x570/0x8f0 [c000f8fc7610] [c0675bc4] .schedule_timeout+0x334/0x3c8 [c000f8fc7720] [c0674738] .wait_for_common+0x1c0/0x238 [c000f8fc7800] [d2f835b0] .cma_process_remove+0x170/0x1a8 [rdma_cm] [c000f8fc78b0] [d2f8366c] .cma_remove_one+0x84/0xb0 [rdma_cm] [c000f8fc7940] [d2c34f60] .ib_unregister_device+0x78/0x170 [ib_core] ... Thanks, kleber -- Kleber Sacilotto de Souza IBM Linux Technology Center -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] IB/mlx4: Fail post send command on error recovery
On 04/04/2013 06:49 PM, Roland Dreier wrote: I don't know so much about this PCI error recovery stuff but it does seem sensible to trigger a catastrophic error async event when it happens (I'm assuming the recovery mechanism resets the adapter). The PCI error recovery in the powerpc architecture, which is where I'm focusing, works by identifying a misbehaving adapter and freezing its slot, so that all MMIO writes to that device will be ignored and reads will return all 1's. When that happens the Linux implementation will invoke some callbacks on the driver (in this case mlx4_core) to recover from the error, and reset the slot. The most common procedure is the driver to remove the adapter and add it back, which is what the mlx4_ib is trying to do. Then we should fix at least kernel ULPs behave appropriately when they get such an async event. And similarly if someone wants to harden some subset of userspace apps to handle PCI error recovery too, that would be another step forward. I agree, this seems to be what is missing to have the error recovery fully functional. Thanks, -- Kleber Sacilotto de Souza IBM Linux Technology Center -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] IB/mlx4: Fail post send command on error recovery
On Mon, Apr 8, 2013 at 4:51 PM, Kleber Sacilotto de Souza kleb...@linux.vnet.ibm.com wrote: Or, I don't have a very comprehensive testcase to stress most part of the IB stack during error recovery, but during my tests the kernel consumer that are still hanging is the ib_sa module, mcast_remove_one() is waiting for the port completion queue: best if you can send the whole relevant picture, e.g use the sysrq t dump when things are hanged and send the stack trace of all (or all involved) kernel-threads/processes Or. -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH v2] IPoIB: Leave space in skb linear buffer for IP headers
On Fri, Apr 5, 2013 at 1:44 PM, Roland Dreier rol...@kernel.org wrote: Thanks. I guess I'll have to set up a testbed and debug this myself. I'll try to work on that this weekend. So I was able to reproduce the problem (or at least a problem) with netpipe. Doing NPtcp -i -2 hit bad data pretty quickly (where the receiver didn't get the same data as the sender sent). It turns out that the problem is with packets that don't go into the fragment page ... with my patch applied, ipoib sends skbs up the stack that have an empty page in the fragment list, and this apparently messes something up in the TCP/IP code. I have a hacky version that clears the frag list if the page isn't used, and that seems to work fine. However I want to clean it up; I should have a good version later today. - R. -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH v2] IPoIB: Leave space in skb linear buffer for IP headers
On Mon, Apr 8, 2013 at 9:44 AM, Eric Dumazet eduma...@google.com wrote: Am empty page in the frag list ? You mean a frag with a zero length ? Yep... the code would do skb_fill_page_desc(skb, 0, page, 0, PAGE_SIZE); but then later on it did the equivalent of skb_frag_size_set(frag, 0); skb-truesize += PAGE_SIZE; and somehow when data is flowing both directions with small packets, that would lead the RX-side handling to return corrupt data to userspace. Not sure if it's worth figuring this out entirely ... the more efficient way for ipoib to do things is to reuse that page for next time, not pass it up the stack unused. - R. -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH v2] IPoIB: Leave space in skb linear buffer for IP headers
Am 08.04.13 18:50 schrieb Roland Dreier unter rol...@kernel.org: On Mon, Apr 8, 2013 at 9:44 AM, Eric Dumazet eduma...@google.com wrote: Am empty page in the frag list ? You mean a frag with a zero length ? Yep... the code would do skb_fill_page_desc(skb, 0, page, 0, PAGE_SIZE); but then later on it did the equivalent of skb_frag_size_set(frag, 0); skb-truesize += PAGE_SIZE; and somehow when data is flowing both directions with small packets, that would lead the RX-side handling to return corrupt data to userspace. Not sure if it's worth figuring this out entirely ... the more efficient way for ipoib to do things is to reuse that page for next time, not pass it up the stack unused. - R. First I thought perfect memory allocation inside ipoib_alloc_rx_skb() could be realized by passing the received packet size from function ipoib_ib_handle_rx_wc(). But I'm unable to estimate the requirements of the similar call inside ipoib_ib_post_receives(). Nevertheless thank you very much for spending time on this. Markus -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH v3] IPoIB: Leave space in skb linear buffer for IP headers
From: Roland Dreier rol...@purestorage.com
Markus Stockhausen markus.stockhau...@gmx.de noticed that IPoIB was
spending significant time doing memcpy() in __pskb_pull_tail(). He
found that this is because his adapter reports a maximum MTU of 4K,
which causes IPoIB datagram mode to receive all the actual data in a
separate page in the fragment list.
We're already allocating extra tailroom for the skb linear part, so we
might as well use it.
Cc: Eric Dumazet eduma...@google.com
Reported-by: Markus Stockhausen markus.stockhau...@gmx.de
Signed-off-by: Roland Dreier rol...@purestorage.com
---
v3: avoid adding pages to the frag list with no data in them
drivers/infiniband/ulp/ipoib/ipoib.h| 4 +-
drivers/infiniband/ulp/ipoib/ipoib_ib.c | 77 +++--
2 files changed, 47 insertions(+), 34 deletions(-)
diff --git a/drivers/infiniband/ulp/ipoib/ipoib.h
b/drivers/infiniband/ulp/ipoib/ipoib.h
index eb71aaa..5f0d34c 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib.h
+++ b/drivers/infiniband/ulp/ipoib/ipoib.h
@@ -64,7 +64,8 @@ enum ipoib_flush_level {
enum {
IPOIB_ENCAP_LEN = 4,
- IPOIB_UD_HEAD_SIZE= IB_GRH_BYTES + IPOIB_ENCAP_LEN,
+ /* add 128 bytes of tailroom for IP/TCP headers */
+ IPOIB_UD_HEAD_SIZE= IB_GRH_BYTES + IPOIB_ENCAP_LEN + 128,
IPOIB_UD_RX_SG= 2, /* max buffer needed for 4K mtu */
IPOIB_CM_MTU = 0x1 - 0x10, /* padding to align header
to 16 */
@@ -155,6 +156,7 @@ struct ipoib_mcast {
struct ipoib_rx_buf {
struct sk_buff *skb;
+ struct page*page;
u64 mapping[IPOIB_UD_RX_SG];
};
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_ib.c
b/drivers/infiniband/ulp/ipoib/ipoib_ib.c
index 2cfa76f..890e2c8 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_ib.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_ib.c
@@ -92,13 +92,15 @@ void ipoib_free_ah(struct kref *kref)
}
static void ipoib_ud_dma_unmap_rx(struct ipoib_dev_priv *priv,
+ struct page *page,
u64 mapping[IPOIB_UD_RX_SG])
{
if (ipoib_ud_need_sg(priv-max_ib_mtu)) {
ib_dma_unmap_single(priv-ca, mapping[0], IPOIB_UD_HEAD_SIZE,
DMA_FROM_DEVICE);
- ib_dma_unmap_page(priv-ca, mapping[1], PAGE_SIZE,
- DMA_FROM_DEVICE);
+ if (page)
+ ib_dma_unmap_page(priv-ca, mapping[1], PAGE_SIZE,
+ DMA_FROM_DEVICE);
} else
ib_dma_unmap_single(priv-ca, mapping[0],
IPOIB_UD_BUF_SIZE(priv-max_ib_mtu),
@@ -107,23 +109,18 @@ static void ipoib_ud_dma_unmap_rx(struct ipoib_dev_priv
*priv,
static void ipoib_ud_skb_put_frags(struct ipoib_dev_priv *priv,
struct sk_buff *skb,
+ struct page *page,
unsigned int length)
{
- if (ipoib_ud_need_sg(priv-max_ib_mtu)) {
- skb_frag_t *frag = skb_shinfo(skb)-frags[0];
- unsigned int size;
+ if (ipoib_ud_need_sg(priv-max_ib_mtu)
+ length IPOIB_UD_HEAD_SIZE) {
/*
-* There is only two buffers needed for max_payload = 4K,
+* There are only two buffers needed for max_payload = 4K,
* first buf size is IPOIB_UD_HEAD_SIZE
*/
- skb-tail += IPOIB_UD_HEAD_SIZE;
- skb-len += length;
-
- size = length - IPOIB_UD_HEAD_SIZE;
-
- skb_frag_size_set(frag, size);
- skb-data_len += size;
- skb-truesize += PAGE_SIZE;
+ skb_put(skb, IPOIB_UD_HEAD_SIZE);
+ skb_add_rx_frag(skb, 0, page, 0,
+ length - IPOIB_UD_HEAD_SIZE, PAGE_SIZE);
} else
skb_put(skb, length);
@@ -143,9 +140,11 @@ static int ipoib_ib_post_receive(struct net_device *dev,
int id)
ret = ib_post_recv(priv-qp, priv-rx_wr, bad_wr);
if (unlikely(ret)) {
ipoib_warn(priv, receive failed for buf %d (%d)\n, id, ret);
- ipoib_ud_dma_unmap_rx(priv, priv-rx_ring[id].mapping);
+ ipoib_ud_dma_unmap_rx(priv, priv-rx_ring[id].page,
priv-rx_ring[id].mapping);
dev_kfree_skb_any(priv-rx_ring[id].skb);
priv-rx_ring[id].skb = NULL;
+ put_page(priv-rx_ring[id].page);
+ priv-rx_ring[id].page = NULL;
}
return ret;
@@ -156,18 +155,13 @@ static struct sk_buff *ipoib_alloc_rx_skb(struct
net_device *dev, int id)
struct ipoib_dev_priv *priv = netdev_priv(dev);
struct sk_buff *skb;
int buf_size;
- int tailroom;
u64 *mapping;
+ struct page **page;
- if
Re: [PATCH 1/4] Add IBV_*_USNIC enums for the Cisco Ethernet Virtual NIC.
On Apr 5, 2013, at 4:40 PM, Roland Dreier rol...@purestorage.com wrote: I think the idea is that without context, it's hard to know if adding these enums makes sense or not. And I'm sorry but I'm not that sympathetic to my code isn't ready but you have to take this out-of-context patch so I can meet Red Hat's arbitrary schedule. Ok, fair enough. It'll be a few weeks before we can submit usnic.ko, so I'll re-bring up the IBV_NODE_VENDOR/related patches then. I think the MTU discussion is still relevant, however -- there seems to be a larger design issue there. I'll go reply separately on that thread. -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Ad IB_MTU_1500|9000 enums.
On Apr 4, 2013, at 1:57 PM, Weiny, Ira ira.we...@intel.com wrote: In hindsight, the user space API never should have exposed the mtu as an enum... Since an enum is an int, and we're never going to have anything with an mtu = 5 bytes, couldn't we just store all new mtu values directly as their byte value? That seems like a pretty good idea. Agreed, but changing to an int would seem to have some fairly serious backwards compatibility issues. What is the right way to move forward here? Just to re-state: our issue is that there does not seem to be any other way to get the max UD message size without knowing the actual MTU (are we incorrect about that?). Hence, using the IB-defined values is not really sufficient. -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] Use autoreconf in autogen.sh
Roland -- If there are no objections, can this patch (and patch 4 of this set: https://patchwork.kernel.org/patch/2387321/) be committed? Neither should not have any real impact other than the modernization of the libibverbs build system. On Apr 3, 2013, at 9:06 AM, Jeff Squyres jsquy...@cisco.com wrote: The old sequence of Autotools commands listed in autogen.sh is no longer correct. Instead, just use the single autoreconf command, which will invoke all the Right Autotools commands in the correct order. --- autogen.sh | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/autogen.sh b/autogen.sh index fd47839..6c9233e 100755 --- a/autogen.sh +++ b/autogen.sh @@ -1,8 +1,4 @@ #! /bin/sh set -x -aclocal -I config -libtoolize --force --copy -autoheader -automake --foreign --add-missing --copy -autoconf +autoreconf -ifv -I config -- 1.8.1.1 -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH v2] IPoIB: Leave space in skb linear buffer for IP headers
On Mon, Apr 8, 2013 at 12:03 PM, Markus Stockhausen markus.stockhau...@gmx.de wrote: First I thought perfect memory allocation inside ipoib_alloc_rx_skb() could be realized by passing the received packet size from function ipoib_ib_handle_rx_wc(). But I'm unable to estimate the requirements of the similar call inside ipoib_ib_post_receives(). The problem is that we have to allocate the receive buffer before we know how big the packet we're going to receive is. Anyway, see my latest patch. I'm pretty sure it should work -- and I hope the performance is reasonable. Your approach of hacking the max mtu avoids the fragmented skb completely, whereas I'm just making sure the TCP/IP headers are in the linear part. - R. -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] Ad IB_MTU_1500|9000 enums.
Agreed, but changing to an int would seem to have some fairly serious backwards compatibility issues. Why can't IB_MTU_1500 = 1500? -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] Use autoreconf in autogen.sh
On 09/04/2013 00:59, Jeff Squyres (jsquyres) wrote: Roland -- If there are no objections, can this patch (and patch 4 of this set: https://patchwork.kernel.org/patch/2387321/) be committed? Neither should not have any real impact other than the modernization of the libibverbs build system. Jeff, the patches don't carry signed-of-by signature line... I would suggest you resubmit patches 3 and 4 with a signature Or. -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
