On Jun 5, 2009, at 12:35 AM, Darren Reed wrote:
Nicolas Droux wrote:
On Jun 3, 2009, at 6:37 PM, Jason King wrote:
- Shouldn't TX be defined through an entry point called by client
instead of
a callback?
I'm not sure how easily that'd work. For each port, a PDU is sent
ever tx_interval (default: 30) seconds. Except, if something has
changed, then a new PDU is sent out immediately (but no more
frequently than tx_delay - default: 1 - second to prevent a flood of
PDUs if multiple TLV values are changing).
From what I could get from reading the DCBX docs, if a link on an
Opensolaris host was setup as an FCOE target, the OS would send out
LLDP PDUs (with the DCBX TLVs) at the normal intervals (i.e. every
30s), once it sees it's neighbor also send a PDU with DCBX TLVs (and
there aren't any other neighbors on the same link), it switches to a
'fast start' mode where it sends frames once a second to exchange
the
needed data, the returns to the normal 30sec interval.
If multiple PDUs are sent from the same link with different data,
the
most recent replaces whatever was there. To me, this suggests
it'd be
better for LLDP to manage when PDU transmission happens, and just
ping
anything that wants to send extra TLVs to stick them in the mblk.
OK, that makes sense. From the API point of view it could be
simpler to let the callback return a ptr to the buffer containing
the TLV to be added to the PDU, or NULL otherwise. LLDP can then
copy the TLV to the PDU mblk, handle the cases where the mblk size
is exceeded, etc.
- Instead of specifying the link name to the start routine, the
registration
routine should be taking a MAC handle or MAC client handle
instead, which
would allow you to leverage the existing mac_open_*() variants.
One thing I've been struggling with (perhaps you can clarify this)
is
it looks like the recent changes in the MAC api require that each
call
to mac_open_*() (obtaining a handle in the process) requires it's
own
unique MAC address. This is a bit of a problem, since LLDP should
be
using an existing mac addresses, versus getting one of it's own
(this
is why I was originally looking at using DLS instead of MAC since
the
same handle could be reused). Am I correct in that
understanding, or
did I miss something?
mac_client_open() does not require a unique MAC address, however
the data path of a MAC client is currently setup during
mac_unicast_add(). Some changes need to be made to MAC in order to
allow clients like LLDP to send and receive PDUs without adding a
unique MAC address/VID to the client, as discussed previously on
crossbow-discuss. What's your timeline for integrating the LLDP
support? It would be probably best if you could work on this
closely with a member of the Crossbow team.
Nicolas,
I think this is 6838175?
Yes, and in addition to what was described initially by that CR,,
there's also the issue of being able to receive multicast LLDP PDUs
without putting the NIC in promiscuous mode or passing every packet
(or a copy of every packet) to LLDP. These issues should be looked at
simultaneously since they could require refactoring the data-path setup.
Nicolas.
Darren
--
Nicolas Droux - Solaris Kernel Networking - Sun Microsystems, Inc.
[email protected] - http://blogs.sun.com/droux
_______________________________________________
networking-discuss mailing list
[email protected]
