All of lore.kernel.org
 help / color / mirror / Atom feed
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 18:07:09 +0900	[thread overview]
Message-ID: <20190705090708.GA3251@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1907042138091.840-100000@netrider.rowland.org>

On Thu, Jul 04, 2019 at 09:41:04PM -0400, Alan Stern wrote:
> On Fri, 5 Jul 2019, Suwan Kim wrote:
> 
> > 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.
> 
> You have a lot of leeway.  For example, there's no reason a single SG
> transfer on the client has to correspond to a single SG transfer on the
> host.  In theory the client's vhci-hcd can break a large SG transfer up
> into a bunch of smaller pieces and send them to the host one by one,
> then reassemble the results to complete the original transfer.  That
> way the memory pressure on the host would be a lot smaller than on the
> client.

Thank you for the feedback, Alan. I understood your comment. It
seems to be a good idea to use sg_tablesize to alleviate the memory
pressure of the host. But I think 16 is too small for USB 3.0 device
because USB 3.0 storage device in my machine usually uses more than
30 SG entries. So, I will set sg_tablesize to 32.

Regards

Suwan Kim

  reply	other threads:[~2019-07-05  9:07 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
2019-07-05  1:41           ` Alan Stern
2019-07-05  9:07             ` Suwan Kim [this message]
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=20190705090708.GA3251@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 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.