On Wed, Aug 13, 2025 at 5:55 AM Menglong Dong <menglong8.d...@gmail.com> wrote: > > On Sun, Aug 3, 2025 at 4:32 PM Jason Xing <kerneljasonx...@gmail.com> wrote: > > > > On Sun, Aug 3, 2025 at 12:00 PM Menglong Dong <menglong8.d...@gmail.com> > > wrote: > > > > > > On Sun, Aug 3, 2025 at 10:54 AM Jason Xing <kerneljasonx...@gmail.com> > > > wrote: > > > > > > > > On Sun, Aug 3, 2025 at 9:59 AM Menglong Dong <menglong8.d...@gmail.com> > > > > wrote: > > > > > > > > > > On Sat, Aug 2, 2025 at 9:06 PM Jason Xing <kerneljasonx...@gmail.com> > > > > > wrote: > > > > > > > [......] > > > > > > > > I'm trying to picture what the usage can be in the userland as you > > > > pointed out in the MD5 case. As to the client side, it seems weird > > > > since it cannot detect and know the priority of the other side where a > > > > few sockets listen on the same address and port. > > > > > > For the server side, it needs to add all the clients information > > > with the TCP_MD5SIG option. For socket1 that binded on the > > > eth0, it will add all the client addresses that come from eth0 to the > > > socket1 with TCP_MD5SIG. So the server knows the clients. > > > > Right, but I meant the _client_ side doesn't know the details of the > > other side, that is to say, the server side needs to keep sure the > > client server easily connects to your preferred listener regardless of > > what the selection algorithm looks like. In terms of what you > > depicted, I see your point. One question is if the kernel or API > > provides any rules and instructions to the users that on the server > > side the sk1 must be selected in your case? Is it possible for other > > cases where the sk2 is the preferable/ideal one? I'm not sure if it's > > worth 'fixing' it in the kernel. > > What does sk2 represent here? I don't think that the sk2 should > be preferable. For now, it is selected by the creating order, and > there should not be a case that relies on the socket creation > order......would it? > > So the socket should be selected by priority, and sk1, which is binded > on eth0, has higher priority, which is awarded by the users. > > I noticed that the net-next is open, so we can use Kuniyuki's > solution instead, which is better for the performance ;)
I'll post a series next week when Eric is back.
