I'd like to describe the e1000g issue with more details here.
Currently the e1000g driver set jumbo frames in e1000g.conf with a
different method:
MaxFrameSize=0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0;
# 0 is for normal ethernet frames.
# 1 is for upto 4k size frames.
# 2 is for upto 8k size frames.
# 3 is for upto 16k size frames.
It takes 4 options to set the maximum frame size. That is different from
the traditional "default_mtu" method that Brussels uses.
So here I get two problems:
(1) What's the precedence of reading the persistent dladm properties and
reading the conf file settings? Will one setting overwrites the other
setting?
(2) Because e1000g is using a different method, I believe I have to
change the e1000g.conf settings to make it consistent with Brussels.
This is a user interface change, and it will impact customers'
applications if it is backported to s10. I believe we should make this
change, but do we need to do any additional thing for this? (PSARC?)
I want to hear more ideas/suggestions for this.
Thanks,
Ted
sowmini.varadhan at sun.com :
> Artem,
>
> Ted and I were discussing the changes to convert e1000g to Brussels,
> and he raise the following question:
>
>
>>I asked this because e1000g link
>>configuration method is different from other drivers, and with the
>>Brussels porting, e1000g will use the same way as other drivers when
>>using dladm and ndd. But the e1000g.conf file still uses the old method,
>>which will conflict with the permanent property settings. So I'm
>>considering to make some changes to the conf file.
>
>
> I believe (Ted?) that Ted is referring to the fact that the syntax that
> e1000g reads from e1000g.conf is linux-style configuration, not the
> traditional "default_mtu" config.
>
> Artem: can you confirm that this is the model being proposed by
> the Persistence component:
>
> In that case, e1000g_attach should make a door_call (the prototype
> uses a mac_prop_init() function) to the dlmgmtd that will result in the
> driver properties being loaded into the kernel in a mac_prop_list that
> is managed by the mac layer. Then, instead of doing ddi_prop_get* interfaces
> to read the property from driver.conf, e1000g should call something
> like mac_prop_get_int to get the value of mtu. The latter function
> will first search the mac_prop_list, and second do the ddi_prop_get
> to get the requested value. (I'm assigning precedence for the dladm
> configuration arbitrarily- not sure what choices Artem is making).
>
> --Sowmini
>
>
