Re: Bug in e1000 + semantics of flow control WAS(Re: [e1000]: flow control on by default - good idea really?

[jamal <hadi@cyberus.ca>]

To the good folks at Intel:


Do you need more info on how to reproduce the issue below?
Note, there are 2 issues - one being a larger ethtool semantic issue and
the other being what i perceive to be a bug in the e1000.

cheers,
jamal

On Thu, 2006-20-07 at 16:15 -0400, jamal wrote:
> I went back to this today.  I am typing this from a scribbled sticky
> note in a big hurry -  but i still believe I took the correct notes.
> 
> It does seem there is no distinction between what ethernet advertises
> for flow control capability vs what it ends up negotiating with its
> partner i.e there is some ambiguity. I havent checked tg3, this on e1000
> only.
> 
> On Fri, 2006-07-07 at 08:28 -0400, jamal wrote:
> > On Thu, 2006-06-07 at 23:59 -0700, David Miller wrote:
> > 
> > > 
> > > It's autonegotiated, check you kernel message logs when the link
> > > came up, you'll see this:
> > > 
> > > tg3: eth0: Flow control is on for TX and on for RX.
> > > 
> > 
> > yikes - yes, this would be it.
> > 
> > I  could be wrong and i will double check:
> > I think when the e1000 says via ethtool "rx is on" - it means that it 
> > is _advertising_ flow control as opposed to detecting partner has flow
> > control capability.
> > Auke, can you also check this as well?
> 
> Semantic #1
> 
> For example, configure:
> ethtool -A eth0 rx off
> ethtool -A eth0 tx on
> 
> debopolis:~# ethtool -a eth0
> Pause parameters for eth0:
> Autonegotiate:  on
> RX:             off
> TX:             on
> 
> The other side was set to do symmetric TX flow control only.
> 
> Now enforce autonegotiation:
> ethtool -r eth0
> 
> ethtool -a eth0
> Pause parameters for eth0:
> Autonegotiate:  on
> RX:             off
> TX:             off
> 
> Ok, this is what i expected if this thing (output of ethtool) was
> supposed to store state as opposed to configuration.
> But if it is state that is stored, then what about that the values
> before autonegotian - surely that state is invalid, no?
> 
> It would be nice (for debug/usability reasons) to be able to see what i
> configured vs what i end up negotiating with the link partner. I think
> this may be an ethtool issue, but it could also be a driver issue.
> 
> I send 1 Mpps to eth0 and see no flow control packets back. good. So it
> does store state
> 
> #2: The other semantic
> 
> debopolis:~# ethtool -A eth0 rx on
> debopolis:~# ethtool -A eth0 tx on
> 
> debopolis:~# ethtool -a eth0
> Pause parameters for eth0:
> Autonegotiate:  on
> RX:             on
> TX:             on
> 
> Other side was set to do symmetric TX flow control only.
> 
> Now enforce autonegotiation:
> debopolis:~# ethtool -r eth0
> 
> lets see what we came up with:
> debopolis:~# ethtool -a eth0
> Pause parameters for eth0:
> Autonegotiate:  on
> RX:             on
> TX:             on
> 
> Now that is contradictory to #1 semantic - I would have expected this TX
> flow control on the e1000 to be off. 
> Unless it is meant to store configuration info and not what you have
> negotiated.
>  
> Trying sending traffic to the e1000 at about 1Mpps.
> I observe that the e1000 is sending out about 800Kpps of flow control
> packets back ;->
> 
> So which semantics are correct? I would claim #2 flow control behavior
> to be a bug. I just dont have time to chase a fix - hopefully whoever
> reads this from the e1000 crowd can fix it.
> 
> More importantly can we have two variables storing the two pieces on
> information separately instead of the ambiguity of just one?
> 
> 
> cheers,
> jamal