Peter Memishian wrote:
>  > Would really appreciate if you could review the code which implements
>  > 'POSSIBLE' MTU values feature. The CR for the same is "6680929 dladm
>  > should print POSSIBLE values for properties like mtu by contacting the
>  > driver".
>  > 
>  > Today, 'dladm show-linkprop -p mtu' output, the 'POSSIBLE' column
>  > displays just '--'. With this fix, that column would be populated with
>  > range of values (min - max) that can be used to set the 'mtu', of-course 
>  > only if 'mtu' is writeable. In cases when MTU property cannot be
>  > set, one will see '--'; as for a 'read-only' MTU property, 'POSSIBLE' 
>  > value is just the 'CURRENT' value and does not mean anything.
>  > 
>  > Sample output:
>  > 
>  > bash-3.2# dladm show-linkprop -p mtu
>  > LINK         PROPERTY     PERM VALUE          DEFAULT        POSSIBLE
>  > ixgb0        mtu          r-   1500           1500           --
>  > e1000g0      mtu          rw   1500           1500           1500-9216
>  > e1000g1      mtu          rw   1500           1500           500-9216
>  > e1000g2      mtu          rw   1510           1500           1500-9216
>  > e1000g3      mtu          rw   1510           1500           1500-9216
>  > aggr1        mtu          rw   1510           1500           1500-9216
>  > stub1        mtu          rw   9000           1500           46-9000
>  > 
>  > The webrev can be found at:
>  > 
>  > http://cr.opensolaris.org/~girishmg/possible_mtu/
> 
> The notion of having a range/collection of values for POSSIBLE is generic
> and thus seems like something that should be thus extended into the
> linkprop framework itself rather than one-offed through a parallel set of
> mac properties as has been done.  For instance, I'd expect this would also
> apply to the "cpus" link property.  (Further, there is a CR for covering
> inputting ranges as well (6822164), which doesn't apply for MTU but
> certainly applies in the general case.)
> 

Sure. The current structure I have defined is not sufficient to support 
multiple ranges, as in 1-6, 10-19, et al. I will extend it to support 
multiple ranges which can be used by properties like CPU.

Now, I have:
-------------

typedef struct mac_propval_range {
        uint32_t range_min;
        uint32_t range_max;
} mac_propval_range_t;


I think I need;
----------------

typedef struct mac_propval_limit {
        uint32_t range_min;
        uint32_t range_max;
} mac_propval_limit_t;

typedef struct mac_propval_range {
        uint32_t range_num;
        mac_propval_limit_t range_limit[1];
} mac_propval_range_t;

thanks
~Girish



Reply via email to