On di, 25 jun 2019 10:54:55 +0200, Oleksij Rempel wrote: > On 25.06.19 10:43, David Jander wrote: > >On Tue, 25 Jun 2019 09:30:09 +0200 > >Oleksij Rempel <o.rempel@xxxxxxxxxxxxxx> wrote: > > > >>Hello all, > >> > >>We already had a discussion about the J1939 use case for server > >>implementation. Short description of the challenge will looks as follow: > >>- main socket is listening on DST address and PGN. > >>- as soon as connection was requested from peer the server will > >> create new connect()ed socket with SRC, DST addresses and PGN. > >> > >>With current stack implementation both sockets (main and connected) will > >>receive same packages. At least with huge packages it will start to be > >>not really good :). > >> > >>To solve this issue we have following variants: > >>variant a: > >> - all sockets can receive everything (as currently implemented) > >>variant b: > >> - only one socket will receive specific tuple. In this case kernel > >> should calculate RX "priority". Only highest priority will RX packet. > >> - all sockets with same priority will receive the matching packet > >> - socket option promisc == same priority as exact match > > > >How is this "priority" determined? > >Something like this: > > > > for each socket: > > prio = 0 > > listening on same DST or PGN ==> prio++ > > listening on same DST and PGN ==> prio++ > > connect()ed to same SRC ==> prio++ > > deliver frame to socket(s) with highest prio. > > > >Is that what you mean? > > ACK. I don't like any of these. The problem you try to solve is 'huge packet duplication where it is probably not required'. Your proposed solution puts a policy in the kernel that goes in serious conflict with a multiuser system. It is driven by a typical implementation, but did not address the problem you try to solve. In order to avoid receiving huge packets where we suspect it is not really wanted, we should not try to guess what 'a' program wants, nor implement rules that apply to 1 specific case. Instead, we should protect sockets from receiving huge packets. Why not add a socket option, that implements a ceiling on the size of received packets. If that defaults to, let's say, 1785 bytes, so anyone will out of the box receive all TP sessions, but no ETP session, then the user will not be really supprised, and we need to make only 1 clear decision during delivery. I honestly think that my proprosal puts way less decision policy in the kernel code, and effectively addresses the problem you tried to solve, without adding unnecessary multi-user restrictions. What's your thought? Kurt > > Kind regards, > Oleksij Rempel > > -- > Pengutronix e.K. | | > Industrial Linux Solutions | http://www.pengutronix.de/ | > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
