Skip to contentSkip to conversation

InfiniBand/RDMA merge plans for 2.6.27

DISCUSSION Roland Dreier 6 participants 12 messages Jul 14, 2008 – Jul 17, 2008 1 message not in the archive

Subsystems (5)
lore
Share & tools
lore
#0 lore raw

I've been a little lazy about writing this, and 2.6.26 is already out, so it's time to review what my plans are for the merge window opens.

I have to say that I've been somewhat disappointed with the quality of things this cycle. Maybe I've just been in a tetchy mood these days, but before you send me an email saying, "this is ready to go, when are you going to merge it," please try doing some of the following;

- Run your patch through checkpatch.pl so I don't have to nag you to fix trivial issues (or spend time fixing them myself).

- Read your patch over so I don't see a memory leak or deadlock as soon as I look at it.

- Build your patch with sparse checking ("C=2 CF=-D__CHECK_ENDIAN__") and make sure it doesn't introduce new warnings. (A big bonus in goodwill for sending patches that fix old warnings)

- Test your patch on a kernel with things like slab debugging and lockdep turned on.

And while you're waiting for me to get to your patch, I sure wouldn't mind if you read and commented on someone else's patch. None of this means you shouldn't remind me about pending patches, since I often lose track of things and drop them accidentally.

Anyway, here are all the pending things that I'm aware of. As usual, if something isn't already in my tree and isn't listed below, I probably missed it or dropped it by mistake. Please remind me again in that case.

Core:

- I'm waiting to merge the RDMA_CM_EVENT_ADDR_CHANGE changes that depend on core networking changes until such changes are upstream. Or, please remind me when that happens.

- Jack's XRC patch set. I think we're getting closer to converging here, and I hope to get this merged but we're getting down to the wire, so we'll see.

ULPs:

- I merged a decent amount of stuff for IPoIB, including LRO, "loopback blocking," and better handling of fabric events, and I don't think I have anything pending.

HW specific:

- Yevgeny's mlx4 changes. We'll see how much time is left after I get done with XRC (which is before this on my list) but to be honest I'm not sure how mergeable a lot of this is without the mlx4_en patches that actually use it.

- I've been working on memory management extensions support for mlx4, but I'm not sure if it will be ready in time. Firmware for this may not be released for a while so it ain't urgent anyway.

Here are a few topics that I believe will not be ready in time for the 2.6.27 window and will need to wait for 2.6.28 at least:

- Remove LLTX from IPoIB. I haven't had time to finish this yet, so I guess it will probably wait for 2.6.28 now...

- Multiple CQ event vector support. No one has convinced me that we know how ULPs or userspace apps should decide which vector to use, and hence little progress has been made since we deferred this during the 2.6.23 merge window.

Here all the patches I already have in my for-2.6.27 branch:

Christophe Jaillet (1):
RDMA/nes: Remove unnecessary memset()

Dotan Barak (1):
RDMA: Improve include file coding style

Eli Cohen (12):
IB/mlx4: Optimize QP stamping
IPoIB: Copy small received SKBs in connected mode
IB/mlx4: Configure QPs' max message size based on real device capability IB/mlx4: Pass congestion management class MADs to the HCA
IPoIB: Remove unused IPOIB_MCAST_STARTED code
IPoIB: Remove priv->mcast_mutex
IPoIB: Only set Q_Key once: after joining broadcast group
IPoIB: Use rtnl lock/unlock when changing device flags
IPoIB: Use dev_set_mtu() to change mtu
IPoIB/cm: Reduce connected mode TX object size
IPoIB: Double default RX/TX ring sizes
IB/mlx4: Use kzalloc() for new QPs so flags are initialized to 0

Joachim Fenkes (2):
IB/ehca: Reject receive work requests if QP is in RESET state IB/ehca: Make device table externally visible

Jon Mason (1):
RDMA/cxgb3: Propagate HW page size capabilities

