From: Oliver Neukum <oneukum@suse.com>
To: David Laight <David.Laight@ACULAB.COM>,
"gregKH@linuxfoundation.org" <gregKH@linuxfoundation.org>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>
Subject: UAS: fix alignment of scatter/gather segments
Date: Mon, 29 Apr 2019 17:57:25 +0200 [thread overview]
Message-ID: <1556553445.20085.21.camel@suse.com> (raw)
On Mo, 2019-04-29 at 15:06 +0000, David Laight wrote:
> From: Oliver Neukum
> > On Mo, 2019-04-29 at 14:19 +0000, David Laight wrote:
> > AFAICT controllers do not export that property.
>
> Perhaps they need to ....
Feel free to make a patch.
> > > Even if you decide the code is 'good enough' (I don't know what the
> > > cost is of enforcing a 2k alignment instead of 512 bytes)
> > > the comment is just plain wrong.
> >
> > Usually block IO will be pages. They are 4K aligned.
> > In terms of performance this code is unlikely to matter.
>
> Presumably there are some cases where the buffer isn't 4k aligned.
> I'm guessing things like 'dd' of raw disks?
Possibly.
> If the buffer has the wrong alignment then I presume a bounce buffer
> has to be allocated?
> The USB controller drivers are likely to need to be able to do that
> anyway because buffers from the network stack can have almost
> arbitrary alignment (I remember that code being horrid, I don't
> remember a data copy in the TX path).
You can ask the network layer to undo scatter/gather.
I don't see an issue.
> > But it is needed for correctness.
>
> If you are doing it for 'correctness' then you need the correct size.
Why? Any larger size will do.
> If you are doing it because you've seen too small an alignment you
> should be mentioning the failing system.
Why?
> > What would you want for the comment?
>
> You need to be more specific about the alignment requirements than
> the old comment, not far less specific.
But the statement the old comment made are no longer correct.
Regards
Oliver
WARNING: multiple messages have this Message-ID (diff)
From: Oliver Neukum <oneukum@suse.com>
To: David Laight <David.Laight@ACULAB.COM>,
"gregKH@linuxfoundation.org" <gregKH@linuxfoundation.org>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>
Subject: Re: [PATCH] UAS: fix alignment of scatter/gather segments
Date: Mon, 29 Apr 2019 17:57:25 +0200 [thread overview]
Message-ID: <1556553445.20085.21.camel@suse.com> (raw)
Message-ID: <20190429155725.y8wzHvoqNE5l5TcSVFGLfReVzDPAR8g486dOCsimHa8@z> (raw)
In-Reply-To: <ff7152940ce84722a284baf7b8566dde@AcuMS.aculab.com>
On Mo, 2019-04-29 at 15:06 +0000, David Laight wrote:
> From: Oliver Neukum
> > On Mo, 2019-04-29 at 14:19 +0000, David Laight wrote:
> > AFAICT controllers do not export that property.
>
> Perhaps they need to ....
Feel free to make a patch.
> > > Even if you decide the code is 'good enough' (I don't know what the
> > > cost is of enforcing a 2k alignment instead of 512 bytes)
> > > the comment is just plain wrong.
> >
> > Usually block IO will be pages. They are 4K aligned.
> > In terms of performance this code is unlikely to matter.
>
> Presumably there are some cases where the buffer isn't 4k aligned.
> I'm guessing things like 'dd' of raw disks?
Possibly.
> If the buffer has the wrong alignment then I presume a bounce buffer
> has to be allocated?
> The USB controller drivers are likely to need to be able to do that
> anyway because buffers from the network stack can have almost
> arbitrary alignment (I remember that code being horrid, I don't
> remember a data copy in the TX path).
You can ask the network layer to undo scatter/gather.
I don't see an issue.
> > But it is needed for correctness.
>
> If you are doing it for 'correctness' then you need the correct size.
Why? Any larger size will do.
> If you are doing it because you've seen too small an alignment you
> should be mentioning the failing system.
Why?
> > What would you want for the comment?
>
> You need to be more specific about the alignment requirements than
> the old comment, not far less specific.
But the statement the old comment made are no longer correct.
Regards
Oliver
next prev reply other threads:[~2019-04-29 15:57 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-29 12:20 UAS: fix alignment of scatter/gather segments Oliver Neukum
2019-04-29 12:20 ` [PATCH] " Oliver Neukum
2019-04-29 13:31 ` David Laight
2019-04-29 13:31 ` [PATCH] " David Laight
2019-04-29 13:38 ` Oliver Neukum
2019-04-29 13:38 ` [PATCH] " Oliver Neukum
2019-04-29 14:19 ` David Laight
2019-04-29 14:19 ` [PATCH] " David Laight
2019-04-29 14:32 ` Oliver Neukum
2019-04-29 14:32 ` [PATCH] " Oliver Neukum
2019-04-29 15:06 ` David Laight
2019-04-29 15:06 ` [PATCH] " David Laight
2019-04-29 15:57 ` Oliver Neukum [this message]
2019-04-29 15:57 ` Oliver Neukum
2019-04-29 16:08 ` Alan Stern
2019-04-29 16:08 ` [PATCH] " Alan Stern
2019-04-29 16:58 ` Oliver Neukum
2019-04-29 16:58 ` [PATCH] " Oliver Neukum
2019-04-29 17:55 ` Alan Stern
2019-04-29 17:55 ` [PATCH] " Alan Stern
2019-04-29 18:42 ` Oliver Neukum
2019-04-29 18:42 ` [PATCH] " Oliver Neukum
2019-04-29 19:42 ` Alan Stern
2019-04-29 19:42 ` [PATCH] " Alan Stern
2019-04-30 9:16 ` David Laight
2019-04-30 9:16 ` [PATCH] " David Laight
2019-04-30 14:39 ` Alan Stern
2019-04-30 14:39 ` [PATCH] " Alan Stern
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=1556553445.20085.21.camel@suse.com \
--to=oneukum@suse.com \
--cc=David.Laight@ACULAB.COM \
--cc=gregKH@linuxfoundation.org \
--cc=linux-usb@vger.kernel.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
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