On Tue, 11 Apr 2023 22:58:00 +0200 Clément Péron <[email protected]> wrote:
> Hi Pacien, > > On Tue, 11 Apr 2023 at 00:54, pacien <[email protected]> wrote: > > > > I worked on my own version of this, before seeing that this one was > > already posted to the list. Sorry for the collision. > > > > Message-Id: <[email protected]> > > > > It differs mainly in the terminology: it talks about the SKB priority > > instead of the CoS. Though it should perhaps be the "socket priority" > > instead? The VLAN CoS mapping isn't automatic. > > > > It also differs a bit in the way errors are handled, and puts the > > priority in the client_data struct with the rest of the settings. > > > > <peron.clem at gmail.com>: > > > I'm still testing this patch and I'm unsure if we need to set the > > > priority for all the sockets. > > > [...] > > > udhcp_send_raw_packet() set the priority and not > > > udhcp_send_kernel_packet(). > > > > It seems that the former is used for multicast, the latter for unicast, > > used in particular for renew and release. So things should probably be > > kept consistent here. > > > > <rep.dot.nop at gmail.com>: > > > > > +//usage: "\n -y PRIORITY CoS value 0 .. 7, default 0" > > > > > > I don't see that you would cap the value to 7 anywhere, do you? > > > The manpage seems to imply that 0..6 can be used by unprivileged users, > > > higher values require CAP_NET_ADMIN which is fine per se; I assume the > > > kernel does enough sanity-checking so we can attempt to pass whatever > > > the user said. > > > > I believe 0 to 7 would correspond to VLAN CoS (PCP)? > > Though that should not be limited here for the socket priority. > > I agree with you for both. We should avoid using CoS terminology and > not limit the value. > > I didn't get any response from maintainers and I'm not sure they are > interested in this feature so I will not work on it. Well, at least i did reply, so "didn't get any response from maintainers" is not really fair, isn't it. Denys devotes alot of spare time and yes, sometimes patches fall throught the cracks, which is unfortunate. The usual thing to do is to ping once in a while. That said, anybody is free to comment on patches sent to the list, improve them, or question their validity or usefulness. That's what this list is for :) > > If you want to update and rework this, feel free to send a v3 on top > of this series, but I doubt it will be merged... I can see that it has it's use, so if anybody is willing to apply some tiny bit more TLC then i believe there is no big problem accepting it, maybe under a knob if really needed. Would be nice if you would include bloat-o-meter stats. See 'make baseline; apply the patch; make bloatcheck' and include the output in the commit message so folks are aware of the costs of that functionality, please. If it's not too excessive, we may not need a config knob, or we may, if it's not considered generally useful. cheers, _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
