[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <96e59cf0-1423-64af-1da9-bd740b393fa8@gmail.com>
Date: Wed, 18 Nov 2020 21:35:29 -0700
From: David Ahern <dsahern@...il.com>
To: Jakub Kicinski <kuba@...nel.org>, Jason Gunthorpe <jgg@...dia.com>
Cc: Parav Pandit <parav@...dia.com>, Saeed Mahameed <saeed@...nel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
Jiri Pirko <jiri@...dia.com>,
"dledford@...hat.com" <dledford@...hat.com>,
Leon Romanovsky <leonro@...dia.com>,
"davem@...emloft.net" <davem@...emloft.net>
Subject: Re: [PATCH net-next 00/13] Add mlx5 subfunction support
On 11/18/20 7:14 PM, Jakub Kicinski wrote:
> On Tue, 17 Nov 2020 14:49:54 -0400 Jason Gunthorpe wrote:
>> On Tue, Nov 17, 2020 at 09:11:20AM -0800, Jakub Kicinski wrote:
>>
>>>> Just to refresh all our memory, we discussed and settled on the flow
>>>> in [2]; RFC [1] followed this discussion.
>>>>
>>>> vdpa tool of [3] can add one or more vdpa device(s) on top of already
>>>> spawned PF, VF, SF device.
>>>
>>> Nack for the networking part of that. It'd basically be VMDq.
>>
>> What are you NAK'ing?
>
> Spawning multiple netdevs from one device by slicing up its queues.
Why do you object to that? Slicing up h/w resources for virtual what
ever has been common practice for a long time.
Powered by blists - more mailing lists