crossbow discuss - Apr 2009 - Replacement for dls_tx?

(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?

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.

Thanks,
-krgopi
> _______________________________________________
> networking-discuss mailing list
> networking-discuss at opensolaris.org

--

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).

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



--

On Tue, May 5, 2009 at 12:00 PM, rajagopal kunhappan
<rajagopal.kunhappan at sun.com> 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''d prefer to set it to receive the multicast traffic specific to the
protocol, but that''s a more minor point I think.

As the whole point of the exercise was to create an in-kernel LLDP
prototype that could properly tx/rx PDUs down individual links of an
aggregation, it''s looking like even doing that is going to be far too
complicated now that DLS no longer looks to be an API for other kernel
components (in it''s current form, only DLD can call into it).

I''m now wondering if it would not be better to just stick with the
userland implementation for now, and just not support aggregations (at
least until this is sorted out better).  At worst case, for DCBX, a
kernel module could be created that provides an in-kernel API for LLDP
if needed.  It would just (for now at least) invoke the necessary door
calls to the userland daemon to exchange information, and if the
future things moved into the kernel, it should minimize any changes to
kernel consumers.



>
> 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
>
>
>
> --
>
>
>

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

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
>
>
>