All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Wang <jasowang@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Eli Cohen <elic@nvidia.com>, Cindy Lu <lulu@redhat.com>,
	virtualization@lists.linux-foundation.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] vdpa/mlx5: Use random MAC for the vdpa net instance
Date: Wed, 2 Dec 2020 21:33:19 +0800	[thread overview]
Message-ID: <eaaa5fb6-fd6a-200f-8457-d27f758f1c64@redhat.com> (raw)
In-Reply-To: <20201202080533-mutt-send-email-mst@kernel.org>


On 2020/12/2 下午9:07, Michael S. Tsirkin wrote:
>>>> Two questions here:
>>>> 1. Now we don't have support for control virtqueue. Yet, we must filter
>>>> packets based on MAC, what do you suggest to do here?
>>> How about an ioctl to pass the mac to the device?
>>> Maybe mirroring the control vq struct format ...
>> I think we'd better avoid such ad-hoc ioctls to make vhost-vDPA type
>> independent.
> Fundamentally this is about handling some VQs in QEMU, right?
> Maybe a generic ioctl along the lines of "CTRL_VQ" passing
> vq number and a command buffer from guest?
> Seems generic enough for you?
>

It looks to me you want to invent a synchronized API (or vDPA config 
ops) for submitting virtio descriptors.

Several issues I can think for this:

1) control vq allows the request to be handled asynchronously
2) we still need a way to isolate the DMA if there's a hardware 
virtqueue for the device that use DMA
3) new vDPA config operations need to be invented, new uAPI for 
vhost-vDPA, new virtio config ops for virtio-vDPA

It looks to me we can overcome 1) and 2) if we just stick to a virtqueue 
interface in vhost-vDPA as I proposed in [1]. For issue 3) it also 
requires much less work.

Thanks

[1] https://lkml.org/lkml/2020/9/23/1243


WARNING: multiple messages have this Message-ID (diff)
From: Jason Wang <jasowang@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Eli Cohen <elic@nvidia.com>,
	linux-kernel@vger.kernel.org, Cindy Lu <lulu@redhat.com>,
	virtualization@lists.linux-foundation.org
Subject: Re: [PATCH] vdpa/mlx5: Use random MAC for the vdpa net instance
Date: Wed, 2 Dec 2020 21:33:19 +0800	[thread overview]
Message-ID: <eaaa5fb6-fd6a-200f-8457-d27f758f1c64@redhat.com> (raw)
In-Reply-To: <20201202080533-mutt-send-email-mst@kernel.org>


On 2020/12/2 下午9:07, Michael S. Tsirkin wrote:
>>>> Two questions here:
>>>> 1. Now we don't have support for control virtqueue. Yet, we must filter
>>>> packets based on MAC, what do you suggest to do here?
>>> How about an ioctl to pass the mac to the device?
>>> Maybe mirroring the control vq struct format ...
>> I think we'd better avoid such ad-hoc ioctls to make vhost-vDPA type
>> independent.
> Fundamentally this is about handling some VQs in QEMU, right?
> Maybe a generic ioctl along the lines of "CTRL_VQ" passing
> vq number and a command buffer from guest?
> Seems generic enough for you?
>

It looks to me you want to invent a synchronized API (or vDPA config 
ops) for submitting virtio descriptors.

Several issues I can think for this:

1) control vq allows the request to be handled asynchronously
2) we still need a way to isolate the DMA if there's a hardware 
virtqueue for the device that use DMA
3) new vDPA config operations need to be invented, new uAPI for 
vhost-vDPA, new virtio config ops for virtio-vDPA

It looks to me we can overcome 1) and 2) if we just stick to a virtqueue 
interface in vhost-vDPA as I proposed in [1]. For issue 3) it also 
requires much less work.

Thanks

[1] https://lkml.org/lkml/2020/9/23/1243

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

  reply	other threads:[~2020-12-02 13:35 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-29  6:43 [PATCH] vdpa/mlx5: Use random MAC for the vdpa net instance Eli Cohen
2020-11-29 20:08 ` Michael S. Tsirkin
2020-11-29 20:08   ` Michael S. Tsirkin
2020-11-30  6:27   ` Eli Cohen
2020-11-30  9:00     ` Michael S. Tsirkin
2020-11-30  9:00       ` Michael S. Tsirkin
2020-11-30  9:27       ` Eli Cohen
2020-11-30  9:33         ` Michael S. Tsirkin
2020-11-30  9:33           ` Michael S. Tsirkin
2020-11-30 10:41           ` Cindy Lu
2020-11-30 15:33             ` Michael S. Tsirkin
2020-11-30 15:33               ` Michael S. Tsirkin
2020-12-01  9:23               ` Cindy Lu
2020-12-01 11:32                 ` Michael S. Tsirkin
2020-12-01 11:32                   ` Michael S. Tsirkin
2020-12-02  2:27                   ` Cindy Lu
2020-12-02  4:18                 ` Jason Wang
2020-12-02  4:18                   ` Jason Wang
2020-12-02  5:57                   ` Eli Cohen
2020-12-02  9:23                     ` Michael S. Tsirkin
2020-12-02  9:23                       ` Michael S. Tsirkin
2020-12-02 12:12                       ` Eli Cohen
2020-12-02 12:17                         ` Michael S. Tsirkin
2020-12-02 12:17                           ` Michael S. Tsirkin
2020-12-02 13:00                           ` Jason Wang
2020-12-02 13:00                             ` Jason Wang
2020-12-02 13:07                             ` Michael S. Tsirkin
2020-12-02 13:07                               ` Michael S. Tsirkin
2020-12-02 13:33                               ` Jason Wang [this message]
2020-12-02 13:33                                 ` Jason Wang
2020-12-02 13:48                       ` Jason Wang
2020-12-02 13:48                         ` Jason Wang
2020-12-02 22:00                         ` Michael S. Tsirkin
2020-12-02 22:00                           ` Michael S. Tsirkin
2020-12-03  6:49                           ` Eli Cohen
2020-12-03 10:44                             ` Michael S. Tsirkin
2020-12-03 10:44                               ` Michael S. Tsirkin
2020-12-03 12:09                               ` Eli Cohen
2020-12-03 12:15                                 ` Michael S. Tsirkin
2020-12-03 12:15                                   ` Michael S. Tsirkin
2020-12-03 12:24                                   ` Eli Cohen
2020-12-04  2:53                                     ` Jason Wang
2020-12-04  2:53                                       ` Jason Wang
2020-12-06  6:54                                       ` Eli Cohen
2020-12-02  9:30                   ` Michael S. Tsirkin
2020-12-02  9:30                     ` Michael S. Tsirkin
2020-12-02 12:56                     ` Jason Wang
2020-12-02 12:56                       ` Jason Wang
2020-12-02 13:04                       ` Michael S. Tsirkin
2020-12-02 13:04                         ` Michael S. Tsirkin
2020-12-02 13:41                         ` Jason Wang
2020-12-02 13:41                           ` Jason Wang
2020-11-30 11:51           ` Eli Cohen
2020-11-30 15:30             ` Michael S. Tsirkin
2020-11-30 15:30               ` Michael S. Tsirkin

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=eaaa5fb6-fd6a-200f-8457-d27f758f1c64@redhat.com \
    --to=jasowang@redhat.com \
    --cc=elic@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lulu@redhat.com \
    --cc=mst@redhat.com \
    --cc=virtualization@lists.linux-foundation.org \
    /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.