> -----Original Message----- > From: Morten Brørup <[email protected]> > Sent: Tuesday, April 19, 2022 17:12 > To: Thomas Monjalon <[email protected]>; Daly, Jeff > <[email protected]>; Stephen Hemminger > <[email protected]> > Cc: Wang, Haiyue <[email protected]>; [email protected]; Zhang, Qi Z > <[email protected]>; Mcnamara, > John <[email protected]> > Subject: RE: [PATCH] net/ixgbe: Treat 1G Cu SFPs as 1G SX on the X550 devices > > > From: Thomas Monjalon [mailto:[email protected]] > > Sent: Thursday, 14 April 2022 19.07 > >
> > > > > - should print message that when enabled the driver is no longer > > supported. > > > > It could be supported by Silicom. > > There's more to "supported by" than meets the eye: When an ODM designs > products using Intel chips, > some sort of customer support from Intel field application engineers is > expected by the ODM. We cannot > expect Silicom to provide design support to anyone but their own customers. > E.g. if the NIC is > behaving weird at the hardware bring-up phase, where it might be any type of > problem, Silicom will not > be able to provide the kind of support required. My point is: There is a > difference between community > support and customer support. > > Let me throw up an idea for consideration... I'm trying to think out of the > box here, so please > forgive me if I'm stepping on anyone's toes with this suggestion: > > If Intel doesn't want to take on the responsibility and support for this > feature graciously donated by > Silicom (which is obviously Intel's own decision to make), but the DPDK > community thinks the feature > is beneficial, perhaps Silicom could be accepted as the maintainer of this > part of the driver? The > driver would still come with a big fat disclaimer saying that this feature is > not supported by Intel, The first patch author Stephen D has left Silicom: https://patchwork.dpdk.org/project/dpdk/patch/[email protected]/ How can you expect people can connect to Silicom always ? ; -) > but maintained by Silicom, who also provides community support for it. > > The worst case alternative is a fork or separate add-on patch set offered by > the donor. This has > certainly happened to other projects. Don't get me wrong, we are not there at > all regarding this > feature! I'm just wondering if we can make the DPDK project even more > inclusive, so we can avoid forks > and add-on patch sets now and in the future. > > -Morten
