From: Christoph Hellwig <firstname.lastname@example.org> To: Alan Stern <email@example.com> Cc: Christoph Hellwig <firstname.lastname@example.org>, Yoshihiro Shimoda <email@example.com>, Linux-Renesas <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org> Subject: Re: How to resolve an issue in swiotlb environment? Date: Wed, 12 Jun 2019 09:30:59 +0200 Message-ID: <20190612073059.GA20086@lst.de> (raw) In-Reply-To: <Pine.LNX.4.44L0.email@example.com> First things first: Yoshihiro, can you try this git branch? The new bits are just the three patches at the end, but they sit on top of a few patches already sent out to the list, so a branch is probably either: git://git.infradead.org/users/hch/misc.git scsi-virt-boundary-fixes Gitweb: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/scsi-virt-boundary-fixes And now on to the rest: > We would like to avoid the extra I/O overhead for host controllers that > can't handle SG. In fact, switching to sg_tablesize = 1 would probably > be considered a regression. Ok, makes sense. > > - set the virt boundary as-is for devices supporting "basic" scatterlist, > > although that still assumes they can rejiggle them because for example > > you could still get a smaller than expected first segment ala (assuming > > a 1024 byte packet size and thus 1023 virt_boundary_mask): > > > > | 0 .. 511 | 512 .. 1023 | 1024 .. 1535 | > > > > as the virt_bondary does not guarantee that the first segment is > > the same size as all the mid segments. > > But that is exactly the problem we need to solve. So based on the above I'm a little confused about the actual requirement again. Can you still split the SCSI command into multiple URBs? And is the boundary for that split still the scatterlist entry as in the description above? If so I don't really see how the virt_boundary helps you at all. as it only guarnatees that in a bio, each subsequent segment start as the advertised virt_boundary. It says nothing about the size of each segment. > 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: Thay is someething the virt_boundary prevents. But could still give you something like: 1536 4096 4096 1024 or 1536 16384 8192 4096 16384 512 > The ->sysdev field points to the device used for DMA mapping. It is > often the same as ->controller, but sometimes it is > ->controller->parent because of the peculiarities of some platforms. Thanks, taken into account in the above patches!
next prev parent reply index Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-06-03 6:42 Yoshihiro Shimoda 2019-06-07 12:00 ` Yoshihiro Shimoda 2019-06-10 7:31 ` Biju Das 2019-06-10 11:13 ` Yoshihiro Shimoda 2019-06-10 12:32 ` Christoph Hellwig 2019-06-10 18:46 ` Alan Stern 2019-06-11 6:41 ` Christoph Hellwig 2019-06-11 14:51 ` Alan Stern 2019-06-12 7:30 ` Christoph Hellwig [this message] 2019-06-12 8:52 ` Yoshihiro Shimoda 2019-06-12 11:31 ` Christoph Hellwig 2019-06-13 4:52 ` Yoshihiro Shimoda 2019-06-12 11:46 ` Oliver Neukum 2019-06-12 12:06 ` Christoph Hellwig 2019-06-12 14:43 ` Alan Stern 2019-06-13 7:39 ` Christoph Hellwig 2019-06-13 16:57 ` Martin K. Petersen 2019-06-13 17:16 ` Alan Stern 2019-06-13 18:18 ` Greg KH 2019-06-13 23:01 ` shuah 2019-06-14 14:44 ` Alan Stern 2019-06-18 15:28 ` shuah 2019-06-19 20:23 ` shuah 2019-06-19 21:05 ` Alan Stern 2019-06-21 17:43 ` Suwan Kim 2019-06-11 6:49 ` Yoshihiro Shimoda
Reply instructions: You may reply publically 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=20190612073059.GA20086@lst.de \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ /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
Linux-Block Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-block/0 linux-block/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-block linux-block/ https://lore.kernel.org/linux-block \ email@example.com firstname.lastname@example.org public-inbox-index linux-block Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-block AGPL code for this site: git clone https://public-inbox.org/ public-inbox