vlan patch

[Gleb Smirnoff]

On Fri, Oct 21, 2005 at 11:46:07AM +0400, Yar Tikhiy wrote:
Y> > Or are you going to implement per-vlan lock? Is this going to be a benefit?
Y> > Since all packets on trunk are serialized by NIC driver, can there be any
Y> > benefit in creating a mutex per vlan interface, not per vlan trunk?
Y> 
Y> I think you make a good point.  Indeed, today 2 threads won't process
Y> at once 2 vlan packets coming from the same parent interface.  The
Y> curious question is whether this state of matters will stay forever.
Y> The other approach would be to have separate threads for ip_input,
Y> ipfw, ip_output, and the rest of network stack functions, but it
Y> appears too inefficient in our case due to the overhead of context
Y> switches and locking.  So I agree that locking vlans per trunk is
Y> better today.
Y> 
Y> Do you think we should stick the vlan mutex into struct ifnet, too,
Y> along with the pointer to the vlan hash?  Perhaps, it's time to
Y> separate vlan-related fields into a separate struct?

Not sure yet. Now we have only if_nvlans in ifnet, right? If we
eliminate the global vlan list search, then we need to invent
some if_vlantrunk structure, where we are going to have at least:

  - nvlans
  - mutex
  - hash

The question is whether should we embed the structure into ifnet,
or allocate it on first vlan created and store only pointer in ifnet.

Embedding removes one pointer derefernce and that's good. However
embedding enlarges size of ifnet.

Dynamic allocation has one more benefit - we can leave vlan interfaces
when the parent is destroyed. However, I'm not sure this is a positive
feature.

-- 
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE