From: Doug Ledford <dledford@redhat.com>
To: Johannes Thumshirn <jthumshirn@suse.de>
Cc: Linux Kernel Mailinglist <linux-kernel@vger.kernel.org>,
linux-rdma@vger.kernel.org, Hannes Reinecke <hare@suse.de>,
Sagi Grimberg <sagi@grimberg.me>,
Max Gurtovoy <maxg@mellanox.com>, Moni Shoua <monis@mellanox.com>,
Sean Hefty <sean.hefty@intel.com>,
Hal Rosenstock <hal.rosenstock@gmail.com>
Subject: Re: [PATCH] IB/rxe: Don't clamp residual length to mtu
Date: Mon, 01 May 2017 14:44:00 -0400 [thread overview]
Message-ID: <1493664240.3041.183.camel@redhat.com> (raw)
In-Reply-To: <20170425072938.GB16843@linux-x5ow.site>
On Tue, 2017-04-25 at 09:29 +0200, Johannes Thumshirn wrote:
> On Thu, Apr 06, 2017 at 02:49:44PM +0200, Johannes Thumshirn wrote:
> >
> > When reading a RDMA WRITE FIRST packet we copy the DMA length from
> > the RDMA
> > header into the qp->resp.resid variable for later use. Later in
> > check_rkey()
> > we clamp it to the MTU if the packet is an RDMA WRITE packet and
> > has a
> > residual length bigger than the MTU. Later in write_data_in() we
> > subtract the
> > payload of the packet from the residual length. If the packet
> > happens to have a
> > payload of exactly the MTU size we end up with a residual length of
> > 0 despite
> > the packet not being the last in the conversation. When the next
> > packet in the
> > conversation arrives, we don't have any residual length left and
> > thus set the QP
> > into an error state.
> >
> > This broke NVMe over Fabrics functionality over rdma_rxe.ko
> >
> > The patch was verified using the following test.
> >
> > # echo eth0 > /sys/module/rdma_rxe/parameters/add
> > # nvme connect -t rdma -a 192.168.155.101 -s 1023 -n nvmf-test
> > # mkfs.xfs -fK /dev/nvme0n1
> > meta-data=/dev/nvme0n1 isize=256 agcount=4,
> > agsize=65536 blks
> > = sectsz=4096 attr=2,
> > projid32bit=1
> > = crc=0 finobt=0, sparse=0
> > data = bsize=4096 blocks=262144,
> > imaxpct=25
> > = sunit=0 swidth=0 blks
> > naming =version 2 bsize=4096 ascii-ci=0 ftype=1
> > log =internal log bsize=4096 blocks=2560,
> > version=2
> > = sectsz=4096 sunit=1 blks, lazy-
> > count=1
> > realtime =none extsz=4096 blocks=0,
> > rtextents=0
> > # mount /dev/nvme0n1 /tmp/
> > [ 148.923263] XFS (nvme0n1): Mounting V4 Filesystem
> > [ 148.961196] XFS (nvme0n1): Ending clean mount
> > # dd if=/dev/urandom of=test.bin bs=1M count=128
> > 128+0 records in
> > 128+0 records out
> > 134217728 bytes (134 MB, 128 MiB) copied, 0.437991 s, 306 MB/s
> > # sha256sum test.bin
> > cde42941f045efa8c4f0f157ab6f29741753cdd8d1cff93a6b03649d83c4129a
> > test.bin
> > # cp test.bin /tmp/
> > sha256sum /tmp/test.bin
> > cde42941f045efa8c4f0f157ab6f29741753cdd8d1cff93a6b03649d83c4129a
> > /tmp/test.bin
> >
> > Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
> > Cc: Hannes Reinecke <hare@suse.de>
> > Cc: Sagi Grimberg <sagi@grimberg.me>
> > Cc: Max Gurtovoy <maxg@mellanox.com>
> > ---
>
> Doug anything left here? I already have an Ack from Moni. This patch
> is needed
> to get NVMe over Fabrics working on rxe so I'd like to see it in
> v4.12.
Nope, it's all good. I applied it today.
--
Doug Ledford <dledford@redhat.com>
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
prev parent reply other threads:[~2017-05-01 18:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-06 12:49 [PATCH] IB/rxe: Don't clamp residual length to mtu Johannes Thumshirn
2017-04-13 12:00 ` Johannes Thumshirn
2017-04-13 12:22 ` Leon Romanovsky
2017-04-13 12:29 ` Johannes Thumshirn
2017-04-13 14:12 ` Moni Shoua
2017-04-25 7:29 ` Johannes Thumshirn
2017-05-01 18:44 ` Doug Ledford [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1493664240.3041.183.camel@redhat.com \
--to=dledford@redhat.com \
--cc=hal.rosenstock@gmail.com \
--cc=hare@suse.de \
--cc=jthumshirn@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=maxg@mellanox.com \
--cc=monis@mellanox.com \
--cc=sagi@grimberg.me \
--cc=sean.hefty@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox