netdev - Re: [PATCH/RFC 00/11] HFSC patches

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4EB575AF.1010903@ziu.info>
Date:	Sat, 05 Nov 2011 18:43:11 +0100
From:	Michal Soltys <soltys@....info>
To:	Patrick McHardy <kaber@...sh.net>
Cc:	davem@...emloft.net, netdev@...r.kernel.org
Subject: Re: [PATCH/RFC 00/11] HFSC patches

On 11-11-05 04:48, Patrick McHardy wrote:
>
> Thanks Michal. It has been quite a while since I've last looked
> at this and this is complicated stuff, please give me a few days
> to review your patches.

Of course, and thanks for doing it. If I have any corrections, I'll add 
them as v2 versions in this thread (under respective patches).

>
>>  Apart from these, there's still one subtle thing to do w.r.t. cl_cvtmin (during
>>  init_vf(), as this value is lagged relatively to the situation at the time of
>>  enqueue).
>>
>>  On a side note, I was thinking about something like hfsc-strict or so - where
>>  [uplink] interface could be upperlimited on hfsc qdisc level, but all the class
>>  upperlimit would be otherwise gone. Not sure if anyone would be even interested
>>  in something like that at all.
>
> So classes would just use link-sharing curves? That's
> already possible, so I probably don't get your idea.
>

I mean, that upperlimit's main use is for matching [upstream] router's 
capability (as far as I've always seen this). Other scenarios where 
upperlimit is used somewhere lower, can be transformed to just proper 
linksharing ratios and realtime leaves w/o linksharking part (if 
applicable) - so thus the idea of no upperlimit at class level at all 
(and related code), but ability to define one at qdisc level (added 
during tc qdisc add hfsc ...) and executed during hfsc_dequeue().

Note - this is just a purist's idea, and I realize unacceptable in 
context of existing hfsc scheduler for many reasons (compatibility with 
exisiting configurations for once). But the idea about 
hfsc-{light,strict,pure,etc.} has been crawling in my head for a while.

Apart from that - in the sch_hfsc.c code there're few things you once 
commented out - related to myf adjustments that "overshoot" and made 
classes stay way too much under their respective linksharing curves. Do 
you have the configuration examples saved somewhere, under which it 
happened ?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html