On 5/05/09 10:00 AM, rajagopal kunhappan wrote:
Jason King wrote:
On Wed, Apr 29, 2009 at 6:30 PM, rajagopal kunhappan
<[email protected]> 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
_______________________________________________
networking-discuss mailing list
[email protected]
