Hi, On Tue, Dec 9, 2014 at 7:22 PM, Skidmore, Donald C <donald.c.skidm...@intel.com> wrote: > Hi Stefan, > > Ubuntu is a tricky one. I keep reminding our management that I'm noticing > more people in the community are using it especially LTS. They (Ubuntu) make > it hard though without versioning like SLES and RHEL, doing kcompat can be a > challenge. Not that I think that is at all related to your issue. And you > are correct we do validate and actively add compat support for RHEL and SLES. > :)
By "without versioning" do you mean they backport stuff expected in newer kernel, making it hard to detect which kernel you're running on? I'm asking just so I know next time when I need to decide Ubuntu or their kernel. I guess the Linus/vanilla kernel should work (according to http://sourceforge.net/p/e1000/mailman/message/32788947/ at least)? > > I think ATR may work for you with your current system setup if you map the > interrupts in the 1-to-1 fashion I mentioned below. Since you have your user > space processes pinned to a given CPU all flows that transmit a SYN from that > CPU will be redirected back to that queue/CPU pair. Not sure you would be > effected much by the sampling rate as it rate is our mechanism for identify > non-SYN packet flows, it is the rate at which we check a given packet to see > if a ATR hash bucket exist for it and if not create one. Actually, the stuff we're receiving is strictly layer 3 - IP with a custom protocol, not even TCP or UDP. We would've used Layer2, but I haven't found a way to distribute that among cores / queues. Both RSS and ethtool -K/-U filters seem to require at least layer 3. > > That said I also believe your mechanism will work, possible even better since > you don't have to wait for the ATR hash bucket to be created by the > transmission of the SYN (meaning connections remotely initiated will most > likely not have their initial SYN direct to the CPU you want) and won't have > to deal with the limit on ATR hash buckets (if you have LOTS of ports open > from one IP address). Still I would turn off ATR and thus default to RSS. > This however will limit you to 16 queues, which depending on the size of your > system may or may not be an issue. Is it possible to disable ATR from ethtool while using the older driver that ships with Ubuntu kernel 3.11? We're currently using 8 queues per NIC, so the RSS limit is OK. > > In truth you might want to look at perfect filter. With it you could direct > let the adapter to send all traffic to a given queue. Which, from my limited > understanding of what you're doing, looks to be just what you're looking for. > Basically map an IP address to a give queue. I'm using: ethtool -K $DEV ntuple on [... then for each src IP] ethtool -U $DEV flow-type ip4 src-ip 10.10.10.$ip_digit action $i Not sure if I'm using perfect filter or not... Or what I would need to change to use perfect filter. Thanks for your help, Stefan. > > Thanks, > -Don Skidmore <donald.c.skidm...@intel.com> ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk _______________________________________________ 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