Moni Shoua (2):
IB/sa: Fail requests made while creating new SM AH
IPoIB: Refresh paths instead of flushing them on SM change events

Or Gerlitz (2):
RDMA/addr: Keep pointer to netdevice in struct rdma_dev_addr RDMA/cma: Simplify locking needed for serialization of callbacks

Ralph Campbell (2):
IB/core: Reset to error QP state transition is not allowed IB/ipath: Use IEEE OUI for vendor_id reported by ibv_query_device()

Robert P. J. Day (1):
IB/ipath: Simplify code using ARRAY_SIZE() macro

Roland Dreier (13):
IB/srp: Remove use of cached P_Key/GID queries
RDMA: Remove subversion $Id tags
IB/mthca: Remove extra code for RESET->ERR QP state transition IB/mlx4: Remove extra code for RESET->ERR QP state transition RDMA/cxgb3: Remove write-only iwch_rnic_attributes fields RDMA/cma: Add missing newlines to printk()s
IPoIB/cm: Fix racy use of receive WR/SGL in ipoib_cm_post_receive_nonsrq() RDMA/nes: Encapsulate logic nes_put_cqp_request()
RDMA/nes: Get rid of ring_doorbell parameter of nes_post_cqp_request()
IPoIB: Get rid of ipoib_mcast_detach() wrapper
IB/mthca: Remove "stop" flag for catastrophic error polling timer IB/mthca: Use round_jiffies() for catastrophic error polling timer IB/mthca: Fix check of max_send_sge for special QPs

Ron Livne (3):
IB/core: Add support for multicast loopback blocking IB/mlx4: Add support for blocking multicast loopback packets
IPoIB: Use multicast loopback blocking if available

Sean Hefty (1):
RDMA: Fix license text

Stefan Roscher (1):
IB/ehca: In case of lost interrupts, trigger EOI to reenable interrupts

Steve Wise (8):
RDMA/core: Add memory management extensions support RDMA/cxgb3: MEM_MGT_EXTENSIONS support
RDMA/cxgb3: Fix up some ib_device_attr fields
RDMA/core: Add iWARP protocol statistics attributes in sysfs RDMA/cxgb3: Add support for protocol statistics RDMA/cxgb3: Set rkey field for new memory windows in iwch_alloc_mw() RDMA/core: Add local DMA L_Key support
RDMA/cxgb3: Fixes for zero STag

Vladimir Sokolovsky (2):
IPoIB: add LRO support
mlx4_core: Use MOD_STAT_CFG command to get minimal page size

#1 lore raw

Re: [ofa-general] ***SPAM*** InfiniBand/RDMA merge plans for 2.6.27

Quoted 4 lines · Roland Dreier

- I merged a decent amount of stuff for IPoIB, including LRO, "loopback blocking," and better handling of fabric events, and I don't think I have anything pending.

There is this patch that I did not recieve your response for. We think it's reasonable to do this - what do you think?

http://lists.openfabrics.org/pipermail/general/2008-July/052460.html

Quoted 1 line
#2 lore raw

Re: [ofa-general] ***SPAM*** InfiniBand/RDMA merge plans for 2.6.27

Quoted 4 lines

There is this patch that I did not recieve your response for. We think it's reasonable to do this - what do you think?

http://lists.openfabrics.org/pipermail/general/2008-July/052460.html

I'm ambivalent. Seems like a minor usability improvement in some cases, but on the other hand it seems a little strange to change the MTU behind the user's back. Maybe I'll stick it in -- I need to think about it.

#3 lore raw

Re: [ofa-general] ***SPAM*** InfiniBand/RDMA merge plans for 2.6.27

In reply to Roland Dreier
Quoted 10 lines · Roland Dreier

Core:

- I'm waiting to merge the RDMA_CM_EVENT_ADDR_CHANGE changes that depend on core networking changes until such changes are upstream. Or, please remind me when that happens.

