In playing around developing the sink driver, I also experimented with a "NULL MAC" driver - a MAC driver for a type of NIC that has no MAC addresses to use at the MAC layer. I should note that a MAC of this type must be a point-to-point device.
The source code for this can be found here: http://www.opensolaris.org/os/community/networking/files/mac_null.c.gz - to compile, see an email earlier today about a sink network interface. It's not very hard (cc followed by ld) and the installation is easy, just copy the module (should be called "mac_null") to /kernel/mac/sparcv9 (ultrasparc) or /kernel/mac/amd64 (amd64) or /kernel/mac/ (i386.) That said, it won't work without a patched dld (patches in the pipeline.) Specifics aside, there is something that I think is work discussing... In building this MAC device, I came across a rather bizarre limitation: for a multi-SAP device, it is always necessary to allocate an mblk_t so that (at least) the SAP can be stored in that. This design has an interesting consequence/limitation: - that the SAP is part of the packet or can somehow be derived from the payload of the packet. Perhaps a hangover from DLPI where the SAP is pointed to as part of the UNITDATA_IND header? To break this down, the use of the SAP is a two-step here: 1) when mtops_header is called, put something on the front of the packet so that when 2) mtops_header_info is called, the SAP can be retrieved. The problem being that the only common thing between the call to mtops_header and mtops_header_info is the mblk_t*. The problems with this being the only "packet information" that is carried around the kernel have manifested themselves in other workarounds, such as the use of M_CTL (inside of IP, by IPsec and friends.) If we were to put the SAP elsewhere, what problems would this bring? Also, what benefits would a change to allow that bring? Is this an instant headache for anything promoting DLPI compatibility because there is no SAP in the packet and thus it would need to conjure up something? Does the resulting data duplication of the SAP for the most common packet type (ethernet - duplicating storing SAP in the ethernet header plus somewhere else) make it too likely to cause trouble? If there is negligable performance improvement for the aforementioned common case, does that mean the problem isn't worth solving? But on the other hand, if we can move away from needing to use the mblk_t as the catch-all for all of our diverse needs and information in networking, does that stand a chance of making the implementation better and therefore (hopefully) faster? Darren _______________________________________________ networking-discuss mailing list [email protected]
