Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp3112987ybi; Fri, 5 Jul 2019 02:08:27 -0700 (PDT) X-Google-Smtp-Source: APXvYqzqivNbVNbpqqADRjRMbvNXUr4aa9iYZqgOkEUuvZ69rjyWwMEO/64wjJUwplCtEZOPgwwl X-Received: by 2002:a17:902:1e7:: with SMTP id b94mr4082882plb.333.1562317707012; Fri, 05 Jul 2019 02:08:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1562317707; cv=none; d=google.com; s=arc-20160816; b=oJ6nq3UeQYOrgymT+2TP/XX8NQNjhOt5wG+vvqEJQl+NTPJdi5bpF+6gT4/tLHNrz1 0rC9amlK3W7EBkD0ft0lk4/nHNsnMn1/mIRmX2PbA4k4AFRdAYn4iFccVEIvDYglCir9 JMW4nrQX/z5LCSrnCSXeZuLbq79ircMPVh4d8HSc+NV2gqrn68SWV0Iyt53/5mlsmaLQ 2iLEE56quWv/Hdy5Ol2OnMtiH/afnYx3Seq6ROWjFPh/0y/XXs+EtQMr/VOhW9djom7I xx0V/4misEdulzGKgFrPxwZAy4OVJdUCdTM9pMyY6v3M/zTpk78TjdUQ+sh8WuWkTpoV uVHg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=oAbtO0VVEgPrns4ECpP/l7PElOulKUdNK8WJ9smHNMY=; b=ONi/cn9MhZ6Ka6fx65Tc8bSNjB5YReRX94BOKVbKFsgU2+uCcvwDSrazeMuiSz11gB FPQ6icZ0fLq+v1GUccv4UQhw6E9hb15e4maP2bgSI2VhhuphZKEDLirY0svmStmSCxA6 BM0RpMZ/hsR9brXVB8my+AELKkk+q0vs9v9shDoiZk7l95CGbxXL3gU3zH216fu6kLQg lwHx3ZBy6N7SapfY4iRbeg+TuHlKnrytKZ8EQMd8kGcSczyhyXlLddzH63ks4qLehX/R 90tGzvgNSp3EV5NxAkizU9xPMrIO+66QQGZICsOwWaPvBa50oDOB6045YBfUFk6KjjM5 aB8Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Tgep8XUS; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y13si8068706pgq.172.2019.07.05.02.08.11; Fri, 05 Jul 2019 02:08:26 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Tgep8XUS; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728102AbfGEJHQ (ORCPT + 99 others); Fri, 5 Jul 2019 05:07:16 -0400 Received: from mail-pg1-f195.google.com ([209.85.215.195]:33742 "EHLO mail-pg1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726116AbfGEJHP (ORCPT ); Fri, 5 Jul 2019 05:07:15 -0400 Received: by mail-pg1-f195.google.com with SMTP id m4so4035221pgk.0; Fri, 05 Jul 2019 02:07:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=oAbtO0VVEgPrns4ECpP/l7PElOulKUdNK8WJ9smHNMY=; b=Tgep8XUSV0dm/4njOv+mq3T9bmSTqiX2/FXEOlNqGtx6ARJjfBTy7NN3QIRxz+fDwf a5nYIv9Z26yE+U4P8icDrSSzw2c33eauBtLiQkMaOwZSW14zK21kIsQHZT/gPkHMGlQU sWme3teVQ7zob+AJqr3DZIV5TaJHR6Vo1cm6mjfjPcoWq28iB54FPan93CNGTzLgUiVK Jurj+8efcZJSx0U4m7zoZYxeNpMDkvyktFmW+RjxOe3hVAGD4yI0EOL1Q+d0KWZASk6Z QbpLmcrgRhHTC3LZ2KX2Ri9NtzBXM1VsnxZreuqJxgeA0DeJxl9oYN/Q+hbaCplVXpIh iiQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=oAbtO0VVEgPrns4ECpP/l7PElOulKUdNK8WJ9smHNMY=; b=WO62YA4W7nU9TrxrqKxXvP+oecgqnQllLhxRSXjiHxIapJmVK9fEJw9Ksm82RZZHgq /cgvPZiHiyV+ThxHOFXZxffxS2ioAL+elOUKOz+QBX44C5Bz/tceTATr5KHDgbMMiw6e dCucNwDWsXThS5qWJ5my+hDcv2v48GyCgQkBwzRon65BByi5ImlU0XqPpHqDkbNEVvPT rzR4f8YRp58hZfe2hGNZMpDQ84bJmJXV1oilBjZX2jIoHqrfQvwv53rPhOjQqQqzIPO3 Y2Ah9HHx1Lnaf4ee2PEvK1W0q+4waUc8/g4AloZwMD+7QgSnMwV777yR+/AgafXA/BSS O8SA== X-Gm-Message-State: APjAAAV4+yZj4/JslhZ9t4SeSblG9VDB45HA93kPfwMqOqzoBWF85Ggk 12IGLHx2v02jdypXuHmL1AA= X-Received: by 2002:a17:90a:1aa4:: with SMTP id p33mr4012219pjp.27.1562317634927; Fri, 05 Jul 2019 02:07:14 -0700 (PDT) Received: from localhost.localdomain ([163.152.162.99]) by smtp.gmail.com with ESMTPSA id x26sm8587339pfq.69.2019.07.05.02.07.13 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Fri, 05 Jul 2019 02:07:14 -0700 (PDT) Date: Fri, 5 Jul 2019 18:07:09 +0900 From: Suwan Kim To: Alan Stern 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 Message-ID: <20190705090708.GA3251@localhost.localdomain> References: <20190704172435.GA11673@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.3 (2019-02-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.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