Page MenuHomeFreeBSD

[sockbuf] Don't expose lock details when isn't needed
Needs RevisionPublic

Authored by davide on Feb 9 2015, 2:34 AM.

Details

Diff Detail

Lint
Lint Skipped
Unit
Unit Tests Skipped

Event Timeline

davide updated this revision to Diff 3699.Feb 9 2015, 2:34 AM
davide retitled this revision from to [sockbuf] Don't expose lock details when isn't needed.
davide updated this object.
davide edited the test plan for this revision. (Show Details)
davide added reviewers: kmacy, np, rrs, lstewart, rwatson.
davide set the repository for this revision to rS FreeBSD src repository.
davide added a subscriber: Unknown Object (MLST).

I plan to commit this in two days or such, so if there are objections, please raise them.

julian added a subscriber: julian.Feb 11 2015, 8:04 AM

Is the reason here to just make the lines shorter or is there a deeper reason? (e.g. to prepare for some upcoming change)

Mainly for consistency at this point with whatever else it's used in the stack.

rwatson edited edge metadata.Feb 11 2015, 8:38 AM

Seems reasonable. I'm slightly surprised that any code other than sbwait() actually implements the sleep on sb_acc, and wonder if either a use of abstraction improvement, or an actual abstraction improvement, is needed to fix t4_ddp.c.

rwatson requested changes to this revision.Feb 11 2015, 8:46 AM
rwatson edited edge metadata.

Looks like some serious transcription errors are in this patch.

sys/kern/uipc_sockbuf.c
225

Should this be so->so_rcv?

234

Should this be so->so_rcv?

This revision now requires changes to proceed.Feb 11 2015, 8:46 AM

Robert,
an added (somewhat related) note.
SCTP has already its own sockbuf(s) and this makes integration very hackish in the tree. IIRC glebius experienced this himself while working on sendfile(), and I'm pretty sure rrs@ is kind of familiar with the problem. Introducing a better abstraction for sockbuf might help with this.

sys/kern/uipc_sockbuf.c
234

Thanks for spotting i'll fix up and upload a new patch.

rrs edited edge metadata.Nov 9 2015, 3:25 PM

The socket buffer with SCTP is just not something thats workable. There are
all sorts of pre-defined notions that closely align a socket buffer to stream-of-bytes
semantics of TCP. With UDP its never an issue, since you have all un-ordered who
cares up come the messages.

With SCTP there are all sorts of interesting ordering constraints and settings that
make it so that you can't just read from a linear socket buffer.

We definitely would need a completely different abstraction!

kmacy resigned from this revision.Apr 9 2018, 8:05 PM