hat sch->limit is at least 1. We couldn't come up with a
meaningful behavior for sch->limit being zero, so we defined the basis
case of skbprio_enqueue() as sch->limit one. If there's a guarantee that
qdisc_dev(sch)->tx_queue_len is always greater than zero, we don't need
the max().
[ ]'s
Michel Machado
On 07/09/2018 05:40 PM, Marcelo Ricardo Leitner wrote:
On Mon, Jul 09, 2018 at 05:03:31PM -0400, Michel Machado wrote:
On 07/09/2018 03:53 PM, Marcelo Ricardo Leitner wrote:
On Mon, Jul 09, 2018 at 02:18:33PM -0400, Michel Machado wrote:
On 07/09/2018 11:44 AM, Marcelo Ricardo Leitner wrote
On 07/09/2018 03:53 PM, Marcelo Ricardo Leitner wrote:
On Mon, Jul 09, 2018 at 02:18:33PM -0400, Michel Machado wrote:
On 07/09/2018 11:44 AM, Marcelo Ricardo Leitner wrote:
On Sat, Jul 07, 2018 at 03:43:55PM +0530, Nishanth Devarajan wrote:
net/sched: add skbprio scheduer
Skbprio (SKB
both qdiscs because the enqueueing and dequeueing costs of both qdics
are O(1). Notice that the "extra work" (i.e. dropping lower priority
packets) is a key aspect of skbprio since it gives routers a cheap way
to choose which packets to drop during a DoS.
[ ]'s
Michel Machado
ags other than the expected ones.
*Allow dumping the pure flags.
Original idea by Jamal Hadi Salim
Signed-off-by: Qiaobin Fu
Reviewed-by: Michel Machado
---
[...]
@@ -41,6 +44,25 @@ static int tcf_skbedit(struct sk_buff *skb, const struct
tc_action *a,
if (d->flags & SKBEDIT_
On 06/20/2018 07:53 AM, Jamal Hadi Salim wrote:
On 19/06/18 08:39 AM, Michel Machado wrote:
Notice that, different from skbmod, there's no field parm->flags in
skbedit. Skbedit infers the flags in d->flags from the presence of the
parameters of each of its a
lity
with user space as pointed out by Marcelo Ricardo Leitner. Our solution
was to add TCA_SKBEDIT_FLAGS, so SKBEDIT_F_INHERITDSFIELD and future
flag-only actions can be added.
[ ]'s
Michel Machado
On 09/05/18 01:37 PM, Michel Machado wrote:
On 05/09/2018 10:43 AM, Jamal Hadi Salim wrote:
On 08/05/18 10:27 PM, Cong Wang wrote:
On Tue, May 8, 2018 at 6:29 AM, Jamal Hadi Salim
wrote:
I like the suggestion of extending skbmod to mark skbprio based on ds.
Given that DSprio would no
On 05/10/2018 01:38 PM, Cong Wang wrote:
On Wed, May 9, 2018 at 7:09 AM, Michel Machado wrote:
On 05/08/2018 10:24 PM, Cong Wang wrote:
On Tue, May 8, 2018 at 5:59 AM, Michel Machado
wrote:
Overall it looks good to me, just one thing below:
+struct Qdisc_ops gkprio_qdisc_ops
have to increment low prio accounting if their
space is used.
I don't understand the point you are making here. Could you develop it
further?
[ ]'s
Michel Machado
On 05/08/2018 10:24 PM, Cong Wang wrote:
On Tue, May 8, 2018 at 5:59 AM, Michel Machado wrote:
Overall it looks good to me, just one thing below:
+struct Qdisc_ops gkprio_qdisc_ops __read_mostly = {
+ .id = "gkprio",
+ .priv_size = siz
On 05/08/2018 09:29 AM, Jamal Hadi Salim wrote:
On 08/05/18 08:59 AM, Michel Machado wrote:
Overall it looks good to me, just one thing below:
+struct Qdisc_ops gkprio_qdisc_ops __read_mostly = {
+ .id = "gkprio",
+ .priv_size = siz
for us. I
don't see making this queue classful as a problem per se, but I suggest
leaving it as a future improvement for when someone can come up with a
useful scenario for it.
[ ]'s
Michel Machado
13 matches
Mail list logo