- Jack's XRC patch set. I think we're getting closer to converging here, and I hope to get this merged but we're getting down to the wire, so we'll see.

I hope we can get those in

Quoted 7 lines

HW specific:

- Yevgeny's mlx4 changes. We'll see how much time is left after I get done with XRC (which is before this on my list) but to be honest I'm not sure how mergeable a lot of this is without the mlx4_en patches that actually use it.

We just posted the mlx4_en patches, and we need to coordinate the merge of them together

Quoted 4 lines

- I've been working on memory management extensions support for mlx4, but I'm not sure if it will be ready in time. Firmware for this may not be released for a while so it ain't urgent anyway.

We are testing the patches and we already have FW that enable them.
I agree its not urgent but it would be good to have it, so ULPs that are interested can be tested over IB too.

Quoted 8 lines

Here are a few topics that I believe will not be ready in time for the 2.6.27 window and will need to wait for 2.6.28 at least:

- Multiple CQ event vector support. No one has convinced me that we know how ULPs or userspace apps should decide which vector to use, and hence little progress has been made since we deferred this during the 2.6.23 merge window.

We should progress this one even if we missed 2.6.27, especially we need it for RSS, and I know also RDS can gain from it.

Tziporet

#4 lore raw

Re: [ofa-general] ***SPAM*** InfiniBand/RDMA merge plans for 2.6.27

Quoted 7 lines
Quoted 3 lines

- I've been working on memory management extensions support for mlx4, but I'm not sure if it will be ready in time. Firmware for this may not be released for a while so it ain't urgent anyway.

We are testing the patches and we already have FW that enable them. I agree its not urgent but it would be good to have it, so ULPs that are interested can be tested over IB too.

By the way, for outside of Mellanox, here is my patch that adds mem mgt extensions and local lkey support to mlx4. Comments appreciated...

drivers/infiniband/hw/mlx4/cq.c +12 -0
index 299f208..0b191a4 100644
@@ -637,6 +637,7 @@ repoll:
 		case MLX4_OPCODE_SEND_IMM:
 			wc->wc_flags |= IB_WC_WITH_IMM;
 		case MLX4_OPCODE_SEND:
+		case MLX4_OPCODE_SEND_INVAL:
 			wc->opcode    = IB_WC_SEND;
 			break;
 		case MLX4_OPCODE_RDMA_READ:
@@ -657,6 +658,12 @@ repoll:
 		case MLX4_OPCODE_LSO:
 			wc->opcode    = IB_WC_LSO;
 			break;
