On Fri, Jul 05, 2024 at 10:33:43AM +0200, Stefano Brivio wrote: > On Fri, 5 Jul 2024 10:06:12 +1000 > David Gibson wrote: > > > On Thu, Jul 04, 2024 at 11:21:21PM +0200, Stefano Brivio wrote: > > > On Thu, 4 Jul 2024 14:58:34 +1000 > > > David Gibson wrote: > > > > > > > For the approach we intend to use for handling UDP flows, we have some > > > > pretty specific requirements about how SO_REUSEADDR works with UDP sockets. > > > > Specifically SO_REUSEADDR allows multiple sockets with overlapping bind()s, > > > > and therefore there can be multiple sockets which are eligible to receive > > > > the same datagram. Which one will actually receive it is important to us. > > > > > > > > Add a test program which verifies things work the way we expect, which > > > > documents what those expectations are in the process. > > > > > > > > Signed-off-by: David Gibson > > > > --- > > > > contrib/udp-behaviour/.gitignore | 1 + > > > > contrib/udp-behaviour/Makefile | 45 ++++ > > > > contrib/udp-behaviour/common.c | 66 ++++++ > > > > contrib/udp-behaviour/common.h | 47 ++++ > > > > contrib/udp-behaviour/reuseaddr-priority.c | 240 +++++++++++++++++++++ > > > > 5 files changed, 399 insertions(+) > > > > > > I reviewed these (10/11 and 11/11) a bit lightly, but they look sane to > > > me. I just wonder: wouldn't it be better to have > > > contrib/linux/udp-behaviour instead, so that it's consistent with the > > > other stuff unter contrib/ (project names, kind of)? > > > > Well.. if we ever port to something non-Linux, we'll need the same > > socket behaviour there. Indeed, that's one reason I think having > > these test programs is valuable. So I don't think 'linux/' is a great > > pick. > > Oh, oops, I thought SO_REUSEADDR were specific to Linux, that's why I > was suggesting linux/, but it's actually supported by all the BSDs. RIght. I believe SO_REUSEPORT is Linux specific, but the weaker SO_REUSEADDR is much older, and is all I need for the things I have planned. > > In some ways contrib/ isn't really the right place for this. Maybe > > it would be better under doc/? But at the moment that's more user > > facing than developer facing documentation. > > I would still say it's documentation and it can happily fit under doc/. > Distribution packages don't copy the whole doc/ (to /usr/share/doc/) > anyway. Ok, I'm going with doc/platform-requirements/ in the next spin. > > Or test/kernel/? But it's not something we want to check regularly, > it's really an example to help with development. > > All in all, I don't have a strong preference, doc/ looks like a better > fit to me, but contrib/ isn't problematic either. > -- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson