crossbow discuss - Jan 2009 - why vlan tag is retained in promisc mode

In current Crossbow''s implementation, vlan tag seems to be
unconditionally retained for promisc mode listener even when
MAC_OPEN_FLAGS_TAG_DISABLE is not specified.
I saw comments in mac_rx_deliver() saying that this is deliberately
designed like this.

I''m wondering why we design it like this (choose not to respect
MAC_OPEN_FLAGS_TAG_DISABLE flag for promisc mode listener)?
Or am I missing anything here?

Max

Max,

On Jan 15, 2009, at 3:11 AM, Max Zhen wrote:
> In current Crossbow''s implementation, vlan tag seems to be
> unconditionally retained for promisc mode listener even when
> MAC_OPEN_FLAGS_TAG_DISABLE is not specified.
> I saw comments in mac_rx_deliver() saying that this is deliberately
> designed like this.
>
> I''m wondering why we design it like this (choose not to respect
> MAC_OPEN_FLAGS_TAG_DISABLE flag for promisc mode listener)?
> Or am I missing anything here?
dls/dld in some cases need access to the VLAN tag, and we always pass  
it up to the promisc callback and let them do the VLAN tag stripping  
when needed.

However if the VLAN is used by Xen it should not be passed up, since  
we don''t want xnbo to do the stripping itself, or the domains to see  
the tags.

The flag you are referring to above is only applicable for the TX  
datapath. I would propose adding a separate flag to mac_promisc_add(),  
e.g. MAC_PROMISC_FLAGS_VLAN_TAG_STRIP, to allow a client to request  
that all packets should be stripped from their VLAN tag before passed  
to the promisc callback. This flag could then be set by xnbo.

Nicolas.
>
>
> Max
> _______________________________________________
> crossbow-discuss mailing list
> crossbow-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/crossbow-discuss
-- 
Nicolas Droux - Solaris Kernel Networking - Sun Microsystems, Inc.
droux at sun.com - http://blogs.sun.com/droux

Nicolas Droux wrote:
> Max,
>
> On Jan 15, 2009, at 3:11 AM, Max Zhen wrote:
>
>> In current Crossbow''s implementation, vlan tag seems to be
>> unconditionally retained for promisc mode listener even when
>> MAC_OPEN_FLAGS_TAG_DISABLE is not specified.
>> I saw comments in mac_rx_deliver() saying that this is deliberately
>> designed like this.
>>
>> I''m wondering why we design it like this (choose not to
respect
>> MAC_OPEN_FLAGS_TAG_DISABLE flag for promisc mode listener)?
>> Or am I missing anything here?
Hi Nicolas,

Thanks for your response :).
>
> dls/dld in some cases need access to the VLAN tag, and we always pass 
> it up to the promisc callback and let them do the VLAN tag stripping 
> when needed.
I see.
>
> However if the VLAN is used by Xen it should not be passed up, since 
> we don''t want xnbo to do the stripping itself, or the domains to
see
> the tags.
Yes, and I suspect that this is currently causing
6791678.
>
> The flag you are referring to above is only applicable for the TX 
> datapath. 
Hmmm...I see below code in mac_rx_deliver():
===============================            if (mcip->mci_nvids == 1
&&
                !(mcip->mci_state_flags & MCIS_TAG_DISABLE)) {
                [...cut...]
                mp_chain = mac_strip_vlan_tag_chain(mp_chain);
            }
===============================It looks to me that MCIS_TAG_DISABLE (which is
derived from
MAC_OPEN_FLAGS_TAG_DISABLE) is a flag that is been used in RX 
path...confused :(.
> I would propose adding a separate flag to mac_promisc_add(), e.g. 
> MAC_PROMISC_FLAGS_VLAN_TAG_STRIP, to allow a client to request that 
> all packets should be stripped from their VLAN tag before passed to 
> the promisc callback. This flag could then be set by xnbo.
Sounds reasonable to me :), thanks Nicolas!

Max
>
> Nicolas.
>
>>
>>
>> Max
>> _______________________________________________
>> crossbow-discuss mailing list
>> crossbow-discuss at opensolaris.org
>> http://mail.opensolaris.org/mailman/listinfo/crossbow-discuss
>

What is "promiscuous mode" these days, and to which crossbow component
does it apply in this context? It''s not just for snoop any more, right?

Fred

Max Zhen wrote:
> In current Crossbow''s implementation, vlan tag seems to be
> unconditionally retained for promisc mode listener even when
> MAC_OPEN_FLAGS_TAG_DISABLE is not specified.
> I saw comments in mac_rx_deliver() saying that this is deliberately
> designed like this.
> 
> I''m wondering why we design it like this (choose not to respect
> MAC_OPEN_FLAGS_TAG_DISABLE flag for promisc mode listener)?
> Or am I missing anything here?
> 
> Max
> _______________________________________________
> crossbow-discuss mailing list
> crossbow-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/crossbow-discuss

Hi Max,

On Jan 15, 2009, at 8:02 PM, Max Zhen wrote:
> Hmmm...I see below code in mac_rx_deliver():
> ===============================>           if (mcip->mci_nvids == 1
&&
>               !(mcip->mci_state_flags & MCIS_TAG_DISABLE)) {
>               [...cut...]
>               mp_chain = mac_strip_vlan_tag_chain(mp_chain);
>           }
Good catch, this should be using MCIS_STRIP_DISABLE. I filed 6794884  
for this one.

Thanks,
Nicolas.

-- 
Nicolas Droux - Solaris Kernel Networking - Sun Microsystems, Inc.
droux at sun.com - http://blogs.sun.com/droux

On Jan 16, 2009, at 8:19 AM, Fred Oliver wrote:
> What is "promiscuous mode" these days, and to which crossbow
component
> does it apply in this context? It''s not just for snoop any more,  
> right?
The main difference is that mac now provides a way for a MAC client to  
specify promiscuous callbacks which are separate from receive  
callbacks. The receive callback still only gets the traffic it expects  
(i.e. its unicast + registered mcast + bcast) and can be kept simple,  
while the promisc callback gets the additional traffic.

At the driver API level the semantics are the same as they were  
before, i.e. promiscuous mode for the device is set through the  
mc_setpromisc callback.

Nicolas.

-- 
Nicolas Droux - Solaris Kernel Networking - Sun Microsystems, Inc.
droux at sun.com - http://blogs.sun.com/droux