On Tue, 2015-08-04 at 12:09 -0600, Jason Gunthorpe wrote:
On Mon, Aug 03, 2015 at 11:33:51AM -0700, Bart Van Assche wrote:
Bart, do you know what hardware this workaround is for?
I hope the HW vendors can comment on this. Sorry but I'm not sure which HCA
models and/or firmware versions
On 8/5/2015 1:09 AM, Jason Gunthorpe wrote:
On Tue, Aug 04, 2015 at 05:03:28PM +0300, Yishai Hadas wrote:
Currently, IB/cma remove_one flow blocks until all user descriptor managed by
IB/ucma are released. This prevents hot-removal of IB devices. This patch
allows IB/cma to remove devices
From: Bodong Wang bod...@mellanox.com
- TX/RX checksum offload capabilities are now reporting through
a new member csum_cap inside ib_device_attr.
- The capabilities cover IP_HDR and TCP_UDP.
Signed-off-by: Bodong Wang bod...@mellanox.com
Signed-off-by: Amir Vadai am...@mellanox.com
---
Use the new capability flags for RX/TX checksum offload.
Signed-off-by: Amir Vadai am...@mellanox.com
---
drivers/infiniband/hw/mlx4/main.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/infiniband/hw/mlx4/main.c
b/drivers/infiniband/hw/mlx4/main.c
index 1437ed5..2af7554
Hi Doug,
This small patchset introduces a new member csum_cap inside ib_device_attr.
It is used to report RX/TX checksum offload capabilities of the device.
Having a new field enables reporting more specific capabilities than
the single bit IB_DEVICE_IP_CSUM.
This will be used by a revised
On 8/5/2015 3:23 AM, Jason Gunthorpe wrote:
On Tue, Aug 04, 2015 at 05:03:28PM +0300, Yishai Hadas wrote:
Currently, IB/cma remove_one flow blocks until all user descriptor managed by
IB/ucma are released. This prevents hot-removal of IB devices. This patch
allows IB/cma to remove devices
+enum ib_csum_cap_flags {
+ IB_CSUM_RX_TCP_UDP = 1 0,
+ IB_CSUM_RX_IP_HDR= 1 1,
+ IB_CSUM_TX_TCP_UDP = 1 2,
+ IB_CSUM_TX_IP_HDR= 1 3
+};
TPC and UDP should be separate flags.
--
To unsubscribe from this list: send the line unsubscribe
+enum ib_csum_cap_flags {
+ IB_CSUM_RX_TCP_UDP = 1 0,
+ IB_CSUM_RX_IP_HDR= 1 1,
+ IB_CSUM_TX_TCP_UDP = 1 2,
+ IB_CSUM_TX_IP_HDR= 1 3
+};
TPC and UDP should be separate flags.
Can you explain why?
For the same reason that you didn't include
On Wed, Aug 05, 2015 at 06:34:26PM +0300, Amir Vadai wrote:
struct ib_uverbs_ex_query_device {
__u32 comp_mask;
+ __u32 csum_caps;
__u32 reserved;
};
Uh no.
@@ -221,6 +222,7 @@ struct ib_uverbs_odp_caps {
struct ib_uverbs_ex_query_device_resp {
struct
+enum ib_csum_cap_flags {
+ IB_CSUM_RX_TCP_UDP = 1 0,
+ IB_CSUM_RX_IP_HDR= 1 1,
+ IB_CSUM_TX_TCP_UDP = 1 2,
+ IB_CSUM_TX_IP_HDR= 1 3
+};
TPC and UDP should be separate flags.
Can you explain why?
What we are advertising here is offloads for
On Wed, Aug 05, 2015 at 06:09:45PM +0300, Yishai Hadas wrote:
+static void ucma_close_id(struct work_struct *work)
+{
+ struct ucma_context *ctx = container_of(work, struct ucma_context,
close_work);
+
+ /* Fence to ensure that ctx-closing was seen by all
+* ucma_get_ctx running
On Tue, Aug 04, 2015 at 11:41:16PM -0700, David Dillow wrote:
On Tue, 2015-08-04 at 12:09 -0600, Jason Gunthorpe wrote:
On Mon, Aug 03, 2015 at 11:33:51AM -0700, Bart Van Assche wrote:
Bart, do you know what hardware this workaround is for?
I hope the HW vendors can comment on this.
Every single ULP requires a local_dma_lkey to do anything with
a QP, so let us ensure one exists for every PD created.
If the driver can supply a global local_dma_lkey then use that, otherwise
ask the driver to create a local use all physical memory MR associated
with the new PD.
Signed-off-by:
The majority of callers never check the return value, and even if they
did, they can't do anything about a failure.
All possible failure cases represent a bug in the caller, so just
WARN_ON inside the function instead.
This fixes a few random errors:
net/rd/iw.c infinite loops while it fails.
On Aug 5, 2015, at 4:34 PM, Jason Gunthorpe jguntho...@obsidianresearch.com
wrote:
The majority of callers never check the return value, and even if they
did, they can't do anything about a failure.
All possible failure cases represent a bug in the caller, so just
WARN_ON inside the
On 08/05/2015 04:50 PM, Chuck Lever wrote:
On Aug 5, 2015, at 4:34 PM, Jason Gunthorpe jguntho...@obsidianresearch.com
wrote:
The majority of callers never check the return value, and even if they
did, they can't do anything about a failure.
All possible failure cases represent a bug in
On Aug 5, 2015, at 5:00 PM, Anna Schumaker anna.schuma...@netapp.com wrote:
On 08/05/2015 04:50 PM, Chuck Lever wrote:
On Aug 5, 2015, at 4:34 PM, Jason Gunthorpe
jguntho...@obsidianresearch.com wrote:
The majority of callers never check the return value, and even if they
did, they
Hey Sagi, how is this coming along? How can I help?
Hi Steve,
This is taking longer than I expected, the changes needed seem
pretty extensive throughout the IO path. I don't think it will be ready
for 4.3
Perhaps then we should go with my version that adds iwarp-only
On 08/05/2015 12:51 PM, Jason Gunthorpe wrote:
On Tue, Aug 04, 2015 at 11:41:16PM -0700, David Dillow wrote:
On Tue, 2015-08-04 at 12:09 -0600, Jason Gunthorpe wrote:
On Mon, Aug 03, 2015 at 11:33:51AM -0700, Bart Van Assche wrote:
Bart, do you know what hardware this workaround is for?
I
On Wed, Aug 5, 2015 at 8:16 PM, Jason Gunthorpe
jguntho...@obsidianresearch.com wrote:
On Wed, Aug 05, 2015 at 06:34:26PM +0300, Amir Vadai wrote:
struct ib_uverbs_ex_query_device {
__u32 comp_mask;
+ __u32 csum_caps;
__u32 reserved;
};
Uh no.
@@ -221,6 +222,7 @@ struct
On Sun, Aug 02, 2015 at 10:56:38AM +0300, Matan Barak wrote:
Indeed this design flaw was introduced when the first legacy verb was
extended. I think that falling back from extended code to legacy code
should be in the uverbs code. ib_uverbs_write will return -ENOSYS only
if both extended and
On Wed, Aug 05, 2015 at 05:19:10PM -0700, Bart Van Assche wrote:
A few experimental and untested patches are available for review at
https://github.com/bvanassche/linux/tree/srp-initiator-for-next-experimental.
I'll leave this is in your hands then..
Thanks,
Jason
--
To unsubscribe from this
On Tue, Aug 04, 2015 at 07:34:47AM -0700, Christoph Hellwig wrote:
Hi all,
please take a look at my RFC patch here:
http://git.infradead.org/users/hch/scsi.git/commitdiff/751774250b71da83a26ba8584cff70f5e7bb7b1e
the commit contains my explanation, but apparently the patch is too
On Thu, Aug 06, 2015 at 01:16:17AM +0300, Or Gerlitz wrote:
So -- shit happens, I am trying to figure out if an internal review
has been done, b/c we do have some folks who terribly master the
extended uverbs framework, right...?
You and Matan had no problem doing the timestamp stuff properly
On 08/05/2015 02:45 PM, Bart Van Assche wrote:
On 08/05/2015 12:51 PM, Jason Gunthorpe wrote:
On Tue, Aug 04, 2015 at 11:41:16PM -0700, David Dillow wrote:
On Tue, 2015-08-04 at 12:09 -0600, Jason Gunthorpe wrote:
On Mon, Aug 03, 2015 at 11:33:51AM -0700, Bart Van Assche wrote:
Bart, do you
On Wed, Aug 5, 2015 at 7:17 PM, Hefty, Sean sean.he...@intel.com wrote:
TPC and UDP should be separate flags.
Sean,
I don't think we should over-complex things vs. what the network stack
does for many (since kernel 2.4?!) years. They have basically three
flags
NETIF_F_IP_CSUM - device can
On Wed, Aug 05, 2015 at 03:41:46PM -0700, Bart Van Assche wrote:
Regarding the discussion in 2011 about FMR
(http://thread.gmane.org/gmane.linux.drivers.rdma/7149): since in 2011
nobody recalled the root cause of the issue with non-page aligned FMR my
proposal is to drop the page alignment
27 matches
Mail list logo
