On 8/13/22 15:08, Alexander Bluhm wrote:
Hi,
While running forwarding in parallel, I have introduced a hard
barrier for parallel local protocol processing. The packets are
requeued from shared to exclusive netlock.
Unless we unlock all protocol input routines at once, we need some
mechanism from to move from one queue to the other. The problem
is, that we have to remember next protocol field and offset of the
parsed header chain.
A simple example is IPv6 hop-by-hop options precessing. This code
is MP safe and can be moved from ip6_local() to ip6_ours() to run
in parallel. If there were any options, the offset and next protocol
are stored in a mbuf tag. Without tag we know that it is a regular
IPv6 header.
Of course mbuf tags kill performance, but who uses hop-by-hop options
anyway? pf drops such packets per default.
ok?
bluhm
This may be totally irrelevant. I may not understand the problem at all.
The problem of locking queue-to-queue transfers in a multiprocessor system
was addressed at Alliant Computer a very long time ago.
Other people probably invented other solutions.
They implemented a lock for the queue links only in each type of queue
at a higher lock priority than the lock on the data.
The sending thread already held a lock on the packet data.
It took the queue field lock, transferred the packet and released both
locks.
I can't be sure which lock(s) the receiving thread held.
The point was that neither thread needed to lock both queues.
geoff steckel
