On Thu, Jan 16, 2025 at 09:36:30PM +0100, Morten Brørup wrote: > > From: Bruce Richardson [mailto:bruce.richard...@intel.com] > > Sent: Thursday, 16 January 2025 18.46 > > > > On Thu, Jan 16, 2025 at 11:10:47PM +0530, Jerin Jacob wrote: > > > On Thu, Jan 16, 2025 at 10:50 PM Bruce Richardson > > > <bruce.richard...@intel.com> wrote: > > > > > > > > On Fri, Dec 20, 2024 at 02:38:57PM +0000, Bruce Richardson wrote: > > > > > This RFC attempts to reduce the amount of code duplication across > > a > > > > > number of Intel NIC drivers, specifically: ixgbe, i40e, iavf, and > > ice. > > > > > > > > > > The first patch extract a function from the Rx side, otherwise > > the > > > > > majority of the changes are on the Tx side, leading to a > > converged Tx > > > > > queue structure across the 4 drivers, and a large number of > > common > > > > > functions. > > > > > > > > > > > > > When considering the changes in this patchset, I'm still not > > entirely > > > > satisfied with where to place the common code in the repo. Using > > the > > > > "drivers/common" seems wrong to me, as it's for code common across > > devices, > > > > and having a "_common_intel" (or common_intel) folder inside > > drivers/net > > > > > > driver/common/intel is OK. I think. > > > > > > > seems a bit ugly to me. > > > > > > > > What would people think of me taking a leaf out of the kernel > > directory > > > > structure playbook, and moving the intel drivers into a separate > > > > subdirectory "drivers/net/intel"? I've done up a prototype RFC > > patch for > > > > > > I thought the reason for not keeping the company name was to - not > > > change the directory structure > > > if NIC block is bought by another company (driver/net/bnxk was with > > > Boradcom then moved to Marvell) or acquired by another company. > > > (Cavium->Marvell) > > > > > > > > I hadn't thought of that. > > > > However, in our case I believe the reason we don't use this scheme is > > that > > we a) never needed to and AFAIK b) it has never been proposed. > > > > In practice, if we do this for the intel drivers, it does not need to > > be > > done by other vendors unless they want to do so, or have a lot of > > drivers > > in DPDK. Also, renaming vendor directories is not going to be a serious > > problem, so long as the underlying device directory name remains the > > same. > > For compatibility of output, my RFC patch strips off all paths but the > > last, so intel/i40e remains just "i40e" in terms of all generated > > objects. > > > > /Bruce > > If we proceed with drivers/net/intel/i40e, will new patches be titled > "net/intel/i40e: new feature", or still just "net/i40e: ..."? > > The key is getting rid of code duplication, so either directory structure is > fine with me, drivers/net/intel/common, or drivers/common/intel. > > Considering Jerin's input about NICs getting new owner companies, I have a > slight preference for Jerin's suggestion. >
For the second suggestion, drivers/common/intel wouldn't work as a name on it's own since it's too generic, and doesn't specify that this is common net driver code. So the resulting name would be "drivers/common/intel_net" or "intel_eth". My preference is definitely against using drivers/common, but I am ok to continue to use the "_common_intel" folder name in "net" as in the v4 patchset, or (my slight preference) to have "drivers/net/intel/common" folder with the other drivers moved to that "drivers/net/intel" folder too. /Bruce
