| Message ID | 1708193020-14740-3-git-send-email-ssengar@linux.microsoft.com |
|---|---|
| State | New |
| Headers |
Return-Path: <linux-kernel+bounces-69992-ouuuleilei=gmail.com@vger.kernel.org>
Delivered-To: ouuuleilei@gmail.com
Received: by 2002:a05:693c:2685:b0:108:e6aa:91d0 with SMTP id mn5csp444013dyc;
Sat, 17 Feb 2024 10:05:40 -0800 (PST)
X-Forwarded-Encrypted: i=3;
AJvYcCUQjDiDSmRg4xgtSLlmNlnFvYo3FvBsIKTM8A+hpnyqt/ecsPligBeLH/GMPmFoUHOY46aLj1bmrZBL0FnLOlWlO6HC5Q==
X-Google-Smtp-Source:
AGHT+IGsbKCL7IVMsBCVpbU2Xqx+QxUOG//GNvExods8iZtEciZrNsJp0oMWpIE6olihmiL2Mpxl
X-Received: by 2002:a05:6a21:918b:b0:1a0:60b2:451 with SMTP id
tp11-20020a056a21918b00b001a060b20451mr9953064pzb.7.1708193140019;
Sat, 17 Feb 2024 10:05:40 -0800 (PST)
ARC-Seal: i=2; a=rsa-sha256; t=1708193140; cv=pass;
d=google.com; s=arc-20160816;
b=cCm5Gv7Sge9fprv0bYEh6p4/b3swJ1TYKCiPr3GxWBxSLABc6Nd3TXEWGvBA7swi/6
v+zd9OzRf3JKs/VFPIGlWlUkClMiqOGRRaHFcKZQoGvkfu7VXR8BE1cTvHhwm6xwPM8F
RqNsI0sPM14mLSjMVnh1UEyqsrrsr1B9gDUJhvuLtVkJybxjkH3FpFfvZ0aTCdIYIk2U
TT9tr+JaLET5GQca8TG+MI1gtEcBcDQd9X3sFx53Tas6c+cBqwbEgBgT3lLep4fMccK5
7cCgAlCdodoGgReUlE5yOtHPJ/OTvCitrQKMniGhnulrL5CLVfHLK9I5buHoJxUVwPhb
68uA==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com;
s=arc-20160816;
h=list-unsubscribe:list-subscribe:list-id:precedence:references
:in-reply-to:message-id:date:subject:cc:to:from:dkim-signature
:dkim-filter;
bh=f7wzYQnISkQFMWedckuhXxywKeM0U3MrfpoPt6WGRmk=;
fh=/g2YaKiPj+3FPE7qve5VOLtb1iRxoth7NZi+8r+O0Q0=;
b=SovZVdxv7ongVs3J4FLXoOoruKQWhsd4XYU3dG4BrfhxSsLVRufi1eJMq5DgqfnpEi
Sio/ROXEpBTyUMvxCI9tyz7487vV8F/MWOgDGyj7ICSIHZjFX7uIiXn0vVy9WaD31QHM
nAIpH33+BIZLCOL0ZD9QiHSIgpBJiXLfIvvOlLzCFQpsG/U1MH5NGWd2iRMrxV4JO1oe
tIghoQXBYm8IxPkxOcCeT950TwQl2aE4pqzzCsC2Ksn/aWaiPxR2gNxPoiTtQ2pdrLat
QVrwcUWJQzzViqikVK3dbUxxp3AsJ26ltNE6PDM+sXN0ryOazgxyBQOIXT32EGNYypPI
v+AQ==;
dara=google.com
ARC-Authentication-Results: i=2; mx.google.com;
dkim=pass header.i=@linux.microsoft.com header.s=default
header.b=EU2LoIpZ;
arc=pass (i=1 spf=pass spfdomain=linux.microsoft.com dkim=pass
dkdomain=linux.microsoft.com dmarc=pass fromdomain=linux.microsoft.com);
spf=pass (google.com: domain of
linux-kernel+bounces-69992-ouuuleilei=gmail.com@vger.kernel.org designates
147.75.48.161 as permitted sender)
smtp.mailfrom="linux-kernel+bounces-69992-ouuuleilei=gmail.com@vger.kernel.org";
dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.microsoft.com
Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [147.75.48.161])
by mx.google.com with ESMTPS id
x20-20020a656ab4000000b005dc3d92a492si1832495pgu.39.2024.02.17.10.05.39
for <ouuuleilei@gmail.com>
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Sat, 17 Feb 2024 10:05:40 -0800 (PST)
Received-SPF: pass (google.com: domain of
linux-kernel+bounces-69992-ouuuleilei=gmail.com@vger.kernel.org designates
147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Authentication-Results: mx.google.com;
dkim=pass header.i=@linux.microsoft.com header.s=default
header.b=EU2LoIpZ;
arc=pass (i=1 spf=pass spfdomain=linux.microsoft.com dkim=pass
dkdomain=linux.microsoft.com dmarc=pass fromdomain=linux.microsoft.com);
spf=pass (google.com: domain of
linux-kernel+bounces-69992-ouuuleilei=gmail.com@vger.kernel.org designates
147.75.48.161 as permitted sender)
smtp.mailfrom="linux-kernel+bounces-69992-ouuuleilei=gmail.com@vger.kernel.org";
dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.microsoft.com
Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org
[52.25.139.140])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sy.mirrors.kernel.org (Postfix) with ESMTPS id D4D9AB219E7
for <ouuuleilei@gmail.com>; Sat, 17 Feb 2024 18:05:22 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id B09157E769;
Sat, 17 Feb 2024 18:04:37 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (1024-bit key) header.d=linux.microsoft.com
header.i=@linux.microsoft.com header.b="EU2LoIpZ"
Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182])
by smtp.subspace.kernel.org (Postfix) with ESMTP id AAA2C7E0E7;
Sat, 17 Feb 2024 18:04:33 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
arc=none smtp.client-ip=13.77.154.182
ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1708193075; cv=none;
b=QX2X5ORDhx4tfZpPg18RIpTIo8sDt273sj85cG9PmFq7EVVSSA0/oK+f3uAWR6EH5GeXhZMbYUWANTV/HuHV4HwaG0mCxyR+MdYueidnddEipuqpLM2WICnfnJV6R1iU3MKfkVTn63B/RGEYxr25zPpsw09zbKHHm9svS3JTXVI=
ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1708193075; c=relaxed/simple;
bh=z1X7X1YCv6aHaCd20LNe+sdLH/lgI1gAQ3Ruj1baOqI=;
h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References;
b=nY6TN7hPU6DfSaLevCmDFGLhzTAT1wz9VCL+YOKHSyYC9FKR23d9qQyC4eKFD2cAfTbWOncmkG4W+nBIDew59JQS2H4d9zVQJTon2xayGU6WcQrHRa77zBVw822eaLf4qX/yKihE/CU3yNUwlInNs6iNWK54Aex8Oo+De6cO/Ik=
ARC-Authentication-Results: i=1; smtp.subspace.kernel.org;
dmarc=pass (p=none dis=none) header.from=linux.microsoft.com;
spf=pass smtp.mailfrom=linux.microsoft.com;
dkim=pass (1024-bit key) header.d=linux.microsoft.com
header.i=@linux.microsoft.com header.b=EU2LoIpZ;
arc=none smtp.client-ip=13.77.154.182
Authentication-Results: smtp.subspace.kernel.org;
dmarc=pass (p=none dis=none) header.from=linux.microsoft.com
Authentication-Results: smtp.subspace.kernel.org;
spf=pass smtp.mailfrom=linux.microsoft.com
Received: from
linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net
(linux.microsoft.com [13.77.154.182])
by linux.microsoft.com (Postfix) with ESMTPSA id 8591E207FD2E;
Sat, 17 Feb 2024 10:04:27 -0800 (PST)
DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 8591E207FD2E
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com;
s=default; t=1708193067;
bh=f7wzYQnISkQFMWedckuhXxywKeM0U3MrfpoPt6WGRmk=;
h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
b=EU2LoIpZxgjvME+yjDjLlalSytwEGhoALQOKLplBtV8MaMA8cWR0212JqWr2Viy/H
G+AwxfzKEorD1cA49iSP2G8JVJ0WH3Q5jXGl4ZwSbjXwcMaYTFXGExeii3PpVIsbyJ
6HIVe1o7EAJ5NCSVmIuIBX1GmcrmXQkCErrKx9DM=
From: Saurabh Sengar <ssengar@linux.microsoft.com>
To: kys@microsoft.com,
haiyangz@microsoft.com,
wei.liu@kernel.org,
decui@microsoft.com,
gregkh@linuxfoundation.org,
linux-hyperv@vger.kernel.org,
linux-kernel@vger.kernel.org
Cc: ssengar@microsoft.com
Subject: [PATCH 2/6] uio_hv_generic: Query the ringbuffer size for device
Date: Sat, 17 Feb 2024 10:03:36 -0800
Message-Id: <1708193020-14740-3-git-send-email-ssengar@linux.microsoft.com>
X-Mailer: git-send-email 1.8.3.1
In-Reply-To: <1708193020-14740-1-git-send-email-ssengar@linux.microsoft.com>
References: <1708193020-14740-1-git-send-email-ssengar@linux.microsoft.com>
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
X-getmail-retrieved-from-mailbox: INBOX
X-GMAIL-THRID: 1791170329842604551
X-GMAIL-MSGID: 1791170329842604551
|
| Series |
Low speed Hyper-V devices support
|
|
Commit Message
Saurabh Singh Sengar
Feb. 17, 2024, 6:03 p.m. UTC
Query the ring buffer size from pre defined table per device.
Keep the size as is if the device doesn't have any preferred
ring size.
Signed-off-by: Saurabh Sengar <ssengar@linux.microsoft.com>
---
drivers/uio/uio_hv_generic.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
Comments
On Sat, Feb 17, 2024 at 10:03:36AM -0800, Saurabh Sengar wrote: > Query the ring buffer size from pre defined table per device. > Keep the size as is if the device doesn't have any preferred > ring size. What is the "as is" size? > > Signed-off-by: Saurabh Sengar <ssengar@linux.microsoft.com> > --- > drivers/uio/uio_hv_generic.c | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/drivers/uio/uio_hv_generic.c b/drivers/uio/uio_hv_generic.c > index 20d9762331bd..4bda6b52e49e 100644 > --- a/drivers/uio/uio_hv_generic.c > +++ b/drivers/uio/uio_hv_generic.c > @@ -238,6 +238,7 @@ hv_uio_probe(struct hv_device *dev, > struct hv_uio_private_data *pdata; > void *ring_buffer; > int ret; > + size_t ring_size = hv_dev_ring_size(channel); > > /* Communicating with host has to be via shared memory not hypercall */ > if (!channel->offermsg.monitor_allocated) { > @@ -245,12 +246,14 @@ hv_uio_probe(struct hv_device *dev, > return -ENOTSUPP; > } > > + if (!ring_size) > + ring_size = HV_RING_SIZE * PAGE_SIZE; Why the magic * PAGE_SIZE here? Where is it documented that ring_size is in pages? And what happens when PAGE_SIZE is changed? Why are you relying on that arbritrary value to dictate your buffer sizes to a device that has no relationship with PAGE_SIZE? Yes, I know you are copying what was there today, but you have the chance to rethink and most importantly, DOCUMENT this decision properly now. thanks, greg k-h
On Mon, Feb 19, 2024 at 09:50:54AM +0100, Greg KH wrote: > On Sat, Feb 17, 2024 at 10:03:36AM -0800, Saurabh Sengar wrote: > > Query the ring buffer size from pre defined table per device. > > Keep the size as is if the device doesn't have any preferred > > ring size. > > What is the "as is" size? I will elaborate more here. > > > > > Signed-off-by: Saurabh Sengar <ssengar@linux.microsoft.com> > > --- > > drivers/uio/uio_hv_generic.c | 7 +++++-- > > 1 file changed, 5 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/uio/uio_hv_generic.c b/drivers/uio/uio_hv_generic.c > > index 20d9762331bd..4bda6b52e49e 100644 > > --- a/drivers/uio/uio_hv_generic.c > > +++ b/drivers/uio/uio_hv_generic.c > > @@ -238,6 +238,7 @@ hv_uio_probe(struct hv_device *dev, > > struct hv_uio_private_data *pdata; > > void *ring_buffer; > > int ret; > > + size_t ring_size = hv_dev_ring_size(channel); > > > > /* Communicating with host has to be via shared memory not hypercall */ > > if (!channel->offermsg.monitor_allocated) { > > @@ -245,12 +246,14 @@ hv_uio_probe(struct hv_device *dev, > > return -ENOTSUPP; > > } > > > > + if (!ring_size) > > + ring_size = HV_RING_SIZE * PAGE_SIZE; > > Why the magic * PAGE_SIZE here? > > Where is it documented that ring_size is in pages? > > And what happens when PAGE_SIZE is changed? Why are you relying on that > arbritrary value to dictate your buffer sizes to a device that has > no relationship with PAGE_SIZE? > > Yes, I know you are copying what was there today, but you have the > chance to rethink and most importantly, DOCUMENT this decision properly > now. I agree PAGE_SIZE is not accurate here and we should use HV_HYP_PAGE_SIZE. This can be further improved by using VMBUS_RING_SIZE macro. However, I propose addressing this improvement in a separate patch, given the are significant changes already present in this series. - Saurabh > > thanks, > > greg k-h
On Mon, Feb 19, 2024 at 01:40:23AM -0800, Saurabh Singh Sengar wrote: > On Mon, Feb 19, 2024 at 09:50:54AM +0100, Greg KH wrote: > > On Sat, Feb 17, 2024 at 10:03:36AM -0800, Saurabh Sengar wrote: > > > Query the ring buffer size from pre defined table per device. > > > Keep the size as is if the device doesn't have any preferred > > > ring size. > > > > What is the "as is" size? > > I will elaborate more here. > > > > > > > > > Signed-off-by: Saurabh Sengar <ssengar@linux.microsoft.com> > > > --- > > > drivers/uio/uio_hv_generic.c | 7 +++++-- > > > 1 file changed, 5 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/uio/uio_hv_generic.c b/drivers/uio/uio_hv_generic.c > > > index 20d9762331bd..4bda6b52e49e 100644 > > > --- a/drivers/uio/uio_hv_generic.c > > > +++ b/drivers/uio/uio_hv_generic.c > > > @@ -238,6 +238,7 @@ hv_uio_probe(struct hv_device *dev, > > > struct hv_uio_private_data *pdata; > > > void *ring_buffer; > > > int ret; > > > + size_t ring_size = hv_dev_ring_size(channel); > > > > > > /* Communicating with host has to be via shared memory not hypercall */ > > > if (!channel->offermsg.monitor_allocated) { > > > @@ -245,12 +246,14 @@ hv_uio_probe(struct hv_device *dev, > > > return -ENOTSUPP; > > > } > > > > > > + if (!ring_size) > > > + ring_size = HV_RING_SIZE * PAGE_SIZE; > > > > Why the magic * PAGE_SIZE here? > > > > Where is it documented that ring_size is in pages? > > > > And what happens when PAGE_SIZE is changed? Why are you relying on that > > arbritrary value to dictate your buffer sizes to a device that has > > no relationship with PAGE_SIZE? > > > > Yes, I know you are copying what was there today, but you have the > > chance to rethink and most importantly, DOCUMENT this decision properly > > now. > > I agree PAGE_SIZE is not accurate here and we should use HV_HYP_PAGE_SIZE. > This can be further improved by using VMBUS_RING_SIZE macro. > > However, I propose addressing this improvement in a separate patch, given > the are significant changes already present in this series. Add it as a new patch to the series makes sense, thanks! greg k-h
On Mon, Feb 19, 2024 at 11:02:54AM +0100, Greg KH wrote: > On Mon, Feb 19, 2024 at 01:40:23AM -0800, Saurabh Singh Sengar wrote: > > On Mon, Feb 19, 2024 at 09:50:54AM +0100, Greg KH wrote: > > > On Sat, Feb 17, 2024 at 10:03:36AM -0800, Saurabh Sengar wrote: > > > > Query the ring buffer size from pre defined table per device. > > > > Keep the size as is if the device doesn't have any preferred > > > > ring size. > > > > > > What is the "as is" size? > > > > I will elaborate more here. > > > > > > > > > > > > > Signed-off-by: Saurabh Sengar <ssengar@linux.microsoft.com> > > > > --- > > > > drivers/uio/uio_hv_generic.c | 7 +++++-- > > > > 1 file changed, 5 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/drivers/uio/uio_hv_generic.c b/drivers/uio/uio_hv_generic.c > > > > index 20d9762331bd..4bda6b52e49e 100644 > > > > --- a/drivers/uio/uio_hv_generic.c > > > > +++ b/drivers/uio/uio_hv_generic.c > > > > @@ -238,6 +238,7 @@ hv_uio_probe(struct hv_device *dev, > > > > struct hv_uio_private_data *pdata; > > > > void *ring_buffer; > > > > int ret; > > > > + size_t ring_size = hv_dev_ring_size(channel); > > > > > > > > /* Communicating with host has to be via shared memory not hypercall */ > > > > if (!channel->offermsg.monitor_allocated) { > > > > @@ -245,12 +246,14 @@ hv_uio_probe(struct hv_device *dev, > > > > return -ENOTSUPP; > > > > } > > > > > > > > + if (!ring_size) > > > > + ring_size = HV_RING_SIZE * PAGE_SIZE; > > > > > > Why the magic * PAGE_SIZE here? > > > > > > Where is it documented that ring_size is in pages? > > > > > > And what happens when PAGE_SIZE is changed? Why are you relying on that > > > arbritrary value to dictate your buffer sizes to a device that has > > > no relationship with PAGE_SIZE? > > > > > > Yes, I know you are copying what was there today, but you have the > > > chance to rethink and most importantly, DOCUMENT this decision properly > > > now. > > > > I agree PAGE_SIZE is not accurate here and we should use HV_HYP_PAGE_SIZE. > > This can be further improved by using VMBUS_RING_SIZE macro. > > > > However, I propose addressing this improvement in a separate patch, given > > the are significant changes already present in this series. > > Add it as a new patch to the series makes sense, thanks! Sure, will add in V2. - Saurabh > > greg k-h
diff --git a/drivers/uio/uio_hv_generic.c b/drivers/uio/uio_hv_generic.c index 20d9762331bd..4bda6b52e49e 100644 --- a/drivers/uio/uio_hv_generic.c +++ b/drivers/uio/uio_hv_generic.c @@ -238,6 +238,7 @@ hv_uio_probe(struct hv_device *dev, struct hv_uio_private_data *pdata; void *ring_buffer; int ret; + size_t ring_size = hv_dev_ring_size(channel); /* Communicating with host has to be via shared memory not hypercall */ if (!channel->offermsg.monitor_allocated) { @@ -245,12 +246,14 @@ hv_uio_probe(struct hv_device *dev, return -ENOTSUPP; } + if (!ring_size) + ring_size = HV_RING_SIZE * PAGE_SIZE; + pdata = devm_kzalloc(&dev->device, sizeof(*pdata), GFP_KERNEL); if (!pdata) return -ENOMEM; - ret = vmbus_alloc_ring(channel, HV_RING_SIZE * PAGE_SIZE, - HV_RING_SIZE * PAGE_SIZE); + ret = vmbus_alloc_ring(channel, ring_size, ring_size); if (ret) return ret;