From: Suwan Kim <suwan.kim027@gmail.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: shuah <shuah@kernel.org>, Christoph Hellwig <hch@lst.de>,
Valentina Manea <valentina.manea.m@gmail.com>,
Oliver Neukum <oneukum@suse.com>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>
Subject: Re: How to resolve an issue in swiotlb environment?
Date: Sat, 22 Jun 2019 02:43:43 +0900 [thread overview]
Message-ID: <20190621174342.GA28335@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1906191649350.1596-100000@iolanthe.rowland.org>
On Wed, Jun 19, 2019 at 05:05:49PM -0400, Alan Stern wrote:
> On Wed, 19 Jun 2019, shuah wrote:
>
> > I missed a lot of the thread info. and went looking for it and found the
> > following summary of the problem:
> >
> > ==================
> > The issue which prompted the commit this thread is about arose in a
> > situation where the block layer set up a scatterlist containing buffer
> > sizes something like:
> >
> > 4096 4096 1536 1024
> >
> > and the maximum packet size was 1024. The situation was a little
> > unusual, because it involved vhci-hcd (a virtual HCD). This doesn't
> > matter much in normal practice because:
> >
> > Block devices normally have a block size of 512 bytes or more.
> > Smaller values are very uncommon. So scatterlist element sizes
> > are always divisible by 512.
> >
> > xHCI is the only USB host controller type with a maximum packet
> > size larger than 512, and xHCI hardware can do full
> > scatter-gather so it doesn't care what the buffer sizes are.
> >
> > So another approach would be to fix vhci-hcd and then trust that the
> > problem won't arise again, for the reasons above. We would be okay so
> > long as nobody tried to use a USB-SCSI device with a block size of 256
> > bytes or less.
> > ===================
> >
> > Out of the summary, the following gives me pause:
> >
> > "xHCI hardware can do full scatter-gather so it doesn't care what the
> > buffer sizes are."
> >
> > vhci-hcd won't be able to count on hardware being able to do full
> > scatter-gather. It has to deal with a variety of hardware with
> > varying speeds.
>
> Sure. But you can test whether the server's HCD is able to handle
> scatter-gather transfers, and if it is then you can say that the
> client-side vhci-hcd is able to handle them as well. Then all you
> would have to do is preserve the scatterlist information describing the
> transfer when you go between the client and the server.
>
> The point is to make sure that the client-side vhci-hcd doesn't claim
> to be _less_ capable than the server-side actual HCD. That's what
> leads to the problem described above.
>
> > "We would be okay so long as nobody tried to use a USB-SCSI device with
> > a block size of 256 bytes or less."
> >
> > At least a USB Storage device, I test with says 512 block size. Can we
> > count on not seeing a device with block size <= 256 bytes?
>
> Yes, we can. In fact, the SCSI core doesn't handle devices with block
> size < 512.
>
> > In any case, I am looking into adding SG support vhci-hci at the moment.
> >
> > Looks like the following is the repo, I should be working with?
> >
> > git://git.infradead.org/users/hch/misc.git
>
> It doesn't matter. Your work should end up being independent of
> Christoph's, so you can base it on any repo.
I implemented SG support of vhci. I will send it as a patch.
Please look at it and let me know if you have a feedback.
Regards
Suwan Kim
WARNING: multiple messages have this Message-ID (diff)
From: Suwan Kim <suwan.kim027@gmail.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
Oliver Neukum <oneukum@suse.com>,
Valentina Manea <valentina.manea.m@gmail.com>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>, shuah <shuah@kernel.org>,
Christoph Hellwig <hch@lst.de>
Subject: Re: How to resolve an issue in swiotlb environment?
Date: Sat, 22 Jun 2019 02:43:43 +0900 [thread overview]
Message-ID: <20190621174342.GA28335@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1906191649350.1596-100000@iolanthe.rowland.org>
On Wed, Jun 19, 2019 at 05:05:49PM -0400, Alan Stern wrote:
> On Wed, 19 Jun 2019, shuah wrote:
>
> > I missed a lot of the thread info. and went looking for it and found the
> > following summary of the problem:
> >
> > ==================
> > The issue which prompted the commit this thread is about arose in a
> > situation where the block layer set up a scatterlist containing buffer
> > sizes something like:
> >
> > 4096 4096 1536 1024
> >
> > and the maximum packet size was 1024. The situation was a little
> > unusual, because it involved vhci-hcd (a virtual HCD). This doesn't
> > matter much in normal practice because:
> >
> > Block devices normally have a block size of 512 bytes or more.
> > Smaller values are very uncommon. So scatterlist element sizes
> > are always divisible by 512.
> >
> > xHCI is the only USB host controller type with a maximum packet
> > size larger than 512, and xHCI hardware can do full
> > scatter-gather so it doesn't care what the buffer sizes are.
> >
> > So another approach would be to fix vhci-hcd and then trust that the
> > problem won't arise again, for the reasons above. We would be okay so
> > long as nobody tried to use a USB-SCSI device with a block size of 256
> > bytes or less.
> > ===================
> >
> > Out of the summary, the following gives me pause:
> >
> > "xHCI hardware can do full scatter-gather so it doesn't care what the
> > buffer sizes are."
> >
> > vhci-hcd won't be able to count on hardware being able to do full
> > scatter-gather. It has to deal with a variety of hardware with
> > varying speeds.
>
> Sure. But you can test whether the server's HCD is able to handle
> scatter-gather transfers, and if it is then you can say that the
> client-side vhci-hcd is able to handle them as well. Then all you
> would have to do is preserve the scatterlist information describing the
> transfer when you go between the client and the server.
>
> The point is to make sure that the client-side vhci-hcd doesn't claim
> to be _less_ capable than the server-side actual HCD. That's what
> leads to the problem described above.
>
> > "We would be okay so long as nobody tried to use a USB-SCSI device with
> > a block size of 256 bytes or less."
> >
> > At least a USB Storage device, I test with says 512 block size. Can we
> > count on not seeing a device with block size <= 256 bytes?
>
> Yes, we can. In fact, the SCSI core doesn't handle devices with block
> size < 512.
>
> > In any case, I am looking into adding SG support vhci-hci at the moment.
> >
> > Looks like the following is the repo, I should be working with?
> >
> > git://git.infradead.org/users/hch/misc.git
>
> It doesn't matter. Your work should end up being independent of
> Christoph's, so you can base it on any repo.
I implemented SG support of vhci. I will send it as a patch.
Please look at it and let me know if you have a feedback.
Regards
Suwan Kim
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2019-06-21 17:43 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-03 6:42 How to resolve an issue in swiotlb environment? Yoshihiro Shimoda
2019-06-03 6:42 ` Yoshihiro Shimoda
2019-06-07 12:00 ` Yoshihiro Shimoda
2019-06-07 12:00 ` Yoshihiro Shimoda
2019-06-10 7:31 ` Biju Das
2019-06-10 7:31 ` Biju Das
2019-06-10 11:13 ` Yoshihiro Shimoda
2019-06-10 11:13 ` Yoshihiro Shimoda
2019-06-10 12:32 ` Christoph Hellwig
2019-06-10 12:32 ` Christoph Hellwig
2019-06-10 18:46 ` Alan Stern
2019-06-10 18:46 ` Alan Stern
2019-06-11 6:41 ` Christoph Hellwig
2019-06-11 6:41 ` Christoph Hellwig
2019-06-11 14:51 ` Alan Stern
2019-06-11 14:51 ` Alan Stern
2019-06-12 7:30 ` Christoph Hellwig
2019-06-12 7:30 ` Christoph Hellwig
2019-06-12 8:52 ` Yoshihiro Shimoda
2019-06-12 8:52 ` Yoshihiro Shimoda
2019-06-12 11:31 ` Christoph Hellwig
2019-06-12 11:31 ` Christoph Hellwig
2019-06-13 4:52 ` Yoshihiro Shimoda
2019-06-13 4:52 ` Yoshihiro Shimoda
2019-06-12 11:46 ` Oliver Neukum
2019-06-12 11:46 ` Oliver Neukum
2019-06-12 12:06 ` Christoph Hellwig
2019-06-12 12:06 ` Christoph Hellwig
2019-06-12 14:43 ` Alan Stern
2019-06-12 14:43 ` Alan Stern
2019-06-13 7:39 ` Christoph Hellwig
2019-06-13 7:39 ` Christoph Hellwig
2019-06-13 16:57 ` Martin K. Petersen
2019-06-13 16:57 ` Martin K. Petersen
2019-06-13 17:16 ` Alan Stern
2019-06-13 17:16 ` Alan Stern
2019-06-13 18:18 ` Greg KH
2019-06-13 18:18 ` Greg KH
2019-06-13 23:01 ` shuah
2019-06-13 23:01 ` shuah
2019-06-14 14:44 ` Alan Stern
2019-06-14 14:44 ` Alan Stern
2019-06-18 15:28 ` shuah
2019-06-18 15:28 ` shuah
2019-06-19 20:23 ` shuah
2019-06-19 20:23 ` shuah
2019-06-19 21:05 ` Alan Stern
2019-06-19 21:05 ` Alan Stern
2019-06-21 17:43 ` Suwan Kim [this message]
2019-06-21 17:43 ` Suwan Kim
2019-06-11 6:49 ` Yoshihiro Shimoda
2019-06-11 6:49 ` Yoshihiro Shimoda
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=20190621174342.GA28335@localhost.localdomain \
--to=suwan.kim027@gmail.com \
--cc=hch@lst.de \
--cc=iommu@lists.linux-foundation.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=oneukum@suse.com \
--cc=shuah@kernel.org \
--cc=stern@rowland.harvard.edu \
--cc=valentina.manea.m@gmail.com \
--cc=yoshihiro.shimoda.uh@renesas.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.