| created | 2024-07-27T17:21:46Z |
|---|---|
| begin | 2024-07-20T00:00:00Z |
| end | 2024-07-21T00:00:00Z |
| path | src/sys |
| commits | 2 |
| date | 2024-07-20T12:34:52Z | |||
|---|---|---|---|---|
| author | jsg | |||
| files | src/sys/dev/usb/uvideo.c | log | diff | annotate |
| message |
UVIDEO_DEBUG needs fcntl.h reported by Peter J. Philipp |
|||
| date | 2024-07-20T17:26:19Z | |||
|---|---|---|---|---|
| author | mvs | |||
| files | src/sys/kern/uipc_socket.c | log | diff | annotate |
| src/sys/netinet/udp_usrreq.c | log | diff | annotate | |
| src/sys/sys/socketvar.h | log | diff | annotate | |
| message |
Unlock udp(4) somove(). Socket splicing belongs to sockets buffers. udp(4) sockets are fully switched to fine-grained buffers locks, so use them instead of exclusive solock(). Always schedule somove() thread to run as we do for tcp(4) case. This brings delay to packet processing, but it is comparable wit non splicing case where soreceive() threads are always scheduled. So, now spliced udp(4) sockets rely on sb_lock() of `so_rcv' buffer together with `sb_mtx' mutexes of both buffers. Shared solock() only required around pru_send() call, so the most of somove() thread runs simultaneously with network stack. Also document 'sosplice' structure locking. Feedback, tests and OK from bluhm. |
|||