InfiniBand/RDMA merge plans for 2.6.27
Subsystems (5)
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
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
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.
Re: [ofa-general] ***SPAM*** InfiniBand/RDMA merge plans for 2.6.27
In reply to Roland DreierQuoted 10 lines · Roland Dreier
Core:
- I'm waiting to merge the
RDMA_CM_EVENT_ADDR_CHANGEchanges 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_enpatches 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
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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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]
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.
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_flagsrequired 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
Re: [ofa-general] ***SPAM*** InfiniBand/RDMA merge plans for 2.6.27
In reply to Roland DreierQuoted 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_enpatches 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
Re: [ofa-general] ***SPAM*** InfiniBand/RDMA merge plans for 2.6.27
Quoted 2 lines
Roland, what about the fw diagnostic patch for the mlx4 driver?
http://lists.openfabrics.org/pipermail/general/2008-June/051655.html
Oh yeah, I'll reply on that thread.
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_CHANGEchanges 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
01f3109de49a889db8adf9116449727547ee497eAuthor: Or Gerlitz <[email protected]> Date: Fri Jun 13 18:12:02 2008 -0700bonding: deliver netdev event for fail-over under the active-backup mode
commit
709f8a45e8521f2f4229e5fdf3ded1fb77e2ca4eAuthor: Or Gerlitz <[email protected]> Date: Fri Jun 13 18:12:01 2008 -0700bonding:
bond_change_active_slave()cleanup under active-backupcommit
c1da4ac752b8b0411791d26c678fcf23d2eed242Author: Or Gerlitz <[email protected]> Date: Fri Jun 13 18:12:00 2008 -0700net/core: add
NETDEV_BONDING_FAILOVERevent
David Miller
maintainerFrom: 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.
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.