Messages in this thread | | | From | Vinicius Costa Gomes <> | Subject | Re: 回复: INFO: rcu detected stall in tc_modify_qdisc | Date | Thu, 30 Jul 2020 14:01:05 -0700 |
| |
Hi Eric,
Eric Dumazet <eric.dumazet@gmail.com> writes:
>> I admit that I am on the fence on that argument: do not let even root >> crash the system (the point that my code is crashing the system gives >> weight to this side) vs. root has great powers, they need to know what >> they are doing. >> >> The argument that I used to convince myself was: root can easily create >> a bunch of processes and give them the highest priority and do >> effectively the same thing as this issue, so I went with a the "they >> need to know what they are doing side". >> >> A bit more on the specifics here: >> >> - Using a small interval size, is only a limitation of the taprio >> software mode, when using hardware offloads (which I think most users >> do), any interval size (supported by the hardware) can be used; >> >> - Choosing a good lower limit for this seems kind of hard: something >> below 1us would never work well, I think, but things 1us < x < 100us >> will depend on the hardware/kernel config/system load, and this is the >> range includes "useful" values for many systems. >> >> Perhaps a middle ground would be to impose a limit based on the link >> speed, the interval can never be smaller than the time it takes to send >> the minimum ethernet frame (for 1G links this would be ~480ns, should be >> enough to catch most programming mistakes). I am going to add this and >> see how it looks like. >> >> Sorry for the brain dump :-) > > > I do not know taprio details, but do you really need a periodic timer > ?
As we can control the transmission time of packets, you are right, I don't.
Just a bit more detail about the current implementation taprio, basically it has a sequence of { Traffic Classes that are open; Interval } that repeats cyclicly, it uses an hrtimer to advance the pointer for the current element, so during dequeue I can check if a traffic class is "open" or "closed".
But again, if I calculate the 'skb->tstamp' of each packet during enqueue, I don't need the hrtimer. What we have in the txtime-assisted mode is half way there.
I think this is what you had in mind.
Cheers, -- Vinicius
| |