crossbow discuss - Apr 2007 - dls and VLANs

Folks,

As most people here are aware, the dls kernel module contains a number 
of functions and data structures which contain the string "vlan" which
have little to do with VLANs directly.  The dls_vlan_t, for example, is 
actually the object that represents a datalink, which may not be a VLAN 
at all, but might be a physical link, an aggregation, an IP tunnel (in 
Clearview for example), etc...  dls_vlan_hold(), for example, is the 
function used to obtain a reference to a datalink, which may not be a 
VLAN at all.

It would be to the benefit of all who trudge in that source to do some 
house cleaning in dls and at least do some renaming of symbols.

A related question for the Crossbow project is:  Does Crossbow''s goal
of
moving the VLAN implementation out of dls rectify this situation?  This 
would allow us the opportunity of refactoring some of dls''s data
structures.

-Seb

Sebastien Roy wrote On 04/25/07 10:56,:
> Folks,
>
> As most people here are aware, the dls kernel module contains a number 
> of functions and data structures which contain the string "vlan"
which
> have little to do with VLANs directly.  The dls_vlan_t, for example, 
> is actually the object that represents a datalink, which may not be a 
> VLAN at all, but might be a physical link, an aggregation, an IP 
> tunnel (in Clearview for example), etc...  dls_vlan_hold(), for 
> example, is the function used to obtain a reference to a datalink, 
> which may not be a VLAN at all.
>
> It would be to the benefit of all who trudge in that source to do some 
> house cleaning in dls and at least do some renaming of symbols.
>
> A related question for the Crossbow project is:  Does Crossbow''s
goal
> of moving the VLAN implementation out of dls rectify this situation?  
> This would allow us the opportunity of refactoring some of dls''s
data

yes, crossbow''s moving VLAN implementation out of DLS, making them VNIC
interfaces should
make the DLS code unaware of VLANs.

For the inaccurate naming currently in the Nevada gate, it makes sense 
to rename
dls_vlan_t and dls_vlan_*() to dls_link_t and dls_link_*() etc .., 
either now, or part of Clearview changes.

    Kais.
> structures.
>
> -Seb
>
> _________________________________
> clearview-discuss mailing list
> clearview-discuss at opensolaris.org

> For the inaccurate naming currently in the Nevada gate, it makes sense
 > to rename dls_vlan_t and dls_vlan_*() to dls_link_t and dls_link_*()
 > etc .., either now, or part of Clearview changes.

It''s not quite that simple, since the Nevada gate already has e.g. both
a
dls_vlan_hold() and dls_link_hold().

-- 
meem

Peter Memishian wrote:
>  > For the inaccurate naming currently in the Nevada gate, it makes
sense
>  > to rename dls_vlan_t and dls_vlan_*() to dls_link_t and dls_link_*()
>  > etc .., either now, or part of Clearview changes.
> 
> It''s not quite that simple, since the Nevada gate already has e.g.
both a
> dls_vlan_hold() and dls_link_hold().
Right.  What is a "link" today in dls is really dls''s handle
on the
underlying mac, and what is a "vlan" today is really the data-link. 
It''s all very confusing, but that was the point of my original mesage.
:-)

-Seb

On 4/26/07, Sebastien Roy <Sebastien.Roy at sun.com>
wrote:
>
> Right.  What is a "link" today in dls is really dls''s
handle on the
> underlying mac, and what is a "vlan" today is really the
data-link.
> It''s all very confusing, but that was the point of my original
mesage. :-)
>
It used to be all quite straightforward...

mac_ functions were used to access an underlying device drivers mac functions
dls_ink_ functions abstracted this for the rest of DLS''s consumption
dls_vlan_ functions acted on traffic flows separated by VLAN tag (and
a non-VLAN interface was represented as a VLAN with tag 0)
dls_client_ functions acted on traffic flows further sparated by DLSAP

When the configurable VLAN support was ripped out of DLS (and some of
the other stuff that was done late in the project) the model was
broken. It''s therefore probably best if the internals of DLS are
reviewed and the functions and data structures renamed to reflect
their purpose. If VLANs are no longer handled inside DLS then the
dls_vlan_ layer should probably go away and the dls_client_ functions
should talk directly to the dls_link_ functions.

  Paul

-- 
Paul Durrant
http://www.linkedin.com/in/pdurrant

Paul Durrant wrote:
> On 4/26/07, Sebastien Roy <Sebastien.Roy at sun.com> wrote:
>>
>> Right.  What is a "link" today in dls is really
dls''s handle on the
>> underlying mac, and what is a "vlan" today is really the
data-link.
>> It''s all very confusing, but that was the point of my original
mesage.
>> :-)
>>
> 
> It used to be all quite straightforward...
> 
> mac_ functions were used to access an underlying device drivers mac 
> functions
> dls_ink_ functions abstracted this for the rest of DLS''s
consumption
> dls_vlan_ functions acted on traffic flows separated by VLAN tag (and
> a non-VLAN interface was represented as a VLAN with tag 0)
> dls_client_ functions acted on traffic flows further sparated by DLSAP
> 
> When the configurable VLAN support was ripped out of DLS (and some of
> the other stuff that was done late in the project) the model was
> broken. It''s therefore probably best if the internals of DLS are
> reviewed and the functions and data structures renamed to reflect
> their purpose. If VLANs are no longer handled inside DLS then the
> dls_vlan_ layer should probably go away and the dls_client_ functions
> should talk directly to the dls_link_ functions.
I agree.  That would indeed be a good thing to do, and my understanding 
based on Kais'' input is that Crossbow is going to handle that 
re-organization within dls when VLAN support is moved out of dls and 
into the vnic.

-Seb