Re: SOCK_RAW and in_pcb.c

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?

-- 
Gleb Smirnoff