On 02/24/2012 12:50 PM, Wyborny, Carolyn wrote: > > >> -----Original Message----- >> From: Wyborny, Carolyn [mailto:[email protected]] >> Sent: Friday, February 24, 2012 12:30 PM >> To: Ben Greear >> Cc: e1000-devel list >> Subject: Re: [E1000-devel] Question on igb and rx-fcs. >> >> >> >>> -----Original Message----- >>> From: Ben Greear [mailto:[email protected]] >>> Sent: Tuesday, February 21, 2012 4:30 PM >>> To: Wyborny, Carolyn >>> Cc: e1000-devel list >>> Subject: Re: [E1000-devel] Question on igb and rx-fcs. >>> >>> On 02/21/2012 04:23 PM, Wyborny, Carolyn wrote: >>>> >>>> >>>>> -----Original Message----- >>>>> From: Ben Greear [mailto:[email protected]] >>>>> Sent: Tuesday, February 21, 2012 10:09 AM >>>>> To: Wyborny, Carolyn >>>>> Cc: e1000-devel list >>>>> Subject: Re: [E1000-devel] Question on igb and rx-fcs. >>>>> >>>>> On 02/21/2012 09:51 AM, Wyborny, Carolyn wrote: >>>>>>> -----Original Message----- >>>>>>> From: Ben Greear [mailto:[email protected]] >>>>>>> Sent: Monday, February 20, 2012 3:09 PM >>>>>>> To: e1000-devel list >>>>>>> Subject: [E1000-devel] Question on igb and rx-fcs. >>>>>>> >>>>>>> I'm trying to write a patch to allow rx-fcs on the igb driver >>>>>>> (82580 chipset). >>>>>>> >>>>>>> I tried the patch below, but when I then enable rx-fcs, traffic >>>>>>> rx breaks and I see Rx-FIFO error counts increasing. I'm testing >>>>>>> with 1024 byte UDP payloads, at 56kpbs. >>>>>>> >>>>>>> First, if anyone sees an obvious problem with the patch, please >>>>>>> let me know...but more importantly, what developer's manual >>>>>>> is valid for the igb supported hardware? I found the '316080.pdf' >>>>>>> that seems valid for e1000e, but I'm not sure it works for igb >>>>>>> as well? >>>>>> [...] >>>>>> >>>>>> The hardware can behave differently for a given feature and the igb >>>>> drivers supports a different set of hardware than e1000e. For igb, >>> we >>>>> support 82575 and greater (82576, 82580, i350). The best bet is the >>>>> Datasheet for the 825XX you're working with. Here's the datasheet >>> for >>>>> 82580. >> http://download.intel.com/design/network/datashts/321027.pdf. >>>>> I'll take a look at your patch and the datasheet as well and see if >> I >>>>> can find anything to help. >>>>> >>>>> Thanks for the datasheet pointer. >>>>> >>>>> I did a quick search for SECRC, and section 8.8.2.7 mentions the >>> SECRC >>>>> bits are >>>>> ignored if some virtual machine logic is enabled. I'm not using any >>>>> virtual >>>>> machines, but perhaps that logic is enabled anyway? >>>>> >>>> [..] >>>> Yeah, it shouldn't be enabled though if you aren't configuring the >>> virtualization nor using a virtualized os. Hmm.., seems that >>> rx_fifo_errors is an accumulation stat and I think there's also a typo >>> in that spec as it lists a stat that doesn't exist anywhere else in the >>> document. I'll dig around a bit more on this, but basically, as you >> can >>> probably see, you're dropping those packets. If you set the RCTL_SBP >>> bit in the driver, you can accumulate the different errors and see >>> exactly what is going wrong there. I could give you a patch to do >> that. >>> Are you using upstream in kernel version or a standalone version of the >>> igb driver? >>> >>> I already wrote a patch to do SBP part, and will post it and the ones >>> for ixgbe after we do some more internal testing. >>> >>> And, I no longer see the rx-fifo errors after I properly reset the chip >>> when enabling the 'rx-fcs' logic. (In the patch I posted, I was just >>> twiddling >>> the register in the set_features() method, which appears to be a bad >>> idea). >>> >>> But, though I receive packets just fine, I do NOT see the 4 bytes of >> FCS >>> on >>> the end. >>> >> [..] >> I checked around a bit and there's no reason I can see why this isn't >> working, so I raised the issue with our internal hw support team. I'll >> let you know what I find. There's nothing much to do here in sw, but >> make sure that bit is unset, rest is up to the hw. If you're seeing >> this with e1000e, then I assume your sniffer setup is identical and >> correct. > [...] > > Another question comes to mind. Have you tried this with another part > supported by igb or just the 82580? There could be something that is common > in the driver that affects this, like the strip bit getting re-enabled at > some point during the process. Perhaps an outputting of that register during > rx might be useful. Also, exactly how are you examining the packets? > Wireshark, tcpdump or some other way?
I tried with two different 4-port NICs ... 02:00.3 Ethernet controller: Intel Corporation Device 1521 (rev 01) 03:00.0 Ethernet controller: Intel Corporation 82580 Gigabit Network Connection (rev 01) ... Same behaviour with both. I was using tshark to capture, wireshark to view the .pcap file, and I also added enough printk to the driver to determine that the length was 4 less than expected when rx-crc was enabled. I also dumped the rx-control register, and it appeared I had it set up as expected. The bulk of the patches have been accepted so should show up in net-next soon. Thanks, Ben > > Thanks, > > Carolyn > > Carolyn Wyborny > Linux Development > LAN Access Division > Intel Corporation > > -- Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ E1000-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
