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? Darren
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.) 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. - Garrett> > Darren > > _______________________________________________ > crossbow-discuss mailing list > crossbow-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/crossbow-discuss
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 :)> 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? Should mac_header_len() return sizeof(struct ether_header) for packets with the VLAN header intact? Or would that be a bug? Darren
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
On 07/20/09 13:47, Garrett D''Amore wrote:> Darren Reed wrote: > >> >> 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?)we''re talking about a private function here, so as long as caller and callee codes know what they''re doing there may be misnaming, but no bug. The second question about whose job is it to insert the vlan tag is an interesting one. As of the first phase of Crossbow, we opted for having by default the MAC layer be fully responsible for the VLAN, both insertion and stripping for inbound tagged packets. We offer an exception to that behavior: A client calling mac_unicast_add() may specify the flags (MAC_UNICAST_TAG_DISABLE | MAC_UNICAST_STRIP_DISABLE) asking for tagged packets to be left alone. Seen from the virtual machines that use VNICs, the default behavior offers a bump-in-the-wire support for the VLANs of some sort, with the host domain (or global zone as the case may be) ensuring the security of the tagging. The rationale behind the exception is to allow more sophisticated trusted clients (LDOM''s vsw code running in the service domain) to take on the VLAN processing themselves. Kais.> > - Garrett > > _______________________________________________ > crossbow-discuss mailing list > crossbow-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/crossbow-discuss >
On 20/07/09 01:47 PM, Garrett D''Amore wrote:> 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?Well, the mac_ib module behaves like it is fixed.>>> 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"?That the MAC header will always be at least X bytes long, but otherwise, one can''t be sure.>> >> 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?)I suspect that someone needs to make up their mind about what the role of mhi_hdrsize is (set by calling mac_header_info()). Is it going to be the correct MAC header length (ie not 14 for _all_ ethernet packets) or is it going to be something else? That it isn''t always correct seems to be avoided by the mac code that chooses not to call mac_header_info() for ethernet whilst it does for other protocols (feels like an optimisation to avoid all the other work in mac_header_info() on the "fast" ethernet path.) however dls_link_header_info() does it right: for VLAN packets, mhi_hdrsize is set to the size of the VLAN packet. I''ve filed 6862429 but.... Darren