| Message ID | 20230411011354.2619359-1-pavan.kumar.linga@intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Introduce Intel IDPF driver | expand |
On Mon, Apr 10, 2023 at 06:13:39PM -0700, Pavan Kumar Linga wrote: >v1 --> v2: link [1] > * removed the OASIS reference in the commit message to make it clear > that this is an Intel vendor specific driver How will this work when the OASIS driver is ready down the road? We'll end up with two "idpf" drivers, where one will work with hardware that is not fully spec compliant using this Intel driver, and everything else will use the OASIS driver? Does Intel plan to remove this driver when the OASIS one lands? At the very least, having two "idpf" drivers will be very confusing.
Sasha Levin wrote: > On Mon, Apr 10, 2023 at 06:13:39PM -0700, Pavan Kumar Linga wrote: > >v1 --> v2: link [1] > > * removed the OASIS reference in the commit message to make it clear > > that this is an Intel vendor specific driver > > How will this work when the OASIS driver is ready down the road? > > We'll end up with two "idpf" drivers, where one will work with hardware > that is not fully spec compliant using this Intel driver, and everything > else will use the OASIS driver? > > Does Intel plan to remove this driver when the OASIS one lands? > > At the very least, having two "idpf" drivers will be very confusing. One approach is that when the OASIS v1 spec is published, this driver is updated to match that and moved out of the intel directory. This IPU/DPU/SmartNIC/.. device highly programmable. I assume a goal is to make sure that the device meets the new v1 spec. That quite likely requires a firmware update, but that is fine.
On 4/12/2023 2:16 PM, Willem de Bruijn wrote: > Sasha Levin wrote: >> On Mon, Apr 10, 2023 at 06:13:39PM -0700, Pavan Kumar Linga wrote: >>> v1 --> v2: link [1] >>> * removed the OASIS reference in the commit message to make it clear >>> that this is an Intel vendor specific driver >> >> How will this work when the OASIS driver is ready down the road? >> >> We'll end up with two "idpf" drivers, where one will work with hardware >> that is not fully spec compliant using this Intel driver, and everything >> else will use the OASIS driver? >> >> Does Intel plan to remove this driver when the OASIS one lands? >> >> At the very least, having two "idpf" drivers will be very confusing. > > One approach is that when the OASIS v1 spec is published, this driver > is updated to match that and moved out of the intel directory. Yes. We don't want to have 2 idpf drivers in the upstream kernel. It will be an Intel vendor driver until it becomes a standard. Hope it will be OK to move the driver out of the intel directory when that happens. > > This IPU/DPU/SmartNIC/.. device highly programmable. I assume a goal > is to make sure that the device meets the new v1 spec. That quite > likely requires a firmware update, but that is fine. > _______________________________________________ > Intel-wired-lan mailing list > Intel-wired-lan@osuosl.org > https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
On Wed, 12 Apr 2023 19:03:22 -0500 Samudrala, Sridhar wrote: > On 4/12/2023 2:16 PM, Willem de Bruijn wrote: > > Sasha Levin wrote: > >> On Mon, Apr 10, 2023 at 06:13:39PM -0700, Pavan Kumar Linga wrote: > >> How will this work when the OASIS driver is ready down the road? > >> > >> We'll end up with two "idpf" drivers, where one will work with hardware > >> that is not fully spec compliant using this Intel driver, and everything > >> else will use the OASIS driver? > >> > >> Does Intel plan to remove this driver when the OASIS one lands? > >> > >> At the very least, having two "idpf" drivers will be very confusing. > > > > One approach is that when the OASIS v1 spec is published, this driver > > is updated to match that and moved out of the intel directory. > > Yes. We don't want to have 2 idpf drivers in the upstream kernel. > It will be an Intel vendor driver until it becomes a standard. > Hope it will be OK to move the driver out of the intel directory when > that happens. As I said previously in [0] until there is a compatible, widely available implementation from a second vendor - this is an Intel driver and nothing more. It's not moving anywhere. I think that's a reasonable position which should allow Intel to ship your code and me to remain professional. [0] https://lore.kernel.org/all/20230403163025.5f40a87c@kernel.org/
On Wed, Apr 12, 2023 at 07:24:34PM -0700, Jakub Kicinski wrote: > On Wed, 12 Apr 2023 19:03:22 -0500 Samudrala, Sridhar wrote: > > On 4/12/2023 2:16 PM, Willem de Bruijn wrote: > > > Sasha Levin wrote: > > >> On Mon, Apr 10, 2023 at 06:13:39PM -0700, Pavan Kumar Linga wrote: > > >> How will this work when the OASIS driver is ready down the road? > > >> > > >> We'll end up with two "idpf" drivers, where one will work with hardware > > >> that is not fully spec compliant using this Intel driver, and everything > > >> else will use the OASIS driver? > > >> > > >> Does Intel plan to remove this driver when the OASIS one lands? > > >> > > >> At the very least, having two "idpf" drivers will be very confusing. > > > > > > One approach is that when the OASIS v1 spec is published, this driver > > > is updated to match that and moved out of the intel directory. > > > > Yes. We don't want to have 2 idpf drivers in the upstream kernel. > > It will be an Intel vendor driver until it becomes a standard. > > Hope it will be OK to move the driver out of the intel directory when > > that happens. > > As I said previously in [0] until there is a compatible, widely > available implementation from a second vendor - this is an Intel > driver and nothing more. It's not moving anywhere. Even if second implementation arrives, it is unlikely that this idpf driver will be moved. Mainly because of different level of review between vendor driver vs. standard one, and expected pushback to any incompatible changes in existing driver as it is already deployed. Thanks > > I think that's a reasonable position which should allow Intel to ship > your code and me to remain professional. > > [0] https://lore.kernel.org/all/20230403163025.5f40a87c@kernel.org/
On Wed, Apr 12, 2023 at 07:24:34PM -0700, Jakub Kicinski wrote: >On Wed, 12 Apr 2023 19:03:22 -0500 Samudrala, Sridhar wrote: >> On 4/12/2023 2:16 PM, Willem de Bruijn wrote: >> > Sasha Levin wrote: >> >> On Mon, Apr 10, 2023 at 06:13:39PM -0700, Pavan Kumar Linga wrote: >> >> How will this work when the OASIS driver is ready down the road? >> >> >> >> We'll end up with two "idpf" drivers, where one will work with hardware >> >> that is not fully spec compliant using this Intel driver, and everything >> >> else will use the OASIS driver? >> >> >> >> Does Intel plan to remove this driver when the OASIS one lands? >> >> >> >> At the very least, having two "idpf" drivers will be very confusing. >> > >> > One approach is that when the OASIS v1 spec is published, this driver >> > is updated to match that and moved out of the intel directory. >> >> Yes. We don't want to have 2 idpf drivers in the upstream kernel. >> It will be an Intel vendor driver until it becomes a standard. >> Hope it will be OK to move the driver out of the intel directory when >> that happens. > >As I said previously in [0] until there is a compatible, widely >available implementation from a second vendor - this is an Intel >driver and nothing more. It's not moving anywhere. My concern isn't around the OASIS legal stuff, it's about the users who end up using this and will end up getting confused when we have two (or more) in-kernel "IDPF" drivers. I don't think that moving is an option - it'll brake distros and upset users: we can't rename drivers as we go because it has a good chance of breaking users. >I think that's a reasonable position which should allow Intel to ship >your code and me to remain professional. No concerns about OASIS or the current code, I just don't want to make this a mess for the users.
On Fri, 14 Apr 2023 18:01:42 -0400 Sasha Levin wrote: >> As I said previously in [0] until there is a compatible, widely >> available implementation from a second vendor - this is an Intel >> driver and nothing more. It's not moving anywhere. > > My concern isn't around the OASIS legal stuff, it's about the users who > end up using this and will end up getting confused when we have two (or > more) in-kernel "IDPF" drivers. > > I don't think that moving is an option - it'll brake distros and upset > users: we can't rename drivers as we go because it has a good chance of > breaking users. Minor pain for backports but I don't think we need to rename anything, just move. Or we can just leave it be under intel/, since there are not other participant now. Unless perhaps under google/ is a better option? Drivers are organized by the vendor for better or worse. We have a number of drivers under the "wrong directly" already. Companies merge / buy each others product lines, there's also some confusion about common IP drivers. It's all fine, whatever. Users are very, very unlikely to care. >> I think that's a reasonable position which should allow Intel to ship >> your code and me to remain professional. > > No concerns about OASIS or the current code, I just don't want to make > this a mess for the users. It's not a standard until someone else actually adopts it. What stops all the other vendors from declaring that their driver interface is a standard now, too? We have a long standing rule in netdev against using marketing language.
On Fri, Apr 14, 2023 at 03:27:44PM -0700, Jakub Kicinski wrote: >On Fri, 14 Apr 2023 18:01:42 -0400 Sasha Levin wrote: >>> As I said previously in [0] until there is a compatible, widely >>> available implementation from a second vendor - this is an Intel >>> driver and nothing more. It's not moving anywhere. >> >> My concern isn't around the OASIS legal stuff, it's about the users who >> end up using this and will end up getting confused when we have two (or >> more) in-kernel "IDPF" drivers. >> >> I don't think that moving is an option - it'll brake distros and upset >> users: we can't rename drivers as we go because it has a good chance of >> breaking users. > >Minor pain for backports but I don't think we need to rename anything, >just move. > >Or we can just leave it be under intel/, since there are not other >participant now. Unless perhaps under google/ is a better option? > >Drivers are organized by the vendor for better or worse. We have a >number of drivers under the "wrong directly" already. Companies merge / >buy each others product lines, there's also some confusion about common >IP drivers. It's all fine, whatever. > >Users are very, very unlikely to care. > >>> I think that's a reasonable position which should allow Intel to ship >>> your code and me to remain professional. >> >> No concerns about OASIS or the current code, I just don't want to make >> this a mess for the users. > >It's not a standard until someone else actually adopts it. What stops >all the other vendors from declaring that their driver interface is a >standard now, too? > >We have a long standing rule in netdev against using marketing language. Sorry, I may not have explained myself well. My concern is not around what's standard and what's not, nor around where in the kernel tree these drivers live. I'm concerned that down the road we may end up with two drivers that have the same name, and are working with hardware so similar that it might be confusing to understand which driver a user should be using. Yes, it's not something too big, but we have an opportunity to think about this before committing to anything that might be a pain down the road.
On Sat, 15 Apr 2023 13:16:23 -0400 Sasha Levin wrote: > Sorry, I may not have explained myself well. My concern is not around > what's standard and what's not, nor around where in the kernel tree > these drivers live. My bad, I thought you were looking at this from the stable tree's angle. > I'm concerned that down the road we may end up with two drivers that > have the same name, and are working with hardware so similar that it > might be confusing to understand which driver a user should be using. > > Yes, it's not something too big, but we have an opportunity to think > about this before committing to anything that might be a pain down the > road. Indeed, the "update" Willem mentioned should be at most a quirk or capability exchange with the device within this driver. Two drivers would be unacceptable.