The out-of-tree driver exists for people who need features that can’t be
upstreamed, and for people who need a driver fix and can’t update their kernel.
At this time the 1G driver is pretty stable and we’re mostly only doing bug
fixes to the igb out-of-tree driver.
To be honest, most of our focus is on enabling new parts or new features on our
NICs. We haven’t enabled features like pluggable SFP because we never released
a NIC that had pluggable modules. If you need that you can add it to the
upstream kernel, but we’re not going to backport it to our out-of-tree driver
because we have no way of validating the changes.
Todd Fujinaka
Software Application Engineer
Networking Division (ND)
Intel Corporation
todd.fujin...@intel.com
(503) 712-4565
From: Doron Shikmoni [mailto:doron.shikm...@gmail.com]
Sent: Monday, May 02, 2016 9:46 AM
To: Fujinaka, Todd <todd.fujin...@intel.com>
Cc: e1000-devel@lists.sourceforge.net
Subject: Re: [E1000-devel] Introduce "ethtool -m" support?
Todd,
Thanks for responding. Good question... A while ago our devops found that this
flavor behaved better in some aspects (mainly the reading of full frames,
including VLAN tags, into the cap buffers). They also seem to provide some
stability / portability in the face of kernel changes, and, at the same time,
ability to use higher versions without too many kernel dependencies.
We're also seeing some other vendors' patches being done against this tree.
I'm not overly familiar with the politics / raison d'etre of the separation
between the two trees. Would you be recommending not to use the out-of-tree
driver version?
Currently, we're having an issue with the LED Blink function ("ethtool -p") not
working when an I350 based NIC has a copper SFP inserted. Also, subsequent
removal / insertion of the SFP seems not to initiate the desired port reset.
This is somewhat independent of the original question I posted, although still
related.
Cheers,
Doron
On Mon, May 2, 2016 at 6:29 PM, Fujinaka, Todd
<todd.fujin...@intel.com<mailto:todd.fujin...@intel.com>> wrote:
At this point this is very, very unlikely. Is there any reason you need the
out-of-tree driver?
Todd Fujinaka
Software Application Engineer
Networking Division (ND)
Intel Corporation
todd.fujin...@intel.com<mailto:todd.fujin...@intel.com>
(503) 712-4565
-----Original Message-----
From: Doron Shikmoni
[mailto:doron.shikm...@gmail.com<mailto:doron.shikm...@gmail.com>]
Sent: Sunday, May 01, 2016 5:03 PM
To: e1000-devel@lists.sourceforge.net<mailto:e1000-devel@lists.sourceforge.net>
Subject: [E1000-devel] Introduce "ethtool -m" support?
Hi folks,
Has it been discussed, or is there any intention, to introduce the "ethtool -m"
capability that is available in the in-tree version of igb, to this driver?
(this feature provides "module" eeprom information, namely SFP info).
I found this provision to be extremely useful, and was somewhat surprised it is
only available in the in-kernel-tree driver (the dash-k).
The change seems to basically boil down to fitting a couple routines
(igb_get_module_info and igb_get_module_eeprom) into ethtool.c
Has this been rejected for some reason?
Thanks for any info,
Doron
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit
http://communities.intel.com/community/wired
