Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp2751883ybi; Thu, 4 Jul 2019 18:43:28 -0700 (PDT) X-Google-Smtp-Source: APXvYqwLXBiHV8aP8kEHdjubP+qsBZO9z4bUFCt2tCmXxUbzj1m0So+4+GjLKZkY1FAYCaBi+Se/ X-Received: by 2002:a63:5402:: with SMTP id i2mr1457835pgb.414.1562291008399; Thu, 04 Jul 2019 18:43:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1562291008; cv=none; d=google.com; s=arc-20160816; b=WjBaJoFHNqH3V87I3M2OVpjlYHFlMAr4u7GfLjY7bf3GLlwcWByzKLp9jxr8hLnocs js2xYDb29kwtKMpIOqntGlJL4M+492PLwX4L4rFs8v3DPDG2y7Pu+2/07cq6us9OwsRw ivEwNWal1xkbZju92cbiv2xjY1HdkpG6udSzlTNg+SI8WrLPyBvHnQMSG5KaFFj5pjMA OSel3D9i2iMpEHhzQL6vMWOd2keUYUcjlxNdckrXqrQ24BwudN6GjcJCl3y/SLGdPb8K gaPXmorU/2ceEQnClO0nBRDlxggFzmNKstspMgFWr8D6PYS/5lAQV3u2H8g7CxMsC5QR D5dg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:in-reply-to :subject:cc:to:from:date; bh=OOix3nv/J7dsm101+cqRV6cxIykxl/aftggz4rUHcqQ=; b=M1RiZbUAiP3LFGhRf0kfodAyHdmExGKp42jSQ0P5DgY6KMcu5gDLYGIuBmjdJ9W+dt dXDRU9o39UM7DwsgBQL/oHo4wAwmJfREy4lu0PwQGnLR4cERxm5tcZroRsnFRNHNqqVb knY2X4v9/xXFydUzLcf+oT37JbeuDjBESGJFW4My8+ZFZLc8wc4od0xFbHSJ8qbJ2+GL SUaoQGs9n0HaEI4OC0h9KguM/Y0wxBankow5zSr6D6Dm0bZGwouzWOnieq+uBN3CPZql kGCsD+62JW7v0B7Z6bUDra5JBuZZbJvjYokohg0983HK9/+U42csfS1F4W6thQR7C+0Q 7Mvw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x190si6577082pgd.402.2019.07.04.18.43.13; Thu, 04 Jul 2019 18:43:28 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727506AbfGEBlF (ORCPT + 99 others); Thu, 4 Jul 2019 21:41:05 -0400 Received: from netrider.rowland.org ([192.131.102.5]:57257 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1726871AbfGEBlF (ORCPT ); Thu, 4 Jul 2019 21:41:05 -0400 Received: (qmail 1325 invoked by uid 500); 4 Jul 2019 21:41:04 -0400 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 4 Jul 2019 21:41:04 -0400 Date: Thu, 4 Jul 2019 21:41:04 -0400 (EDT) From: Alan Stern X-X-Sender: stern@netrider.rowland.org To: Suwan Kim cc: shuah@kernel.org, , , Subject: Re: [PATCH 2/2] usbip: Implement SG support to vhci In-Reply-To: <20190704172435.GA11673@localhost.localdomain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Alan Stern