[prev in list] [next in list] [prev in thread] [next in thread] 

List:       e1000-devel
Subject:    Re: [E1000-devel] HW behavior when RA is partially written
From:       Jesse Brandeburg <jesse.brandeburg () intel ! com>
Date:       2013-12-11 0:49:24
Message-ID: 20131210164924.00000e42 () unknown
[Download RAW message or body]

On Tue, 26 Nov 2013 13:55:56 -0500
Vlad Yasevich <vyasevic@redhat.com> wrote:
> > 
> > Thank for taking a look.  I saw the AV bit in RAH as well.  That's
> > what got me asking the question.  The data sheet says AV gets turns off
> > on resets only.  So if the address is changing from one value to
> > another AV is still valid half way through the write just as you said
> 
> Any news?  Does the HW use the AV bit as a latch between RAL and RAH writes?
> 
> If not, does it make sense for the driver to clear the AV before setting
> the registers so that there is no window where a half-written address
> may match an incoming packet?
> 
> Thanks
> -vlad
> .
> > 
> > The main reason I am asking is that in qemu we are working on completing
> > a feature where a change in guest mac address is propagated to the host
> > and the host can program that address to the nic card.  The debate
> > we have is when to do the notifications since we have 2 writes.
> > One approach was to do it when RAH was written.  If there is a
> > requirement that RAH has to be written last, that's works great.
> > However, if RAL and RAH can be written in any order, that doesn't work
> > and we notify on every write. In this case, we could end up
> > notifying twice and possibly writing incomplete mac address to HW.  That
> > seemed bad.  So I was wondering how does HW behaves.

hardware is probably stupider than you think.  :-) It likely just pays
attention to AV bit and if the register changes and AV is valid, the
receive filters are changed immediately.

This is likely a long standing bug in the code that probably doesn't
matter much at all.  But to be 100% correct we should be clearing AV
with the first RAH write, write new RAL , then enable AV with another
write to RAH.  My guess is the designers intended us to do:
write AV 0 in RAH
write RAL
write new RAH with AV set
write flush

writes won't be reordered, so this should always work.

I don't know if/when we would get to fixing this. :-(

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&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&#174; Ethernet, visit http://communities.intel.com/community/wired
[prev in list] [next in list] [prev in thread] [next in thread]