Re: SOCK_RAW and in_pcb.c

On Thu, Mar 19, 2026 at 09:37:01AM -0700, Gleb Smirnoff wrote:
> On Thu, Mar 19, 2026 at 03:53:11AM -0400, Mark Johnston wrote:
> M> I believe, before your SMRification change, there was no lock.  We
> M> relied on the network epoch section to synchronize lookups.  Can we
> M> avoid re-introducing a lock on the input path?  AFAIR the use of SMR was
> M> motivated by needing to be able to recycle inpcbs quickly, but for raw
> M> sockets this is probably not much of a concern...?
> M> 
> M> > Here is the plan:
> M> > - a shared code between IPv4 and IPv6
> M> > - rawpcb database per VNET that has: a list of unbound pcbs and tree of
> M> >   src-bound pcbs.  We could have also a tree of dst-bound and src+dst-bound,
> M> >   but I would speculate that practical hosts/routers that have a large
> M> >   (local IP address count * raw socket count) product do not exist.  The
> M> >   current hash that serves only the src+dst+proto-bound pcbs, IMHO, is too
> M> >   restrictive and supposedly only mpd5 benefits from it.  I'd speculate that
> M> >   src-bound lookup database will not degrade mpd5 performance, but will
> M> >   provide improvements for other raw users.
> M> > - the database is protected by rwlock, that is rlocked on the fast path and
> M> >   wlocked by socket(2), bind(2) and connect(2).
> M> > - setsockopt(2) needs to take care to not use raw's so_pcb as inpcb any more
> M> > 
> M> > Any comments?
> M> 
> M> I don't really like the rwlock and prefer to rely on the network epoch
> M> instead.  Other than that I think this is ok.
> 
> I'm thinking of using a tree for src-bound sockets and we don't have CK ready
> tree.  The benefit of a tree is the autotuning.  Most hosts will not spend any
> memory on the raw pcb databasem, while heavy VPN concentrators running mpd5
> will have a decently fast lookup.  Maybe rmlock(9) will be a good compromise?

Or use a hash table instead of a tree?  A chained table would be
friendlier since we can use the CK list macros, exactly as it works
today for TCP and UDP.

rmlock could also work, but would be expensive if there is some workload
which binds many short-lived sockets.