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. On the receive side, you can set the device to device promiscuous mode and look for packets that are of interest. I think taking this approach may help you in the short term. We are still discussing how to go about this for the long term. Nicolas Droux or myself will send a mail later for the longer term approach. Thanks, -krgopi --
