[brussels-dev] Is replumb sufficient to change the mtu property?

[sowmini.varadhan at sun.com]

On (10/11/07 18:06), Artem Kachitchkine wrote:
> > so it may be that the mi_ref is getting scribbled on somewhere else. 
> 
> It's worth investigating, but might not be related to this particular 
> issue. Detaching a driver instance is not the only way to change MTU. 
> bge_m_setprop(DLD_PROP_DEFMTU) only returns EBUSY when 
> bgep->bge_mac_state == BGE_MAC_STARTED. If you stop the mac then call 
> mi_setprop, it should reinitialize with the the value. I think we should 
> work this angle first.

This is along the lines of what Erik Nordmark suggested: of reiniting
the chip (at the potential penalty of dropping some packets).

Can you actually stop the mac of a driver easily when it is running?

This would be ideal to do..  however, the problem is that, in practice, we
can't always do this technique (stop/start) for every property considered 
because of the unfortunate fact that many drivers (including the
network stack, sometimes) may need a major rewrite to achieve this..
in the case of default_mtu, we are able to reset the ire state information
via mac_maxsdu_update() but this may not always be easy to do
(e.g., for some parameters like interrupt coalescing, where Crossbow
is doing the rewrite).

Getting back to the question on hand:
Why doesn't the mac_prop_load() invocation in mac_start() pull
in the new property definitions on the replumb? 

--Sowmini