On 5/05/09 10:00 AM, rajagopal kunhappan wrote: > Jason King wrote: >> On Wed, Apr 29, 2009 at 6:30 PM, rajagopal kunhappan >> <rajagopal.kunhappan at sun.com> wrote: >>> Jason King wrote: >>>> (Trying this again in the hopes gmail is no longer on the spam >>>> blacklist)... >>>> >>>> While I haven't checked to see exactly where, I suspect that it was >>>> the crossbow integration that removed dls_tx(). What would be the >>>> equivalent for transmitting frames now for dls clients? >>> They would need to call mac_tx(). mac_tx() is the mac client API. >>> Details of >>> this mac API is in the "Crossbow MAC Virtualization Architecture" >>> document >>> at http://opensolaris.org/os/project/crossbow/Docs/ . This document >>> is a bit >>> old and the mac_tx() signature has changed. >> >> Unfortunately, there seems to no longer be a way to get the mac handle >> from dls (unless you directly grab it from dls_str_t->dl_mh, which >> seems bad form. >> >> Is there any example code using dls that merely does: >> >> open link >> bind to a SAP >> send or recv a frame >> closes link >> >> I'm trying to put this all together, but so many pieces have changed >> so much that the existing documentation has enough gaps that I can't >> I'm scared of even comitting to any sort of design, even for just a >> prototype because I cannot figure out what's going on anymore. >> >> From what I can tell, it appears that each mac client now gets it's >> own hardware address, this means LLDP cannot talk to the mac layer >> directly -- as it should use the existing factory hw address (it does >> become a bit more interesting for vnics or cards w/ multiple hw >> addresses, as the standard really doesn't address that). Thus some >> other layer above the mac layer would need to be used, dls seems the >> right candidate, being similar in concept to libdlpi in userland, but >> seems that bits have been removed or replaced with things I cannot >> find that appear render it unusable (I'm sure it's just I can't find >> what's replaced what's been removed, but the effect is the same). > > The problem with MAC client API for your use is that without calling > mac_unicast_add(), you would not be able to send and receive packets. > mac_unicast_add() configures Rx/Tx rings, SRSes, soft rings, etc. But > you need to send packets without doing mac_unicast_add(). To > do this, some changes need to be done to mac_tx() function. > > Here is one approach: > The first thing that is done in mac_tx() is to get the Tx_SRS from > flent. This is always non-NULL (because mac_unicast_add() would have > setup the SRSes). To handle your case, we can do the following: If > Tx_SRS is NULL and certain flags in mac_client_impl_t are true, then > just send the packet out of the NIC (by calling MAC_TX()) without doing > anything else. If the NIC has exposed Tx rings, then send the packet > out using the default Tx ring.
BPF and PF_PACKET are also going to need help here - I'd been under the seemingly false assumption that having a mac_client_handle_t was all that I needed to call mac_tx() successfully. Being able to pass a flag such as MAC_CLIENT_OPEN_NO_ADDRESS, telling the mac that mac_unicast_add() is never going to be called, when calling mac_client_open() would be sufficient for me. Darren
