On 12/8/19 10:06 AM, Matan Azrad wrote: > From: Andrew Rybchenko >> On 12/6/19 8:32 AM, Liang, Cunming wrote: >>> >>> >>>> -----Original Message----- >>>> From: Bie, Tiwei <[email protected]> >>>> Sent: Friday, December 6, 2019 12:28 PM >>>> To: Matan Azrad <[email protected]> >>>> Cc: Wang, Xiao W <[email protected]>; Thomas Monjalon >>>> <[email protected]>; [email protected]; Wang, >> Zhihong >>>> <[email protected]>; Yigit, Ferruh <[email protected]>; >>>> Shahaf Shuler <[email protected]>; Ori Kam >> <[email protected]>; >>>> [email protected]; Slava Ovsiienko <[email protected]>; Asaf >> Penso >>>> <[email protected]>; Olga Shern <[email protected]>; Liang, >> Cunming >>>> <[email protected]> >>>> Subject: Re: discussion: creating a new class for vdpa >>>> [email protected] >>>> >>>> On Thu, Dec 05, 2019 at 01:26:36PM +0000, Matan Azrad wrote: >>>>> Hi all >>>>> >>>>> As described in RFC “[RFC] net: new vdpa PMD for Mellanox devices”, >>>>> a new vdpa drivers is going to be added for Mellanox devices – >>>>> mlx5_vdpa >>>>> >>>>> The only vdpa driver now is the IFC driver that is located in net >>>>> directory. >>>>> >>>>> The IFC driver and the new mlx5_vdpa driver provide the vdpa ops and >>>>> not the eth_dev ops. >>>>> >>>>> All the others drivers in net provide the eth-dev ops. >>>>> >>>>> I suggest to create a new class for vdpa drivers, to move IFC to >>>>> this class and to add the mlx5_vdpa to this class too. >>>>> >>>>> Later, all the new drivers that implements the vdpa ops will be >>>>> added to the vdpa class. >>>> >>>> +1. Sounds like a good idea to me. >>> +1 >> >> vDPA drivers are vendor-specific and expected to talk to vendor NIC. I.e. >> there are significant chances to share code with network drivers (e.g. base >> driver). Should base driver be moved to drivers/common in this case or is it >> still allows to have vdpa driver in drivers/net together with ethdev driver? > > Yes, I think this should be the method, shared code should be moved to the > drivers/common directory. > I think there is a precedence with shared code in common which shares a > vendor specific code between crypto and net.
I see motivation behind driver/vdpa. However, vdpa and net drivers tightly related and I would prefer to avoid extra complexity here. Right now simplicity over-weights for me. No strong opinion on the topic, but it definitely requires better and more clear motivation why a new class should be introduced and existing drivers restructured. > Actually, this is my plan to share mlx5 vdpa code with mlx5 net code by the > drivers/common dir (see RFC). I see.
