On Fri, Jul 05, 2024 at 10:33:43AM +0200, Stefano Brivio wrote:On Fri, 5 Jul 2024 10:06:12 +1000 David Gibson <david(a)gibson.dropbear.id.au> wrote: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.On Thu, Jul 04, 2024 at 11:21:21PM +0200, Stefano Brivio wrote: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.On Thu, 4 Jul 2024 14:58:34 +1000 David Gibson <david(a)gibson.dropbear.id.au> wrote: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.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 <david(a)gibson.dropbear.id.au> --- 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)?Ok, I'm going with doc/platform-requirements/ in the next spin.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.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