| Message ID | 20230407081021.30952-1-gautam.dawar@amd.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | sfc: add vDPA support for EF100 devices | expand |
On Fri, Apr 07, 2023 at 01:40:01PM +0530, Gautam Dawar wrote: > Hi All, > > This series adds the vdpa support for EF100 devices. > For now, only a network class of vdpa device is supported and > they can be created only on a VF. Each EF100 VF can have one > of the three function personalities (EF100, vDPA & None) at > any time with EF100 being the default. A VF's function personality > is changed to vDPA while creating the vdpa device using vdpa tool. Jakub, I wonder if it is not different approach to something that other drivers already do with devlink enable knobs (DEVLINK_PARAM_GENERIC_ID_ENABLE_*) and auxiliary bus. Thanks
On Sun, Apr 9, 2023 at 5:13 PM Leon Romanovsky <leon@kernel.org> wrote: > > On Fri, Apr 07, 2023 at 01:40:01PM +0530, Gautam Dawar wrote: > > Hi All, > > > > This series adds the vdpa support for EF100 devices. > > For now, only a network class of vdpa device is supported and > > they can be created only on a VF. Each EF100 VF can have one > > of the three function personalities (EF100, vDPA & None) at > > any time with EF100 being the default. A VF's function personality > > is changed to vDPA while creating the vdpa device using vdpa tool. > > Jakub, > > I wonder if it is not different approach to something that other drivers > already do with devlink enable knobs (DEVLINK_PARAM_GENERIC_ID_ENABLE_*) > and auxiliary bus. I think the auxiliary bus fits here, and I've proposed to use that in V2 of this series. Thanks > > Thanks >
On 4/10/23 07:09, Jason Wang wrote: > Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding. > > > On Sun, Apr 9, 2023 at 5:13 PM Leon Romanovsky <leon@kernel.org> wrote: >> On Fri, Apr 07, 2023 at 01:40:01PM +0530, Gautam Dawar wrote: >>> Hi All, >>> >>> This series adds the vdpa support for EF100 devices. >>> For now, only a network class of vdpa device is supported and >>> they can be created only on a VF. Each EF100 VF can have one >>> of the three function personalities (EF100, vDPA & None) at >>> any time with EF100 being the default. A VF's function personality >>> is changed to vDPA while creating the vdpa device using vdpa tool. >> Jakub, >> >> I wonder if it is not different approach to something that other drivers >> already do with devlink enable knobs (DEVLINK_PARAM_GENERIC_ID_ENABLE_*) >> and auxiliary bus. > I think the auxiliary bus fits here, and I've proposed to use that in > V2 of this series. Yeah, right and you mentioned that are fine with it if this is done sometime in future to which Martin responded saying the auxbus approach will be considered when re-designing sfc driver for the upcoming projects on the roadmap. Gautam > > Thanks > >> Thanks >>
On Mon, Apr 10, 2023 at 12:03:25PM +0530, Gautam Dawar wrote: > > On 4/10/23 07:09, Jason Wang wrote: > > Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding. > > > > > > On Sun, Apr 9, 2023 at 5:13 PM Leon Romanovsky <leon@kernel.org> wrote: > > > On Fri, Apr 07, 2023 at 01:40:01PM +0530, Gautam Dawar wrote: > > > > Hi All, > > > > > > > > This series adds the vdpa support for EF100 devices. > > > > For now, only a network class of vdpa device is supported and > > > > they can be created only on a VF. Each EF100 VF can have one > > > > of the three function personalities (EF100, vDPA & None) at > > > > any time with EF100 being the default. A VF's function personality > > > > is changed to vDPA while creating the vdpa device using vdpa tool. > > > Jakub, > > > > > > I wonder if it is not different approach to something that other drivers > > > already do with devlink enable knobs (DEVLINK_PARAM_GENERIC_ID_ENABLE_*) > > > and auxiliary bus. > > I think the auxiliary bus fits here, and I've proposed to use that in > > V2 of this series. > > Yeah, right and you mentioned that are fine with it if this is done sometime > in future to which Martin responded saying the auxbus approach will be > considered when re-designing sfc driver for the upcoming projects on the > roadmap. Adding new subsystem access (vDPA) is the right time to move to auxbus. This is exactly why it was added to the kernel. We asked to change drivers for Intel, Pensando, Mellanox and Broadcom and they did it. There are no reasons to do it differently for AMD. Thanks > > Gautam > > > > > Thanks > > > > > Thanks > > >
On Mon, Apr 10, 2023 at 10:53:33AM +0300, Leon Romanovsky wrote: > On Mon, Apr 10, 2023 at 12:03:25PM +0530, Gautam Dawar wrote: > > > > On 4/10/23 07:09, Jason Wang wrote: > > > Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding. > > > > > > > > > On Sun, Apr 9, 2023 at 5:13 PM Leon Romanovsky <leon@kernel.org> wrote: > > > > On Fri, Apr 07, 2023 at 01:40:01PM +0530, Gautam Dawar wrote: > > > > > Hi All, > > > > > > > > > > This series adds the vdpa support for EF100 devices. > > > > > For now, only a network class of vdpa device is supported and > > > > > they can be created only on a VF. Each EF100 VF can have one > > > > > of the three function personalities (EF100, vDPA & None) at > > > > > any time with EF100 being the default. A VF's function personality > > > > > is changed to vDPA while creating the vdpa device using vdpa tool. > > > > Jakub, > > > > > > > > I wonder if it is not different approach to something that other drivers > > > > already do with devlink enable knobs (DEVLINK_PARAM_GENERIC_ID_ENABLE_*) > > > > and auxiliary bus. > > > I think the auxiliary bus fits here, and I've proposed to use that in > > > V2 of this series. > > > > Yeah, right and you mentioned that are fine with it if this is done sometime > > in future to which Martin responded saying the auxbus approach will be > > considered when re-designing sfc driver for the upcoming projects on the > > roadmap. > > Adding new subsystem access (vDPA) is the right time to move to auxbus. > This is exactly why it was added to the kernel. > > We asked to change drivers for Intel, Pensando, Mellanox and Broadcom > and they did it. There are no reasons to do it differently for AMD. We have obtained permission from our management to incorporate auxbus for this, and will start work on a design for this. Best regards, Martin > Thanks > > > > > Gautam > > > > > > > > Thanks > > > > > > > Thanks > > > >