Darren Reed wrote:
> Garrett D'Amore wrote:
>> Darren Reed wrote:
>>> The current design of mac_header_info() and its accompanying structure
>>> suggest that when it comes to the MAC header, a variable sized one,
>>> where
>>> each packet may have a different MAC header length, was planned for.
>>>
>>>
>>> However the current implementation runs counter to that: all of the MAC
>>> types currently set the header length to a constant, which some may
>>> consider
>>> to be a bug for ethernet as it would always exclude the VLAN header
>>> if that
>>> were present.
>>>
>>> However, if we aren't going to implement per-packet variation of MAC
>>> header sizes, then doesn't it make sense to have the header length
>>> also be
>>> a property of the MAC provider itself, rather than just a packet?
>>> i.e. to
>>> have a mac_header_len() that is modeled after mac_addr_len().
>>>
>>> Is anyone aware of any MAC layer devices that are likely to run on
>>> Solaris that would have a variable size MAC header?
>>
>> I've seen devices where the MAC header was dependent on the type of
>> packet -- anycast used one length, and unicast another. (Don't
>> remember what the protocol, possibly ATM or HIPPI.)
>
> So nothing likely to actually run on Solaris :)
Do we know if IPoIB has a fixed header length?
>
>> The other thing is that there is work on things like RBridges, plus
>> the VLAN protocols, to embed additional information into the headers
>> and extend the header length.
>
> Both of which would at least have a "minimum" length, yes?
What do you mean by "minimum"?
>
> Should mac_header_len() return sizeof(struct ether_header) for packets
> with the VLAN header intact?
> Or would that be a bug?
I don't know... I suspect its a bug, but that might depend on how the
client is used. I don't have any experience with the mac consumer API.
(Whose job is it to do vlan tag insertion? The mac layers, or the clients?)
- Garrett
