e1000 question

e1000 question

[Ihar 'Philips' Filipau]

[-- Attachment #1: Type: text/plain, Size: 1223 bytes --]


[ If this is wrong ML, will appreciate pointer to correct one. ]
[ CC: me, please - I'm not sub'd. ]
[ Intel's driver as in 2.6.5 - 
http://lxr.linux.no/source/drivers/net/e1000/e1000_main.c?v=2.6.5 ]

    I'm looking into e1000 driver in irq handling and what I see, 
puzzles me.

    Functions e1000_clean_{t,r}x_irq are very similar: both of them are 
checking descriptor flag updated by nic.
    Host CPU, obviously, to perform this check, will cache descriptor.
    If, say e1000_clean_rx_irq() will be called twice in short time 
range, I expect that it can miss change of the flag, since old flag may 
still sit in host CPU cache.

    Am I missing something here?

-- 
     Johnson's law:
            Systems resemble the organizations that create them.
--                              ___      ___
Ihar 'Philips' Filipau             \    /     Sr. Software Developer
Tel:    +49 681 959 16 0            \  /                 GIGA STREAM
Fax:    +49 681 959 16 100           \/        Konrad Zuse Strasse 7
Mobile: +49 173 39 462 49            /\           66115 Saarbruecken
email:  ifilipau@giga-stream.de     /  \                     Germany
www: http://www.giga-stream.de  ___/    \___   Switching for success


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3439 bytes --]

Re: e1000 question

[Mitchell Blank Jr]

Ihar 'Philips' Filipau wrote:
>    Functions e1000_clean_{t,r}x_irq are very similar: both of them are 
> checking descriptor flag updated by nic.
>    Host CPU, obviously, to perform this check, will cache descriptor.
>    If, say e1000_clean_rx_irq() will be called twice in short time 
> range, I expect that it can miss change of the flag, since old flag may 
> still sit in host CPU cache.

Please see Documentation/DMA-mapping.txt; especially the part starting
at "There are two types of DMA mappings..."  Ring buffers are allocated
as "consistent" DMA memory.

For most architectures this will mean that the cache hardware snoops the
PCI bus and automatically invalidates cache lines as they are written to.
For architectures that can't do that then Linux will mark those memory
regions uncacheable.

-Mitch

Re: e1000 question

[Ihar 'Philips' Filipau]

[-- Attachment #1: Type: text/plain, Size: 1571 bytes --]


   Thanks, Mitch!
   That explains everything.

   Went reading pci_alloc_consistent()'s RTFM.
   That is exactly what I was missing in couple of my drivers.

Mitchell Blank Jr wrote:
> Ihar 'Philips' Filipau wrote:
> 
>>   Functions e1000_clean_{t,r}x_irq are very similar: both of them are 
>>checking descriptor flag updated by nic.
>>   Host CPU, obviously, to perform this check, will cache descriptor.
>>   If, say e1000_clean_rx_irq() will be called twice in short time 
>>range, I expect that it can miss change of the flag, since old flag may 
>>still sit in host CPU cache.
> 
> 
> Please see Documentation/DMA-mapping.txt; especially the part starting
> at "There are two types of DMA mappings..."  Ring buffers are allocated
> as "consistent" DMA memory.
> 
> For most architectures this will mean that the cache hardware snoops the
> PCI bus and automatically invalidates cache lines as they are written to.
> For architectures that can't do that then Linux will mark those memory
> regions uncacheable.
> 

-- 
     Johnson's law:
            Systems resemble the organizations that create them.
--                              ___      ___
Ihar 'Philips' Filipau             \    /     Sr. Software Developer
Tel:    +49 681 959 16 0            \  /                 GIGA STREAM
Fax:    +49 681 959 16 100           \/        Konrad Zuse Strasse 7
Mobile: +49 173 39 462 49            /\           66115 Saarbruecken
email:  ifilipau@giga-stream.de     /  \                     Germany
www: http://www.giga-stream.de  ___/    \___   Switching for success


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3439 bytes --]

Re: e1000 question

[Mitchell Blank Jr]

Ihar 'Philips' Filipau wrote:
>    I'm looking into e1000 driver in irq handling and what I see, 
> puzzles me.
[...]

Wow - thats some lag.  I already answered this question when I it got posted
to lkml four days ago.  Looking at the headers it looks like there was
a 4 day delay in the same email making it to the netdev list!

-Mitch