On 2016/09/27 23:23, Mintz, Yuval wrote:
>> +/* return envelope header length */
>> +static inline int netif_get_env_hdr_len(struct net_device *dev) {
>> + if (dev->netdev_ops->ndo_set_env_hdr_len)
>> + return dev->env_hdr_len;
>> +
>> + if (netif_reduces_vlan_mtu(dev))
>> + return 0;
>> +
>> + return 4; /* VLAN_HLEN */
>> +}
>
Thank you for taking a look at this.
> Why claim that `4' is the default?
> What's the benefit of propagating this value to userspace if
> driver doesn't actually support it?
I'm sorry, this is a leftover from previous draft when I was not aware
of type 2-2 drivers (that do not allow over-MTU-sized packets other than
vlan-tagged ones). Now I'm thinking we should not include
IFLA_ENV_HDR_LEN in response of GETLINK if it is not supported.
I'll delete current logic from next version.
>
> Assuming this *is* a good default [meaning your analysis indicated
> basically every driver has at least so many octets reserved]
> perhaps we should consider initializing the env_hdr_len in some
> common function [e.g., in setup_ether() next to the mtu] to this value?
I actually tried it first and realized it is difficult, since so many
drivers use their own initializer instead of ether_setup(). Anyway, I'm
going not to expose envhdrlen when it is not supported.
Thanks,
Toshiaki Makita
