Hi Bernhard, On Wed, 12 Apr 2023 at 20:51, Bernhard Reutner-Fischer <[email protected]> wrote: > > 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 :)
Apologize, not sure why but I thought it was a comment from someone else. My bad :( > > > > > 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
