I've captured this as 6838175.
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.
>
> 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
>
>
>
