On Jun 10, 2009, at 1:52 AM, Garrett D'Amore wrote: > Nicolas Williams wrote: >> On Tue, Jun 09, 2009 at 10:24:53PM -0700, Garrett D'Amore wrote: >> >>> Bzzt. You're conflating things here. VLAN and Jumbo frames >>> affect *on the wire* transmission and *need* to be tunable. >>> >>> TSO and LSO are *optimizations* that don't affect on the wire >>> presentation, and needing to tune them at all is a *bug*. >>> >> >> Unless you're trying to demonstrate them and the perf benefit you get >> from having them, or just to see for yourself. Sure, a feature whose >> only value is, in a way, marketing. But marketing matters. >> > > For marketing purposes, a specially hacked driver, or a private > tunable, are adequate. We don't need to pollute our framework for > this, nor should we confuse administrators by presenting something > to them that they shouldn't be tuning. > > Solaris suffers from ETOOMANYTUNABLES. Canonizing more of them is > not the right way forward.
Sure, I can buy that sentiment. How about a read-only representation of whether some offload feature is even present? I think we allow for read-only properties, right? Take a driver such as bge or e1000g for example. These two drivers support a ton of silicon parts that have quite varied feature sets among. Some do jumbo, some don't. Some have various levels of off- loading and checksumming, some none at all. It would be useful, I would think, for an admin to know if a particular (offload) feature is present on a particular chipset without trying to dig up the chipset's docs, make sense of source code, or guess. Right now this area is sort of like mystery meat. Extrapolating this into the future, who knows what other features lay in wait when it comes to ethernet chipset one-upmanship... iscsi crap, RDMA, and so on. All I'm saying is that info is good, even in read- only form. It can take the sleuthing out of wondering what you've got when you put in a new Intel PRO card or are wondering what exactly your Nvidia chip is capable of. /dale
