> From: Michael S. Tsirkin
> Sent: Tuesday, October 31, 2023 5:02 AM
>
> On Mon, Oct 30, 2023 at 06:10:06PM +, Parav Pandit wrote:
> >
> >
> > > From: Michael S. Tsirkin
> > > Sent: Monday, October 30, 2023 9:29 PM On Mon, Oct 30, 2023 at
> > > 03:51:40PM +, Parav Pandit wrote:
> > >
> From: Michael S. Tsirkin
> Sent: Tuesday, October 31, 2023 1:29 PM
>
> On Tue, Oct 31, 2023 at 03:11:57AM +, Parav Pandit wrote:
> >
> >
> > > From: Michael S. Tsirkin
> > > Sent: Tuesday, October 31, 2023 5:02 AM
> > >
> > > On Mon, Oct 30, 2023 at 06:10:06PM +, Parav Pandit wrote:
> From: Michael S. Tsirkin
> Sent: Thursday, October 26, 2023 6:45 PM
> > Followed by an open coded driver check for 0x1000 to 0x103f range.
> > Do you mean windows driver expects specific subsystem vendor id of 0x1af4?
>
> Look it up, it's open source.
Those are not OS inbox drivers anyway.
> From: Michael S. Tsirkin
> Sent: Thursday, October 26, 2023 5:42 PM
>
> On Thu, Oct 26, 2023 at 03:08:12PM +0300, Yishai Hadas wrote:
> > > > Makes sense ?
> > > So do I understand correctly that virtio dictates the subsystem
> > > device ID for all subsystem vendor IDs that implement a legacy
> From: Michael S. Tsirkin
> Sent: Thursday, October 26, 2023 8:36 PM
>
> On Thu, Oct 26, 2023 at 01:28:18PM +, Parav Pandit wrote:
> >
> > > From: Michael S. Tsirkin
> > > Sent: Thursday, October 26, 2023 6:45 PM
> >
> > > > Followed by an open coded driver check for 0x1000 to 0x103f
> From: Michael S. Tsirkin
> Sent: Thursday, October 26, 2023 9:16 PM
> On Thu, Oct 26, 2023 at 03:09:13PM +, Parav Pandit wrote:
> >
> > > From: Michael S. Tsirkin
> > > Sent: Thursday, October 26, 2023 8:36 PM
> > >
> > > On Thu, Oct 26, 2023 at 01:28:18PM +, Parav Pandit wrote:
> >
> From: Michael S. Tsirkin
> Sent: Monday, October 30, 2023 1:53 AM
>
> On Sun, Oct 29, 2023 at 05:59:45PM +0200, Yishai Hadas wrote:
> > From: Feng Liu
> >
> > Introduce support for the admin virtqueue. By negotiating
> > VIRTIO_F_ADMIN_VQ feature, driver detects capability and creates one
> From: Michael S. Tsirkin
> Sent: Monday, October 30, 2023 9:29 PM
> On Mon, Oct 30, 2023 at 03:51:40PM +, Parav Pandit wrote:
> >
> >
> > > From: Michael S. Tsirkin
> > > Sent: Monday, October 30, 2023 1:53 AM
> > >
> > > On Sun, Oct 29, 2023 at 05:59:45PM +0200, Yishai Hadas wrote:
> >
> From: Jason Gunthorpe
> Sent: Friday, September 22, 2023 5:53 PM
> > And what's more, using MMIO BAR0 then it can work for legacy.
>
> Oh? How? Our team didn't think so.
It does not. It was already discussed.
The device reset in legacy is not synchronous.
The drivers do not wait for reset
> From: Michael S. Tsirkin
> Sent: Thursday, September 21, 2023 10:31 PM
> Another question I'm interested in is whether there's actually a performance
> benefit to using this as compared to just software vhost. I note there's a VM
> exit
> on each IO access, so ... perhaps?
> Would be nice
> From: Michael S. Tsirkin
> Sent: Tuesday, September 26, 2023 10:30 PM
> For example, a transitional device
> must not in theory be safely passed through to guest userspace, because guest
> then might try to use it through the legacy BAR without acknowledging
> ACCESS_PLATFORM.
> Do any
> From: Michael S. Tsirkin
> Sent: Friday, September 22, 2023 9:23 PM
> > +static int virtiovf_pci_probe(struct pci_dev *pdev,
> > + const struct pci_device_id *id) {
> > + const struct vfio_device_ops *ops = _acc_vfio_pci_ops;
> > + struct virtiovf_pci_core_device
> From: Jason Wang
> Sent: Tuesday, September 26, 2023 10:08 AM
> Right, so if we'd consider migration from virtio to vDPA, it needs to be
> designed
> in a way that allows more involvement from hypervisor other than coupling it
> with a specific interface (like admin virtqueues).
It is not
> From: Jason Wang
> Sent: Tuesday, September 26, 2023 8:03 AM
>
> It's the implementation details in legacy. The device needs to make sure
> (reset)
> the driver can work (is done before get_status return).
It is part of the 0.9.5 and 1.x specification as I quoted those text above.
> From: Michael S. Tsirkin
> Sent: Tuesday, September 26, 2023 12:06 AM
> One can thinkably do that wait in hardware, though. Just defer completion
> until
> read is done.
>
Once OASIS does such new interface and if some hw vendor _actually_ wants to do
such complex hw, may be vfio driver
> From: Jason Wang
> Sent: Tuesday, September 26, 2023 10:07 AM
>
> If you can't find a way to make legacy drivers work, use modern.
>
Understood.
This vfio series make the legacy drivers work.
Thanks.
> That's it.
>
> Thanks
___
> From: Jason Wang
> Sent: Monday, September 25, 2023 8:00 AM
>
> On Fri, Sep 22, 2023 at 8:25 PM Parav Pandit wrote:
> >
> >
> > > From: Jason Gunthorpe
> > > Sent: Friday, September 22, 2023 5:53 PM
> >
> >
> > > > And what's more, using MMIO BAR0 then it can work for legacy.
> > >
> > >
> From: Jason Gunthorpe
> Sent: Friday, September 22, 2023 6:07 PM
>
> On Thu, Sep 21, 2023 at 01:58:32PM -0600, Alex Williamson wrote:
>
> > If the heart of this driver is simply pretending to have an I/O BAR
> > where I/O accesses into that BAR are translated to accesses in the
> > MMIO
> From: Michael S. Tsirkin
> Sent: Thursday, October 12, 2023 4:23 PM
>
> On Tue, Sep 26, 2023 at 03:45:36AM +, Parav Pandit wrote:
> >
> >
> > > From: Michael S. Tsirkin
> > > Sent: Tuesday, September 26, 2023 12:06 AM
> >
> > > One can thinkably do that wait in hardware, though. Just
> From: Michael S. Tsirkin
> Sent: Thursday, October 12, 2023 5:00 PM
> I am instead talking about devices that work with existing legacy linux
> drivers
> with no traps.
>
Yep, I understood.
> > I am not expecting OASIS to do anything extra for legacy registers.
> >
> > [1] The device MUST
> From: Alex Williamson
> Sent: Wednesday, October 18, 2023 6:22 PM
> Are we realistically extending this beyond virtio-net? Maybe all the
> descriptions
> should be limited to what is actually supported as proposed rather than
> aspirational goals. Thanks,
Virtio blk would the second user
> From: Yishai Hadas
> Sent: Tuesday, October 10, 2023 9:14 PM
>
> On 10/10/2023 18:14, Michael S. Tsirkin wrote:
> > On Tue, Oct 10, 2023 at 06:09:44PM +0300, Yishai Hadas wrote:
> >> On 10/10/2023 17:54, Michael S. Tsirkin wrote:
> >>> On Tue, Oct 10, 2023 at 11:08:49AM -0300, Jason
> From: Jason Gunthorpe
> Sent: Tuesday, October 10, 2023 9:37 PM
>
> On Tue, Oct 10, 2023 at 12:03:29PM -0400, Michael S. Tsirkin wrote:
> > On Tue, Oct 10, 2023 at 12:59:37PM -0300, Jason Gunthorpe wrote:
> > > On Tue, Oct 10, 2023 at 11:14:56AM -0400, Michael S. Tsirkin wrote:
> > >
> > > >
Hi Christoph,
> From: Christoph Hellwig
> Sent: Wednesday, October 11, 2023 12:29 PM
>
> On Wed, Oct 11, 2023 at 02:43:37AM -0400, Michael S. Tsirkin wrote:
> > > Btw, what is that intel thing everyone is talking about? And why
> > > would the virtio core support vendor specific behavior like
> From: Alexander H Duyck
> Sent: Friday, January 13, 2023 6:24 PM
>
> On Sat, 2023-01-14 at 00:36 +0200, Parav Pandit wrote:
> > A smallest Ethernet frame defined by IEEE 802.3 is 60 bytes without
> > any preemble and CRC.
> >
> > Current code only checks for minimal 14 bytes of Ethernet
virtnet_rq_free_unused_buf() helper function to free the buffer
already exists. Avoid code duplication by reusing existing function.
Signed-off-by: Parav Pandit
---
drivers/net/virtio_net.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/net/virtio_net.c
A smallest Ethernet frame defined by IEEE 802.3 is 60 bytes without any
preemble and CRC.
Current code only checks for minimal 14 bytes of Ethernet header length.
Correct it to consider the minimum Ethernet frame length.
Fixes: 296f96fcfc16 ("Net driver using virtio")
Signed-off-by: Parav Pandit
Hi,
These two changes improve the small packet handling.
Patch summary:
patch-1 fixes the length check by considering Ethernet 60B frame size
patch-2 avoids code duplication by reuses existing buffer free helper
Please review.
Parav Pandit (2):
virtio_net: Fix short frame length check
virtnet_rq_free_unused_buf() helper function to free the buffer
already exists. Avoid code duplication by reusing existing function.
Reviewed-by: Alexander Duyck
Reviewed-by: Xuan Zhuo
Signed-off-by: Parav Pandit
---
drivers/net/virtio_net.c | 8 +---
1 file changed, 1 insertion(+), 7
> From: Michael S. Tsirkin
> Sent: Monday, January 16, 2023 5:13 PM
>
> On Mon, Jan 16, 2023 at 10:27:08PM +0200, Parav Pandit wrote:
> > virtnet_rq_free_unused_buf() helper function to free the buffer
> > already exists. Avoid code duplication by reusing existing function.
> >
> >
> From: Alexander Duyck
> Sent: Friday, January 13, 2023 7:24 PM
>
> On Fri, Jan 13, 2023 at 3:37 PM Parav Pandit wrote:
> >
> >
> > > From: Alexander H Duyck
> > > Sent: Friday, January 13, 2023 6:24 PM
> > >
> > > On Sat, 2023-01-14 at 00:36 +0200, Parav Pandit wrote:
> > > > A smallest
Hi Jakub, Dave,
> From: Parav Pandit
> Sent: Friday, January 13, 2023 5:36 PM
>
> Hi,
>
> These two changes improve the small packet handling.
>
> Patch summary:
> patch-1 fixes the length check by considering Ethernet 60B frame size
> patch-2 avoids code duplication by reuses existing buffer
virtio queue index can be maximum of 65535. 16 bytes are enough to store
the vq name with the existing string prefix.
With this change, send queue struct saves 24 bytes and receive
queue saves whole cache line worth 64 bytes per structure
due to saving in alignment bytes.
Pahole results before:
> From: Si-Wei Liu
> Sent: Tuesday, January 31, 2023 6:22 PM
>
> In below example, before the fix, mtu attribute is supported by the parent
> mgmtdev, but the error message showing "All provided are not supported" is
> just misleading.
>
> $ vdpa mgmtdev show
> vdpasim_net:
>
Hi,
This two small patches improves ndo_close() callback to follow
the mirror sequence of ndo_open() callback. This improves the code auditing
and also ensure that xdp rxq info is not unregistered while NAPI on
RXQ is ongoing.
Please review.
Patch summary:
patch-1 ensures that xdp rq info is
Cited commit in fixes tag frees rxq xdp info while RQ NAPI is
still enabled and packet processing may be ongoing.
Follow the mirror sequence of open() in the stop() callback.
This ensures that when rxq info is unregistered, no rx
packet processing is ongoing.
Fixes: 754b8a21a96d ("virtio_net:
> From: Si-Wei Liu
> Sent: Tuesday, January 31, 2023 6:22 PM
>
> The spec says:
> status only exists if VIRTIO_NET_F_STATUS is set
>
> Similar to MAC and MTU, vdpa_dev_net_config_fill() should read STATUS
> conditionally depending on the feature bits.
>
> Signed-off-by: Si-Wei Liu
>
> From: Si-Wei Liu
> Sent: Tuesday, January 31, 2023 6:22 PM
>
> With device feature provisioning, there's a chance for misconfiguration that
> the
> vdpa feature attribute supplied in 'vdpa dev add' command doesn't get
> selected on the device_features to be provisioned. For instance, when
> From: Feng Liu
> Sent: Friday, March 10, 2023 12:34 AM
>
> - if (!is_power_of_2(num)) {
> - dev_warn(_dev->pci_dev->dev, "bad queue size %u",
> num);
> - return ERR_PTR(-EINVAL);
> - }
> -
The check is still valid for split q.
Maybe the right place for such
> From: Jiri Pirko
> Sent: Tuesday, February 21, 2023 9:48 AM
>
> From: Jiri Pirko
>
> Virtio spec introduced a feature VIRTIO_NET_F_GUEST_HDRLEN which when
> set implicates that the driver provides the exact size of the header.
>
> Quoting the original virtio spec:
> "hdr_len is a hint to
On 4/3/2023 12:20 PM, Eli Cohen wrote:
Hi,
the single patch in this series adds support for posted interrupts in
mlx5.
It depends on the patch series already accpted can be seen here:
https://patchwork.kernel.org/project/netdevbpf/patch/20230324231341.29808-1-sa...@kernel.org/
git pull
On 4/3/2023 12:20 PM, Eli Cohen wrote:
Add support for generation of interrupts from the device directly to the
VM to the VCPU thus avoiding the overhead on the host CPU.
When supported, the driver will attempt to allocate vectors for each
data virtqueue. If a vector for a virtqueue cannot
To easily audit the code, better to keep the device stop()
sequence to be mirror of the device open() sequence.
Acked-by: Michael S. Tsirkin
Reviewed-by: Jiri Pirko
Signed-off-by: Parav Pandit
---
drivers/net/virtio_net.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
> From: Jiri Pirko
> Sent: Thursday, February 2, 2023 10:47 AM
>
> Thu, Feb 02, 2023 at 04:10:56PM CET, pa...@nvidia.com wrote:
> >
> >> From: Jiri Pirko
> >> Sent: Thursday, February 2, 2023 7:26 AM
> >>
> >> Thu, Feb 02, 2023 at 06:00:38AM CET, pa...@nvidia.com wrote:
> >> >To easily audit
> From: Jiri Pirko
> Sent: Thursday, February 2, 2023 7:26 AM
>
> Thu, Feb 02, 2023 at 06:00:38AM CET, pa...@nvidia.com wrote:
> >To easily audit the code, better to keep the device stop() sequence to
> >be mirror of the device open() sequence.
> >
> >Signed-off-by: Parav Pandit
>
>
Cited commit in fixes tag frees rxq xdp info while RQ NAPI is
still enabled and packet processing may be ongoing.
Follow the mirror sequence of open() in the stop() callback.
This ensures that when rxq info is unregistered, no rx
packet processing is ongoing.
Fixes: 754b8a21a96d ("virtio_net:
> From: Si-Wei Liu
> Sent: Thursday, February 2, 2023 4:59 PM
>
> On 2/1/2023 9:05 PM, Parav Pandit wrote:
> >
> >> From: Si-Wei Liu
> >> Sent: Tuesday, January 31, 2023 6:22 PM
> >>
> >> With device feature provisioning, there's a chance for
> >> misconfiguration that the vdpa feature
> From: Feng Liu
> Sent: Tuesday, May 2, 2023 8:35 PM
> Issue: 3383038
Remove this internal garbage.
> Fixes: 754b8a21a96d ("virtio_net: setup xdp_rxq_info")
> Signed-off-by: Feng Liu
> Reviewed-by: William Tu
> Reviewed-by: Parav Pandit
> Reviewed-by: Simon Horman
> Acked-by: Michael S.
> From: Jason Wang
> Sent: Thursday, August 19, 2021 9:52 AM
>
> 在 2021/8/19 上午1:33, Michael S. Tsirkin 写道:
> > On Wed, Aug 18, 2021 at 12:31:39PM +0800, Jason Wang wrote:
> >> On Wed, Aug 18, 2021 at 11:15 AM Parav Pandit
> wrote:
> >>>
> >>>
> From: Michael S. Tsirkin
> Sent:
> From: Michael S. Tsirkin
> Sent: Tuesday, August 17, 2021 2:24 AM
>
> On Mon, Aug 09, 2021 at 09:51:49AM +, Parav Pandit wrote:
> > > From: Michael S. Tsirkin
> > > Sent: Monday, August 9, 2021 3:10 PM
> > >
> > > On Fri, Aug 06, 2021 at 08:55:56AM +, Parav Pandit wrote:
> > > >
>
> From: Jason Wang
> Sent: Wednesday, August 18, 2021 10:02 AM
> On Wed, Aug 18, 2021 at 11:15 AM Parav Pandit wrote:
[..]
> > > I'm inclined to say vxlan is closer to a model to follow.
> > Ok. thanks for the feedback. We are using the model close to vxlan.
> > Lets resolve should we have it
> From: Eli Cohen
> Sent: Monday, August 16, 2021 10:27 PM
>
> It works fine when I am working with your version of qemu with support for
> multi queue.
>
> The problem is that it is broken on qemu v6.0.0. If I register my vdpa device
> with more than 2 data virtqueues, qemu won't even create a
> From: Jason Wang
> Sent: Tuesday, August 17, 2021 9:26 AM
>
> On Tue, Aug 17, 2021 at 3:37 AM Michael S. Tsirkin
> wrote:
> >
> > On Mon, Aug 16, 2021 at 07:56:59PM +0300, Eli Cohen wrote:
> > > On Mon, Aug 16, 2021 at 01:58:06PM +0800, Jason Wang wrote:
> > > >
> > > > 在 2021/8/16 下午1:47,
Hi Michael,
> From: Parav Pandit
> Sent: Thursday, July 29, 2021 10:09 AM
>
> Hi Michael,
>
> > From: Parav Pandit
> > Sent: Wednesday, July 21, 2021 7:57 PM
> > To: m...@redhat.com; virtualization@lists.linux-foundation.org
> > Cc: Parav Pandit
> > Subject: [PATCH v3 0/4] virtio short
> From: Eli Cohen
> Sent: Monday, August 9, 2021 11:38 AM
>
> On Mon, Aug 09, 2021 at 09:01:48AM +0300, Parav Pandit wrote:
> >
> >
> > > From: Eli Cohen
> > > Sent: Monday, August 9, 2021 11:28 AM
> > >
> > > On Mon, Aug 09, 2021 at 08:42:58AM +0300, Parav Pandit wrote:
> > > >
> > > >
> > >
> From: Eli Cohen
> Sent: Monday, August 9, 2021 10:51 AM
>
> On Mon, Aug 09, 2021 at 11:07:50AM +0800, Jason Wang wrote:
> >
> > 在 2021/8/6 下午4:55, Parav Pandit 写道:
> > >
> > > > From: Michael S. Tsirkin
> > > > Sent: Friday, August 6, 2021 2:12 PM
> > >
> > > > > enum vdpa_attr {
> > > >
Hi Jason,
> From: Jason Wang
> Sent: Monday, August 9, 2021 8:38 AM
> > For example creator (hypervisor) of the vdpa devices knows that a
> > guest VM is given 4 vcpus, So hypervisor creates a vdpa devices with
> > config space layout as, max_virtqueue_pairs = 4.
> > And the MAC address chosen
Hi Michael,
> From: Virtualization On
> Behalf Of Parav Pandit via Virtualization
> Hi Michael,
>
> > From: Parav Pandit
> > Sent: Thursday, July 29, 2021 10:09 AM
> >
> > Hi Michael,
> >
> > > From: Parav Pandit
> > > Sent
> From: Eli Cohen
> Sent: Monday, August 9, 2021 11:28 AM
>
> On Mon, Aug 09, 2021 at 08:42:58AM +0300, Parav Pandit wrote:
> >
> >
> > > From: Eli Cohen
> > > Sent: Monday, August 9, 2021 10:51 AM
> > >
> > > On Mon, Aug 09, 2021 at 11:07:50AM +0800, Jason Wang wrote:
> > > >
> > > > 在
> From: Michael S. Tsirkin
> Sent: Monday, August 9, 2021 3:10 PM
>
> On Fri, Aug 06, 2021 at 08:55:56AM +, Parav Pandit wrote:
> >
> >
> > >
> > > The point is to try and not reinvent a dedicated vpda interface
> > > where a generic one exits.
> > > E.g. for phy things such as mac speed
Enable user to disable RDMA auxiliary device so that when it is not
required, user can disable it.
For example,
$ devlink dev param set pci/:06:00.0 \
name enable_rdma value false cmode driverinit
$ devlink dev reload pci/:06:00.0
At this point devlink instance do not
Enable user to disable Ethernet auxiliary device so that when it is not
required, user can disable it.
For example,
$ devlink dev param set pci/:06:00.0 \
name enable_eth value false cmode driverinit
$ devlink dev reload pci/:06:00.0
At this point devlink instance do not
Cleanup routine missed to unpublish the parameters. Add it.
Fixes: e890acd5ff18 ("net/mlx5: Add devlink flow_steering_mode parameter")
Signed-off-by: Parav Pandit
Reviewed-by: Jiri Pirko
Reviewed-by: Leon Romanovsky
---
drivers/net/ethernet/mellanox/mlx5/core/devlink.c | 1 +
1 file changed,
Enable drivers to publish/unpublish individual parameter.
Signed-off-by: Parav Pandit
Reviewed-by: Jiri Pirko
Reviewed-by: Leon Romanovsky
---
include/net/devlink.h | 4
net/core/devlink.c| 48 +++
2 files changed, 52 insertions(+)
diff --git
Enable user to disable VDPA net auxiliary device so that when it is not
required, user can disable it.
For example,
$ devlink dev param set pci/:06:00.0 \
name enable_vnet value false cmode driverinit
$ devlink dev reload pci/:06:00.0
At this point devlink instance do not
Add new device generic parameter to enable/disable creation of
Ethernet auxiliary device and associated device functionality
in the devlink instance.
User who prefers to disable such functionality can disable it using below
example.
$ devlink dev param set pci/:06:00.0 \
name
Add new device generic parameter to enable/disable creation of
VDPA net auxiliary device and associated device functionality
in the devlink instance.
User who prefers to disable such functionality can disable it using below
example.
$ devlink dev param set pci/:06:00.0 \
name
Currently device configuration parameters can be registered as an array.
Due to this a constant array must be registered. A single driver
supporting multiple devices each with different device capabilities end
up registering all parameters even if it doesn't support it.
One possible workaround a
Add new device generic parameter to enable/disable creation of
RDMA auxiliary device and associated device functionality
in the devlink instance.
User who prefers to disable such functionality can disable it using below
example.
$ devlink dev param set pci/:06:00.0 \
name
(Resend to CC RDMA and vdpa mailing lists).
Hi Dave, Jakub,
Currently, for mlx5 multi-function device, a user is not able to control
which functionality to enable/disable. For example, each PCI
PF, VF, SF function by default has netdevice, RDMA and vdpa-net
devices always enabled.
Hence, enable
Create and use a helper function for one parameter registration.
Subsequent patch also will reuse this for driver facing routine to
register a single parameter.
Signed-off-by: Parav Pandit
Reviewed-by: Jiri Pirko
Reviewed-by: Leon Romanovsky
---
net/core/devlink.c | 24
> From: Michael S. Tsirkin
> Sent: Friday, August 6, 2021 2:12 PM
> > enum vdpa_attr {
> > @@ -33,6 +34,16 @@ enum vdpa_attr {
> > VDPA_ATTR_DEV_MAX_VQS, /* u32 */
> > VDPA_ATTR_DEV_MAX_VQ_SIZE, /* u16 */
> > + VDPA_ATTR_DEV_NET_CFG_MACADDR,
> From: Michael S. Tsirkin
> Sent: Thursday, August 5, 2021 3:28 PM
>
> On Wed, Jun 16, 2021 at 10:11:49PM +0300, Parav Pandit wrote:
> > Currently user cannot set the mac address and mtu of the vdpa device.
> > This patchset enables users to set the mac address and mtu of the vdpa
> > device
Hi Michael,
> From: Parav Pandit
> Sent: Wednesday, July 21, 2021 7:57 PM
> To: m...@redhat.com; virtualization@lists.linux-foundation.org
> Cc: Parav Pandit
> Subject: [PATCH v3 0/4] virtio short improvements
>
> Hi,
>
> This series contains small improvements for virtio pci driver.
> The
Currently user cannot view the vdpa device config space. Also user
cannot set the mac address and mtu of the vdpa device.
This patchset enables users to set the mac address and mtu of the vdpa
device once the device is created.
If a vendor driver supports such configuration user can set it
Subsequent patches enable get and set configuration either
via management device or via vdpa device' config ops.
This requires synchronization between multiple callers to get and set
config callbacks. Features setting also influence the layout of the
configuration fields endianness.
To avoid
As subsequent patch adds new structure field with comment, move the
structure comment to follow kernel coding style.
Signed-off-by: Parav Pandit
Reviewed-by: Eli Cohen
---
include/linux/vdpa.h | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/include/linux/vdpa.h
Introduce a command to query a device config layout.
An example query of network vdpa device:
$ vdpa dev add name bar mgmtdev vdpasim_net
$ vdpa dev config show
bar: mac 00:35:09:19:48:05 link up link_announce false mtu 1500
$ vdpa dev config show -jp
{
"config": {
"bar": {
$ vdpa dev add name bar mgmtdev vdpasim_net mac 00:11:22:33:44:55 mtu 9000
$ vdpa dev config show
bar: mac 00:11:22:33:44:55 link up link_announce false mtu 9000
$ vdpa dev config show -jp
{
"config": {
"bar": {
"mac": "00:11:22:33:44:55",
"link ": "up",
Enable user to set the mac address and mtu so that each vdpa device
can have its own user specified mac address and mtu.
This is done by implementing the management device's configuration
layout fields setting callback routine.
Now that user is enabled to set the mac address, remove the module
From: Eli Cohen
Add code to accept MAC configuration through vdpa tool. The MAC is
written into the config struct and later can be retrieved through
get_config().
Examples:
1. Configure MAC while adding a device:
$ vdpa dev add mgmtdev pci/:06:00.2 name vdpa0 mac 00:11:22:33:44:55
2. Show
Cited patch in the fixes tag clears the features bit during reset.
mlx5 vdpa device feature bits are static decided by device capabilities.
Clearing features bit cleared the VIRTIO_NET_F_MAC. Due to this MAC address
provided by the device is not honored.
Fix it by not clearing the static feature
From: Eli Cohen
Add rules to forward packets to the net device's TIR only if the
destination MAC is equal to the configured MAC. This is required to
prevent the netdevice from receiving traffic not destined to its
configured MAC.
Signed-off-by: Eli Cohen
Reviewed-by: Parav Pandit
---
Hi Michael,
> From: Michael S. Tsirkin
> Sent: Friday, October 22, 2021 4:11 PM
>
> On Thu, Oct 21, 2021 at 07:35:01PM +0300, Parav Pandit wrote:
> > Currently user cannot view the vdpa device config space. Also user
> > cannot set the mac address and mtu of the vdpa device.
> > This patchset
> From: Michael S. Tsirkin
> Sent: Sunday, October 24, 2021 2:46 AM
[..]
> > > [1.243559] Call Trace:
> > > [1.243559] virtio_queue_rq+0x1e4/0x5f0
> > > [1.243559] __blk_mq_try_issue_directly+0x138/0x1e0
> > > [1.243559] blk_mq_try_issue_directly+0x47/0xa0
> > > [
> From: Jason Wang
> Sent: Monday, October 25, 2021 12:31 PM
>
> 在 2021/10/22 上午12:35, Parav Pandit 写道:
> > $ vdpa dev add name bar mgmtdev vdpasim_net mac 00:11:22:33:44:55 mtu
> > 9000
> >
> > $ vdpa dev config show
> > bar: mac 00:11:22:33:44:55 link up link_announce false mtu 9000
> >
> >
> From: Jason Wang
> Sent: Monday, October 25, 2021 12:32 PM
>
>
> 在 2021/10/22 上午12:35, Parav Pandit 写道:
> > Enable user to set the mac address and mtu so that each vdpa device
> > can have its own user specified mac address and mtu.
> > This is done by implementing the management device's
> From: Jason Wang
> Sent: Monday, October 25, 2021 11:36 AM
>
>
> 在 2021/10/22 上午12:35, Parav Pandit 写道:
> > Introduce a command to query a device config layout.
> >
> > An example query of network vdpa device:
> >
> > $ vdpa dev add name bar mgmtdev vdpasim_net
> >
> > $ vdpa dev config
> From: Michael S. Tsirkin
> Sent: Monday, October 25, 2021 1:39 PM
>
> On Mon, Oct 25, 2021 at 07:11:23AM +, Parav Pandit wrote:
> >
> >
> > > From: Jason Wang
> > > Sent: Monday, October 25, 2021 12:32 PM
> > >
> > >
> > > 在 2021/10/22 上午12:35, Parav Pandit 写道:
> > > > Enable user to
> From: Jason Wang
> Sent: Monday, October 25, 2021 12:35 PM
>
> 在 2021/10/22 上午12:35, Parav Pandit 写道:
> > Cited patch in the fixes tag clears the features bit during reset.
> > mlx5 vdpa device feature bits are static decided by device capabilities.
>
>
> This is not what I read at least
> From: Michael S. Tsirkin
> Sent: Monday, October 25, 2021 1:38 PM
>
> It depends on what will the user be able to do then.
> Inject packets? Affect RX routing? Use up networking resources?
> NET_ADMIN is a safe choice but we didn't check any capability in the past so
> it
> seems reasonable
Hi Michael,
> From: Parav Pandit
> Sent: Monday, October 25, 2021 9:14 AM
> > > Thanks for the report. Parav, could you help bisect this please?
> > > I also pushed out a new head with some patches dropped.
> > > Could you test that maybe?
> > >
> > > Thanks!
> >
> > OK I think it's due to
> From: Eli Cohen
> Sent: Wednesday, December 1, 2021 3:33 PM
>
> On Tue, Nov 30, 2021 at 05:24:03PM -0800, Si-Wei Liu wrote:
> >
> >
> > On 11/30/2021 1:48 AM, Eli Cohen wrote:
> > > Allow to configure the max virtqueues for a device.
> > >
> > > Signed-off-by: Eli Cohen
> > > ---
> > >
This series implements querying and setting of the mac address and mtu
device config fields of the vdpa device of type net.
An example of query and set as below.
$ vdpa dev add name bar mgmtdev vdpasim_net mac 00:11:22:33:44:55 mtu 9000
$ vdpa dev config show
bar: mac 00:11:22:33:44:55 link up
Update kernel headers to commit:
ad69dd0bf26b ("vdpa: Introduce query of device config layout")
Signed-off-by: Parav Pandit
---
include/uapi/linux/virtio_net.h | 81 +
vdpa/include/uapi/linux/vdpa.h | 7 +++
2 files changed, 88 insertions(+)
create mode 100644
vdpa: Enable user to set mtu of the vdpa device
Implement mtu setting for vdpa device.
$ vdpa mgmtdev show
vdpasim_net:
supported_classes net
Add the device with specified mac address:
$ vdpa dev add name bar mgmtdev vdpasim_net mac 00:11:22:33:44:55
View the config after setting:
$ vdpa dev
Query the device configuration layout whenever kernel supports it.
An example of configuration layout of vdpa device of type network:
$ vdpa dev add name bar mgmtdev vdpasim_net
$ vdpa dev config show
bar: mac 00:35:09:19:48:05 link up link_announce false mtu 1500
$ vdpa dev config show -jp
{
Implement mtu setting for vdpa device.
$ vdpa mgmtdev show
vdpasim_net:
supported_classes net
Add the device with mac address and mtu:
$ vdpa dev add name bar mgmtdev vdpasim_net mac 00:11:22:33:44:55 mtu 9000
In above command only mac address or only mtu can also be set.
View the config
> From: Michael S. Tsirkin
> Sent: Sunday, December 19, 2021 3:37 AM
>
> On Sat, Dec 18, 2021 at 01:53:01PM -0700, David Ahern wrote:
> > On 12/17/21 1:08 AM, Parav Pandit wrote:
> > > @@ -204,6 +217,8 @@ static void vdpa_opts_put(struct nlmsghdr *nlh,
> struct vdpa *vdpa)
> > > if
> From: Eli Cohen
> Sent: Thursday, December 30, 2021 7:50 PM
>
> Remove overriding of virtio_version_1_0 which forced the virtqueue object to
> version 1.
>
> Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5
> devices")
> Signed-off-by: Eli Cohen
> ---
>
1 - 100 of 290 matches
Mail list logo
