Hi cathy, I'm still thinking of a few things you mentioned in your review comments so I haven't responded to that yet.
but regarding vlans, I got the impression from your previous mail that you decided to disable fastpath for vlans because the code will be simpler. did you change your mind? the changes you mentioned below sound like hacks and might not be easy to do (especially, moving unicast_add). what's worse is that this benefits no one but vlans on legacy devices. you mentioned all these changes could be undone when legacy fastpath is removed. but I doubt this can happen anytime soon nor have I heard of any plans to do so. because of these reasons, I would say it's better to *not* enable fastpath for vlans. In my opinion, maintainability of the framework far outweigh performance benefits to a few legacy devices. thanks eric On Thu, Feb 12, 2009 at 03:25:52PM -0800, Cathy Zhou wrote: > Hi the Crossbow team, > > I am testing my UV fastpath bits and I found several issues that need your > suggestion: > > 1. dladm show-usage won't work if UV fastpath is enabled. > > Since the link usage data are collected based on the statistics of the > mac_client_impl_t, and UV fastpath skips the GLDv3 processing, that won't > be available. > > I don't see a solution for this except to document this restriction. > > 2. VLAN kstats won't work. > > If we enable UV fastpath over VLANs, packets would go directly between the > lower VLAN stream and the IP stream over softmac, the VNIC (vlan) kstats > won't be updated. > > This could be work around by changing vnic_m_stat() function, to add up > the legacy VLAN kstat (e.g., kstat of ce1000). > > 3. Performance of VLAN is not optimal > > In the current Crossbow code, once a VNIC (vlan) is created, the > underlying mac is started (by the code path > vnic_dev_create()->vnic_unicast_add()->i_mac_unicast_add()->mac_start()) > even when there is no user of this VLAN. As a result, all packets will be > passed by mac and will be eventually dropped in MAC. > > This is not a preferred behavior and causes performance issues for VLANs > over legacy devices. Even we try to use the fast-path for a VLAN, there > would be two lower stream over the legacy device: the shared lower stream > and dedicated IP lower stream over the VLAN, so each packets will be > copied once and passed to two streams, and the copy on the shared lower > stream will soon be dropped in the MAC module. > > The fix to this is to not call vnic_unicast_add() for VLANs, and delay > this unicast_add() when mac_unicast_primary_add() is called for this VLAN. > Is this possible? > > Expecting your early reply. > > Thanks > - Cathy > _______________________________________________ > crossbow-discuss mailing list > crossbow-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/crossbow-discuss
