I'm writing a custom driver for a custom OS and thus this does not relate
to the Linux driver.

I have implemented a driver which polls for the DD and EOP flags to get set
(using legacy receive descriptors) and I have noticed a problem where these
flags both can get set very slightly before the packet contents have
actually been DMAed to the host (or at least appear to be).

I'm under the understanding that the X540 device should respect caching and
thus I should not have to be flushing caches for the packet contents. The
only thing I could think of would be that I need to add some memory
barriers as maybe the CPU is speculatively loading the packet contents
before it is reading the flags, and thus the contents are older than the
flags?

I just want to verify that this isn't a hardware problem with the X540 and
that I will need to do a workaround on my end. Ideally the workaround
actually fixes the problem, rather than a small delay/sleep that makes it
seem to go away in most cases.

Anyone have any ideas? Adding an clflush, mfence, sfence fixes the problem,
but an lfence does not. I'm under the suspicion that it's not the fences
that actually are doing anything, rather the delay of these rather long
instructions happens to just be a long enough sleep. I just want to make
sure that I'm fixing the problem correctly and not just hoping the sleep
delays long enough for the DMA to occur, as that is quite kludgey.

It is a 4 physical processor system, AMD Fam 15h.

-B
------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
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

Reply via email to