public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

      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