Re: [B.A.T.M.A.N.] [RFC 18/23] batman-adv: ELP - use phydev to determine link characteristics

[Antonio Quartulli <antonio@meshcoding.com>]

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

On 13/02/14 12:44, Andrew Lunn wrote:
>> it is invoked every time the interface is brought up. So if you
>> disconnect and then reconnect the cable (e.g. to connect the NIC to a
>> faster switch) this function is invoked again and the bandwidth is updated.
>>
>>> Are we sure that auto-negotiation has
>>> finished? It can take a few seconds to complete after the interface is
>>> brought up. It would not be good to have batman use 10Mbps/Half Duplex
>>> on my gigabit links...
>>
>> So it can take up to "few" seconds? I did not expect such a delay!
> 
> It varies a lot between devices. I have a NAS box which i use for
> kernel hacking. I TFTP boot the kernel, using u-boot configuration
> variables. I found that for a cold boot it works great, but a warm
> boot seems to be faster and the TFTP GET command is sent while the phy
> is still auto-negotiating, and it gets lost. This then triggers a bug
> in u-boot, it never re-transmits the GET command, and then whole TFTP
> boot times out eventually.
> 
> So i'm just cautious about making assumptions here, especially
> assumptions which might be mostly true, but in some odd edge case turn
> out to be false.
> 
>> However this function if invoked when the NETDEV_UP event is issued by
>> the underlying system. I expect the event to be thrown when the
>> interface is ready to be used, not when the auto-negotiatin is still
>> going on. I will double check.
> 
> I had a quick look at the code. It seems like NETDEV_UP is issued
> directly after the device is opened. There does not seem to be any
> waiting around for auto-neg.


Hi Andrew,

This morning I've been trying to dig into the tg3 Ethernet driver to get
an idea of what happens before the NETDEV_UP event is fired.

The network stack invokes the ndo_open() callback implemented by the
driver and, as far as I can see, this function does not return until
having set speed and half/full_duplex state.
Thus it looks like that when NETDEV_UP is fired the speed and the
full_duplex attribute have already a meaningful value.

Of course this may vary depending on the driver, so this may not be the
case everywhere.

I think that we can keep this approach for now and then perform some
tests on a couple of platforms before merging the code.
This way we should be "sure" about this particular behaviour.

I think that your NAS might also be a good testing platform, assuming
that the owner is willing to insmod batman-adv on that machine :-)



Cheers,

-- 
Antonio Quartulli


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]