Thanks Ben and John, Yes, the ethtool hooks are already present, and it should be "just" a matter if advertising the capability and implementing it in the driver. Whilst the patch we have works for the one card and the one use case we've tested it (essentially being receive only, to tcpdump spanned packets from a switch) I'm explicitly not enforcing RX_FCS to be mutually exclusive with any other feature, and reading the datasheet's notes on CRCSTRIP, perhaps I should be... I'm just not familiar with the card itself, or these other potentially conflicting features to be sure myself.
I can clean up what little I have and post, perhaps that will be a good starting point. This will be a good few weeks, as I'll be out of the office until late Nov. I apologise for being vague whilst fishing for a way to speak to the Windows driver group regarding this, I didn't want to get too far off topic for this list. But, yes I'm also looking at Windows (Server 2008r2 in particular). I've done something terrible and experimented with poking registers just to see what happens - and by manually clearing CRCSTRP I can convince wireshark to grab the FCS, and note that it is valid for a given packet, so the OS' stack seems OK with that at least. However under windows the card seems to ignore when I set SBP: invalid FCS packets get dropped and error counters increment. Neighbouring bits in the register regarding promiscuous modes do have an effect when poking them. So perhaps there's more needed than setting SBP (this seems all Linux is doing to implement RXALL); the windows driver is operating the card in a different mode where SBP isn't taking [the expected] effect, or the network stack is dropping them. Either way , it seems I've hit a dead end with what information I have on hand, so am reaching out for help on the Windows front, in parallel go getting the Linux version mainlined. Thanks again for your responses, David Mirabito This email is subject to copyright and the information in it is confidential. This e-mail, its content and any files transmitted with it are intended solely for the addressee/s and may be legally privileged and/or confidential. Access by any other person other than the addressee/s is unauthorized without the express written permission of the sender. If you have received this e-mail in error notify the sender immediately by email, do not use the email or any attachment or disclose them to any person, delete the email from your system and destroy all copies you may have printed. Metamako LP does not guarantee that any email or attachment is secure or free from viruses or other defects On 1 November 2014 03:39, Ben Greear <gree...@candelatech.com> wrote: > On 10/31/2014 09:34 AM, Ronciak, John wrote: > > David, > > > >> How best would we go about getting this functionality into the standard > >> driver? I suspect my initial experiments would need some work to watch > out > >> for corner cases and interactions with other adapter features. > > I would suggest working on submitting changes to ethtool to enable the > feature. Along with the ethtool patch to add the functionality you could > also publish the ixgbe changes required to use to the feature. Doing both > of them at the same time. You would have to go through the net-dev mail > list to get this approved. > > Hopefully ethtool tool and API doesn't need any changes. > > Should just need to implement the ethtool hooks in the driver itself. > > Thanks, > Ben > > -- > Ben Greear <gree...@candelatech.com> > Candela Technologies Inc http://www.candelatech.com > >
------------------------------------------------------------------------------
_______________________________________________ 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
