vlan patch

[Yar Tikhiy]

On Fri, Oct 21, 2005 at 09:30:33AM +0400, Gleb Smirnoff wrote:
> On Thu, Oct 20, 2005 at 12:57:21PM +0400, Yar Tikhiy wrote:
> Y> The hash code consists of literally a couple of #define's.  And the
> Y> difference between ng_vlan(4) and vlan(4) is that each ng_vlan node
> Y> gets its own instance of the hash table.  OTOH, in vlan(4) we need
> Y> to decide if the hash table will be per parent interface or a single
> Y> global instance.  In the latter case we could hash by a combination
> Y> of the VLAN tag and parent's ifindex.  Perhaps this approach will
> Y> yield more CPU cache hits during hash table lookups.  In addition,
> Y> it will be thriftier in using memory.  Locking the global hash table
> Y> should not be an issue as we can use an sx lock in this case for
> Y> optimal read access.
> 
> The sx lock is slow. We'd better use per interface hash, and thus
> get locking instantly, with per-vlan lock. In other case, we will
> acquire per-vlan lock + the sx lock on every packet. The sx lock
> actually means mtx_lock+mtx_unlock, thus we will make 3 mutex
> operations instead of one.

OK, let's forget about sx locks.  However, a per-interface hash is
associated with a _physical_ interface, hence we must find the vlan
to lock using the hash first.  If there were a physical interface
lock held by its driver in each case, it could protect the hash as
well.  Can we rely on this?

-- 
Yar