From: Suwan Kim <suwan.kim027@gmail.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: shuah@kernel.org, gregkh@linuxfoundation.org,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] usbip: Implement SG support to vhci
Date: Fri, 5 Jul 2019 02:24:37 +0900 [thread overview]
Message-ID: <20190704172435.GA11673@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1906241322140.1609-100000@iolanthe.rowland.org>
On Mon, Jun 24, 2019 at 01:24:15PM -0400, Alan Stern wrote:
> On Mon, 24 Jun 2019, Suwan Kim wrote:
>
> > > > + hcd->self.sg_tablesize = ~0;
> > > > + hcd->self.no_sg_constraint = 1;
> > >
> > > You probably shouldn't do this, for two reasons. First, sg_tablesize
> > > of the server's HCD may be smaller than ~0. If the client's value is
> > > larger than the server's, a transfer could be accepted on the client
> > > but then fail on the server because the SG list was too big.
>
> On the other hand, I don't know of any examples where an HCD has
> sg_tablesize set to anything other than 0 or ~0. vhci-hcd might end up
> being the only one.
>
> > > Also, you may want to restrict the size of SG transfers even further,
> > > so that you don't have to allocate a tremendous amount of memory all at
> > > once on the server. An SG transfer can be quite large. I don't know
> > > what a reasonable limit would be -- 16 perhaps?
> >
> > Is there any reason why you think that 16 is ok? Or Can I set this
> > value as the smallest value of all HC? I think that sg_tablesize
> > cannot be a variable value because vhci interacts with different
> > machines and all machines has different sg_tablesize value.
>
> I didn't have any good reason for picking 16. Using the smallest value
> of all the HCDs seems like a good idea.
I also have not seen an HCD with a value other than ~0 or 0 except for
whci which uses 2048, but is not 2048 the maximum value of sg_tablesize?
If so, ~0 is the minimum value of sg_tablesize that supports SG. Then
can vhci use ~0 if we don't consider memory pressure of the server?
If all of the HCDs supporting SG have ~0 as sg_tablesize value, I
think that whether we use an HCD locally or remotely, the degree of
memory pressure is same in both local and remote usage.
Regards
Suwan Kim
next prev parent reply other threads:[~2019-07-04 17:24 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-21 17:45 [PATCH 0/2] usbip: Implement SG support to vhci Suwan Kim
2019-06-21 17:45 ` [PATCH 1/2] usbip: Skip DMA mapping and unmapping for urb at vhci Suwan Kim
2019-06-29 0:11 ` shuah
2019-07-01 9:29 ` Suwan Kim
2019-06-21 17:45 ` [PATCH 2/2] usbip: Implement SG support to vhci Suwan Kim
2019-06-21 20:05 ` Alan Stern
2019-06-24 14:58 ` Suwan Kim
2019-06-24 17:24 ` Alan Stern
2019-07-04 17:24 ` Suwan Kim [this message]
2019-07-05 1:41 ` Alan Stern
2019-07-05 9:07 ` Suwan Kim
2019-06-22 10:40 ` kbuild test robot
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=20190704172435.GA11673@localhost.localdomain \
--to=suwan.kim027@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=shuah@kernel.org \
--cc=stern@rowland.harvard.edu \
/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;
as well as URLs for NNTP newsgroup(s).