+		case MLX4_OPCODE_FMR:
+			wc->opcode    = IB_WC_FAST_REG_MR;
+			break;
+		case MLX4_OPCODE_LOCAL_INVAL:
+			wc->opcode    = IB_WC_LOCAL_INV;
+			break;
 		}
 	} else {
 		wc->byte_len = be32_to_cpu(cqe->byte_cnt);
@@ -667,6 +674,11 @@ repoll:
 			wc->wc_flags	= IB_WC_WITH_IMM;
 			wc->ex.imm_data = cqe->immed_rss_invalid;
 			break;
+		case MLX4_RECV_OPCODE_SEND_INVAL:
+			wc->opcode	= IB_WC_RECV;
+			wc->wc_flags	= IB_WC_WITH_INVALIDATE;
+			wc->ex.invalidate_rkey = be32_to_cpu(cqe->immed_rss_invalid);
+			break;
 		case MLX4_RECV_OPCODE_SEND:
 			wc->opcode   = IB_WC_RECV;
 			wc->wc_flags = 0;
drivers/infiniband/hw/mlx4/main.c +11 -0
index bcf5064..38d6907 100644
@@ -104,6 +104,12 @@ static int mlx4_ib_query_device(struct ib_device *ibdev,
 		props->device_cap_flags |= IB_DEVICE_UD_IP_CSUM;
 	if (dev->dev->caps.max_gso_sz)
 		props->device_cap_flags |= IB_DEVICE_UD_TSO;
+	if (dev->dev->caps.bmme_flags & MLX4_BMME_FLAG_RESERVED_LKEY)
+		props->device_cap_flags |= IB_DEVICE_LOCAL_DMA_LKEY;
+	if ((dev->dev->caps.bmme_flags & MLX4_BMME_FLAG_LOCAL_INV) &&
+	    (dev->dev->caps.bmme_flags & MLX4_BMME_FLAG_REMOTE_INV) &&
+	    (dev->dev->caps.bmme_flags & MLX4_BMME_FLAG_FAST_REG_WR))
+		props->device_cap_flags |= IB_DEVICE_MEM_MGT_EXTENSIONS;
 
 	props->vendor_id	   = be32_to_cpup((__be32 *) (out_mad->data + 36)) &
 		0xffffff;
@@ -127,6 +133,7 @@ static int mlx4_ib_query_device(struct ib_device *ibdev,
 	props->max_srq		   = dev->dev->caps.num_srqs - dev->dev->caps.reserved_srqs;
 	props->max_srq_wr	   = dev->dev->caps.max_srq_wqes - 1;
 	props->max_srq_sge	   = dev->dev->caps.max_srq_sge;
+	props->max_fast_reg_page_list_len = PAGE_SIZE / sizeof (u64);
 	props->local_ca_ack_delay  = dev->dev->caps.local_ca_ack_delay;
 	props->atomic_cap	   = dev->dev->caps.flags & MLX4_DEV_CAP_FLAG_ATOMIC ?
 		IB_ATOMIC_HCA : IB_ATOMIC_NONE;
@@ -565,6 +572,7 @@ static void *mlx4_ib_add(struct mlx4_dev *dev)
 	strlcpy(ibdev->ib_dev.name, "mlx4_%d", IB_DEVICE_NAME_MAX);
 	ibdev->ib_dev.owner		= THIS_MODULE;
 	ibdev->ib_dev.node_type		= RDMA_NODE_IB_CA;
+	ibdev->ib_dev.local_dma_lkey	= dev->caps.reserved_lkey;
 	ibdev->ib_dev.phys_port_cnt	= dev->caps.num_ports;
 	ibdev->ib_dev.num_comp_vectors	= 1;
 	ibdev->ib_dev.dma_device	= &dev->pdev->dev;
@@ -627,6 +635,9 @@ static void *mlx4_ib_add(struct mlx4_dev *dev)
 	ibdev->ib_dev.get_dma_mr	= mlx4_ib_get_dma_mr;
 	ibdev->ib_dev.reg_user_mr	= mlx4_ib_reg_user_mr;
 	ibdev->ib_dev.dereg_mr		= mlx4_ib_dereg_mr;
+	ibdev->ib_dev.alloc_fast_reg_mr = mlx4_ib_alloc_fast_reg_mr;
+	ibdev->ib_dev.alloc_fast_reg_page_list = mlx4_ib_alloc_fast_reg_page_list;
+	ibdev->ib_dev.free_fast_reg_page_list  = mlx4_ib_free_fast_reg_page_list;
 	ibdev->ib_dev.attach_mcast	= mlx4_ib_mcg_attach;
 	ibdev->ib_dev.detach_mcast	= mlx4_ib_mcg_detach;
 	ibdev->ib_dev.process_mad	= mlx4_ib_process_mad;
drivers/infiniband/hw/mlx4/mlx4_ib.h +15 -0
index c4cf5b6..d26a913 100644
@@ -83,6 +83,11 @@ struct mlx4_ib_mr {
 	struct ib_umem	       *umem;
 };
 
+struct mlx4_ib_fast_reg_page_list {
+	struct ib_fast_reg_page_list	ibfrpl;
+	dma_addr_t			map;
+};
+
 struct mlx4_ib_fmr {
 	struct ib_fmr           ibfmr;
 	struct mlx4_fmr         mfmr;
@@ -199,6 +204,11 @@ static inline struct mlx4_ib_mr *to_mmr(struct ib_mr *ibmr)
 	return container_of(ibmr, struct mlx4_ib_mr, ibmr);
 }
 
+static inline struct mlx4_ib_fast_reg_page_list *to_mfrpl(struct ib_fast_reg_page_list *ibfrpl)
+{
+	return container_of(ibfrpl, struct mlx4_ib_fast_reg_page_list, ibfrpl);
+}
+
 static inline struct mlx4_ib_fmr *to_mfmr(struct ib_fmr *ibfmr)
 {
 	return container_of(ibfmr, struct mlx4_ib_fmr, ibfmr);
@@ -239,6 +249,11 @@ struct ib_mr *mlx4_ib_reg_user_mr(struct ib_pd *pd, u64 start, u64 length,
 				  u64 virt_addr, int access_flags,
 				  struct ib_udata *udata);
 int mlx4_ib_dereg_mr(struct ib_mr *mr);
+struct ib_mr *mlx4_ib_alloc_fast_reg_mr(struct ib_pd *pd,
+					int max_page_list_len);
+struct ib_fast_reg_page_list *mlx4_ib_alloc_fast_reg_page_list(struct ib_device *ibdev,
+							       int page_list_len);
+void mlx4_ib_free_fast_reg_page_list(struct ib_fast_reg_page_list *page_list);
 
 int mlx4_ib_modify_cq(struct ib_cq *cq, u16 cq_count, u16 cq_period);
 int mlx4_ib_resize_cq(struct ib_cq *ibcq, int entries, struct ib_udata *udata);
drivers/infiniband/hw/mlx4/mr.c +70 -0

76 lines not on this page · raw message

drivers/infiniband/hw/mlx4/qp.c +67 -5

108 lines not on this page · raw message

drivers/net/mlx4/fw.c +3 -7
index 2b5006b..1180fca 100644
@@ -198,7 +198,7 @@ int mlx4_QUERY_DEV_CAP(struct mlx4_dev *dev, struct mlx4_dev_cap *dev_cap)
 #define QUERY_DEV_CAP_C_MPT_ENTRY_SZ_OFFSET	0x8e
 #define QUERY_DEV_CAP_MTT_ENTRY_SZ_OFFSET	0x90
 #define QUERY_DEV_CAP_D_MPT_ENTRY_SZ_OFFSET	0x92
-#define QUERY_DEV_CAP_BMME_FLAGS_OFFSET		0x97
+#define QUERY_DEV_CAP_BMME_FLAGS_OFFSET		0x94
 #define QUERY_DEV_CAP_RSVD_LKEY_OFFSET		0x98
 #define QUERY_DEV_CAP_MAX_ICM_SZ_OFFSET		0xa0
 
@@ -373,12 +373,8 @@ int mlx4_QUERY_DEV_CAP(struct mlx4_dev *dev, struct mlx4_dev_cap *dev_cap)
 		}
 	}
 
-	if (dev_cap->bmme_flags & 1)
-		mlx4_dbg(dev, "Base MM extensions: yes "
-			 "(flags %d, rsvd L_Key %08x)\n",
-			 dev_cap->bmme_flags, dev_cap->reserved_lkey);
-	else
-		mlx4_dbg(dev, "Base MM extensions: no\n");
+	mlx4_dbg(dev, "Base MM extensions: flags %08x, rsvd L_Key %08x\n",
+		 dev_cap->bmme_flags, dev_cap->reserved_lkey);
 
 	/*
 	 * Each UAR has 4 EQ doorbells; so if a UAR is reserved, then
drivers/net/mlx4/fw.h +1 -1
index a0e046c..fbf0e22 100644
@@ -98,7 +98,7 @@ struct mlx4_dev_cap {
 	int cmpt_entry_sz;
 	int mtt_entry_sz;
 	int resize_srq;
-	u8  bmme_flags;
+	u32 bmme_flags;
 	u32 reserved_lkey;
 	u64 max_icm_sz;
 	int max_gso_sz;
drivers/net/mlx4/main.c +2 -0
index d373601..8e1d24c 100644
@@ -158,6 +158,8 @@ static int mlx4_dev_cap(struct mlx4_dev *dev, struct mlx4_dev_cap *dev_cap)
 	dev->caps.max_msg_sz         = dev_cap->max_msg_sz;
 	dev->caps.page_size_cap	     = ~(u32) (dev_cap->min_page_sz - 1);
 	dev->caps.flags		     = dev_cap->flags;
+	dev->caps.bmme_flags	     = dev_cap->bmme_flags;
+	dev->caps.reserved_lkey	     = dev_cap->reserved_lkey;
 	dev->caps.stat_rate_support  = dev_cap->stat_rate_support;
 	dev->caps.max_gso_sz	     = dev_cap->max_gso_sz;
 
drivers/net/mlx4/mr.c +18 -5
index 03a9abc..66c6f84 100644
@@ -47,7 +47,7 @@ struct mlx4_mpt_entry {
 	__be32 flags;
 	__be32 qpn;
 	__be32 key;
-	__be32 pd;
+	__be32 pd_flags;
 	__be64 start;
 	__be64 length;
 	__be32 lkey;
@@ -61,11 +61,15 @@ struct mlx4_mpt_entry {
 } __attribute__((packed));
 
 #define MLX4_MPT_FLAG_SW_OWNS	    (0xfUL << 28)
+#define MLX4_MPT_FLAG_FREE	    (0x3UL << 28)
 #define MLX4_MPT_FLAG_MIO	    (1 << 17)
 #define MLX4_MPT_FLAG_BIND_ENABLE   (1 << 15)
 #define MLX4_MPT_FLAG_PHYSICAL	    (1 <<  9)
 #define MLX4_MPT_FLAG_REGION	    (1 <<  8)
 
+#define MLX4_MPT_PD_FLAG_FAST_REG   (1 << 26)
+#define MLX4_MPT_PD_FLAG_EN_INV	    (3 << 24)
+
 #define MLX4_MTT_FLAG_PRESENT		1
 
 #define MLX4_MPT_STATUS_SW		0xF0
@@ -314,21 +318,30 @@ int mlx4_mr_enable(struct mlx4_dev *dev, struct mlx4_mr *mr)
 
 	memset(mpt_entry, 0, sizeof *mpt_entry);
 
-	mpt_entry->flags = cpu_to_be32(MLX4_MPT_FLAG_SW_OWNS	 |
-				       MLX4_MPT_FLAG_MIO	 |
+	mpt_entry->flags = cpu_to_be32(MLX4_MPT_FLAG_MIO	 |
 				       MLX4_MPT_FLAG_REGION	 |
 				       mr->access);
 
 	mpt_entry->key	       = cpu_to_be32(key_to_hw_index(mr->key));
-	mpt_entry->pd	       = cpu_to_be32(mr->pd);
+	mpt_entry->pd_flags    = cpu_to_be32(mr->pd | MLX4_MPT_PD_FLAG_EN_INV);
 	mpt_entry->start       = cpu_to_be64(mr->iova);
 	mpt_entry->length      = cpu_to_be64(mr->size);
 	mpt_entry->entity_size = cpu_to_be32(mr->mtt.page_shift);
+
 	if (mr->mtt.order < 0) {
 		mpt_entry->flags |= cpu_to_be32(MLX4_MPT_FLAG_PHYSICAL);
 		mpt_entry->mtt_seg = 0;
-	} else
+	} else {
 		mpt_entry->mtt_seg = cpu_to_be64(mlx4_mtt_addr(dev, &mr->mtt));
+	}
+
+	if (mr->mtt.order >= 0 && mr->mtt.page_shift == 0) {
+		/* fast register MR in free state */
+		mpt_entry->flags    |= cpu_to_be32(MLX4_MPT_FLAG_FREE);
+		mpt_entry->pd_flags |= cpu_to_be32(MLX4_MPT_PD_FLAG_FAST_REG);
+	} else {
+		mpt_entry->flags    |= cpu_to_be32(MLX4_MPT_FLAG_SW_OWNS);
+	}
 
 	err = mlx4_SW2HW_MPT(dev, mailbox,
 			     key_to_hw_index(mr->key) & (dev->caps.num_mpts - 1));
include/linux/mlx4/device.h +10 -0
index 81b3dd5..655ea0d 100644
@@ -68,6 +68,14 @@ enum {
 	MLX4_DEV_CAP_FLAG_UD_MCAST	= 1 << 21
 };
 
+enum {
+	MLX4_BMME_FLAG_LOCAL_INV	= 1 <<  6,
+	MLX4_BMME_FLAG_REMOTE_INV	= 1 <<  7,
+	MLX4_BMME_FLAG_TYPE_2_WIN	= 1 <<  9,
+	MLX4_BMME_FLAG_RESERVED_LKEY	= 1 << 10,
+	MLX4_BMME_FLAG_FAST_REG_WR	= 1 << 11,
+};
+
 enum mlx4_event {
 	MLX4_EVENT_TYPE_COMP		   = 0x00,
 	MLX4_EVENT_TYPE_PATH_MIG	   = 0x01,
@@ -184,6 +192,8 @@ struct mlx4_caps {
 	u32			max_msg_sz;
 	u32			page_size_cap;
 	u32			flags;
+	u32			bmme_flags;
+	u32			reserved_lkey;
 	u16			stat_rate_support;
 	u8			port_width_cap[MLX4_MAX_PORTS + 1];
 	int			max_gso_sz;
include/linux/mlx4/qp.h +10 -4
index 7f128b2..5cb34fb 100644
@@ -233,6 +233,14 @@ struct mlx4_wqe_bind_seg {
 	__be64			length;
 };
 
+enum {
+	MLX4_WQE_FMR_PERM_LOCAL_READ	= 1 << 27,
+	MLX4_WQE_FMR_PERM_LOCAL_WRITE	= 1 << 28,
+	MLX4_WQE_FMR_PERM_REMOTE_READ	= 1 << 29,
+	MLX4_WQE_FMR_PERM_REMOTE_WRITE	= 1 << 30,
+	MLX4_WQE_FMR_PERM_ATOMIC	= 1 << 31
+};
+
 struct mlx4_wqe_fmr_seg {
 	__be32			flags;
 	__be32			mem_key;
@@ -255,11 +263,9 @@ struct mlx4_wqe_fmr_ext_seg {
 };
 
 struct mlx4_wqe_local_inval_seg {
-	u8			flags;
-	u8			reserved1[3];
+	__be32			flags;
 	__be32			mem_key;
-	u8			reserved2[3];
-	u8			guest_id;
+	__be32			guest_id;
 	__be64			pa;
 };
 

A message that is not in the archive (sent off-list or not yet received): [email protected]

#6 lore raw

Re: [ofa-general] ***SPAM*** InfiniBand/RDMA merge plans for 2.6.27

Quoted 2 lines

So just to make sure, firmware 2.5 does not support IB BMME and if I want to test with this patch I need to get a special firmware drop from Mellanox?

Right: in the test

+ if ((dev->dev->caps.bmme_flags & MLX4_BMME_FLAG_LOCAL_INV) &&
+ (dev->dev->caps.bmme_flags & MLX4_BMME_FLAG_REMOTE_INV) &&
+ (dev->dev->caps.bmme_flags & MLX4_BMME_FLAG_FAST_REG_WR))
+ props->device_cap_flags |= IB_DEVICE_MEM_MGT_EXTENSIONS;

you will see that not all the bmme_flags required are set by FW 2.5.

#7 lore raw

Re: [ofa-general] ***SPAM*** InfiniBand/RDMA merge plans for 2.6.27

Quoted 10 lines · Roland Dreier

Right: in the test

drivers/infiniband/hw/mlx4/main.c +4 -0
+	if ((dev->dev->caps.bmme_flags & MLX4_BMME_FLAG_LOCAL_INV) &&
+	    (dev->dev->caps.bmme_flags & MLX4_BMME_FLAG_REMOTE_INV) &&
+	    (dev->dev->caps.bmme_flags & MLX4_BMME_FLAG_FAST_REG_WR))
+		props->device_cap_flags |= IB_DEVICE_MEM_MGT_EXTENSIONS;

you will see that not all the bmme_flags required are set by FW 2.5.

If someone is interested to get a FW that implement is please reply to me We should have such a FW next week

Tziporet

#8 lore raw

Re: [ofa-general] ***SPAM*** InfiniBand/RDMA merge plans for 2.6.27

In reply to Roland Dreier
Quoted 11 lines · Roland Dreier

HW specific:

 - Yevgeny's mlx4 changes.  We'll see how much time is left after I get done with XRC (which is before this on my list) but to be honest I'm not sure how mergeable a lot of this is without the mlx4_en patches that actually use it.

 - I've been working on memory management extensions support for mlx4, but I'm not sure if it will be ready in time.  Firmware for this may not be released for a while so it ain't urgent anyway.

Roland, what about the fw diagnostic patch for the mlx4 driver?
http://lists.openfabrics.org/pipermail/general/2008-June/051655.html

Can you put this in 2.6.27, too?

- Jack

#10 lore raw
In reply to Roland Dreier
Quoted 7 lines · Roland Dreier

... 2.6.26 is already out, so it's time to review what my plans are for the merge window opens.

Core:

- I'm waiting to merge the RDMA_CM_EVENT_ADDR_CHANGE changes that depend on core networking changes until such changes are upstream. Or, please remind me when that happens.

Dave,

There are some rdma patches for 2.6.27 which are dependent on few networking patches (below), so Roland can't push them before the net changes gets in, such that enough time has to be left for the rdma push before the merge window closes...

Or.

Quoted 17 lines

commit 01f3109de49a889db8adf9116449727547ee497e

Author: Or Gerlitz <[email protected]>
Date:   Fri Jun 13 18:12:02 2008 -0700

bonding: deliver netdev event for fail-over under the active-backup mode

commit 709f8a45e8521f2f4229e5fdf3ded1fb77e2ca4e

Author: Or Gerlitz <[email protected]>
Date:   Fri Jun 13 18:12:01 2008 -0700

bonding: bond_change_active_slave() cleanup under active-backup

commit c1da4ac752b8b0411791d26c678fcf23d2eed242

Author: Or Gerlitz <[email protected]>
Date:   Fri Jun 13 18:12:00 2008 -0700

net/core: add NETDEV_BONDING_FAILOVER event

maintainer
#11 lore raw

From: Or Gerlitz <[email protected]>
Date: Thu, 17 Jul 2008 10:31:47 +0300

Quoted 4 lines

There are some rdma patches for 2.6.27 which are dependent on few networking patches (below), so Roland can't push them before the net changes gets in, such that enough time has to be left for the rdma push before the merge window closes...

I'm pushing to Linus this coming Sunday.

I wanted to do it sooner but my tree isn't in a state where I can merge it just yet, and Linus is going away for 3 days starting Thursday.

I'm sorry if this makes things difficult, but it's the best I can do at the moment.

#12 lore raw
Quoted 2 lines · David Miller

I'm pushing to Linus this coming Sunday. I'm sorry if this makes things difficult, but it's the best I can do at the moment.

thanks for the update, I believe this will leave Roland enough time to do his push,

Or.