On Fri, Jan 20, 2017 at 8:36 AM, Martin Habets <mhab...@solarflare.com> wrote: > Hi Tom, > > On 17/01/17 22:05, Tom Herbert wrote: >> There was some discussion about the problems of dealing with the >> explosion of NIC features in the mlx directory restructuring proposal, >> but I think the is a deeper issue here that should be discussed. >> >> It's hard not to notice that there has been quite a proliferation of >> NIC features in several drivers. This trend had resulted in very >> complex driver code that may or may not segment individual features. >> One visible manifestation of this is number of ndo functions which is >> somewhere around seventy-five now. >> >> I suspect the vast majority of these advances NIC features (e.g. >> bridging, UDP offloads, tc offload, etc.) are only relevant to some of >> the people some of the time. The problem we have, in this case those >> of us that are attempting to deploy and maintain NICs at scale, is >> when we have to deal with the ramifications of these features being >> intertwined with core driver functionality that is relevant to >> everyone. This becomes very obvious when we need to backport drivers >> from later versions of kernel. >> >> I realize that backports of a driver is not a specific concern of the >> Linux kernel, but nevertheless this is a real problem and a fact of >> life for many users. Rebasing the full kernel is still a major effort >> and it seems the best we could ever do is one rebase per year. In the >> interim we need to occasionally backport drivers. Backporting drivers >> is difficult precisely because of new features or API changes to >> existing ones. These sort of changes tend to have a spiderweb of >> dependencies in other parts of the stack so that the number of patches >> we need to cherry-pick goes way beyond those that touch the driver we >> are interested in. > > For the sfc driver (Solarflare Adapters) we currently do backports internally > for: > - RedHat Enterprise Linux 5.10, 5.11 > - RedHat Enterprise Linux 6.5, 6.6, 6.7, 6.8 > - Redhat Messaging Realtime and Grid 2.5 > - RedHat Enterprise Linux 7.0, 7.1, 7.2 > - RedHat Enterprise Linux for Realtime 7.1, 7.2 > - SuSE Linux Enterprise Server 11 sp3, sp4 > - SuSE Linux Enterprise RealTime Extension 11 > - SuSE Linux Enterprise Server 12 base release, sp1 > - Canonical Ubuntu Server LTS 14.04, 16.04 > - Canonical Ubuntu Server - > - Debian 7 "Wheezy" 7.X > - Debian 8 "Jessie" 8.X > - Linux 2.6.18 to 4.9-rc1 > > We update this list as needed, and always try to support the latest kernel. > I do not know if that would cover the kernel version you are using. > That really doesn't help us. We don't base which kernels we run in datacenters on what distros are doing-- they don't seem to move as fast in rebsing. Our general request is that vendors always do their development upstream, if we need to do a backport in our kernel then we take responsibility for that. As I mentioned, the churn and lack of modularization seem to be making this process more and more difficult.
Tom > Best regards, > Martin > >> Currently we (FB) need to backport two NIC drivers. I've already gave >> details of backporting mlx5 on the thread to restructure the driver >> directories. The other driver being backporting seems to suffer from >> the same type of feature complexity. >> >> In short, I would like to ask if driver maintainers to start to >> modularize driver features. If something being added is obviously a >> narrow feature that only a subset of users will need can we allow >> config options to #ifdef those out somehow? Furthermore can the file >> and directory structure of drivers reflect that; our lives would be >> _so_ much simpler to maintain drivers in production if we have such >> modularity and the ability to build drivers with the features of our >> choosing. >> >> Thanks, >> Tom
