netdev - Re: [PATCH v3 2/2] hfsc: add link layer overhead adaption

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] [day] [month] [year] [list]

Message-ID: <20080709204248.506775otd5me5pwc@naisho.dyndns.info>
Date:	Wed, 09 Jul 2008 20:42:48 +0300
From:	"Jussi Kivilinna" <jussi.kivilinna@...et.fi>
To:	"Patrick McHardy" <kaber@...sh.net>
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH v3 2/2] hfsc: add link layer overhead adaption

Quoting "Patrick McHardy" <kaber@...sh.net>:

> Jussi Kivilinna wrote:
>> Quoting "Patrick McHardy" <kaber@...sh.net>:
>>>
>>> This means HFSC will use other packet sizes as inner qdiscs, policers,
>>> statistics etc, which I don't like very much. My original patch used
>>> the size tables to calculate the size when enqueing to the root qdisc
>>> and stored it in the cb, so all qdiscs in the hierarchy can use the
>>> same size.
>>
>> With this patch I have tried to make HFSC support link layer   
>> emulation in same way as done in HTB with rate table, so that   
>> overhead is defined on leaf qdisc (if have understood right).
>
> The difference is that with this approach you are actually
> able to make the entire qdisc hierarchy use the same size
> for calculations/statistics/etc. The rate tables only work
> in TBF based qdiscs and policers (which was always one of
> my complaints).
>
>>
>> I have used this patch to have different overhead between qdisc   
>> leafs to account for extra overhead of ipv6-in-ipv4 tunnel   
>> (redirecting traffic to IMQ device and filtering ipv4&ipv6 to   
>> corresponding leafs). If overhead/linklayer is defined on root   
>> qdisc, this wouldn't be possible?
>
> You could override the size in inner classes and qdiscs.
> Having an optional size table per qdisc would make this
> consistent from a user perspective with the top-level
> size calculation. (And I agree that including tunnel
> overhead makes sense).
>

Ok, having one table for whole qdisc tree (with overrides) sounds better.

  - Jussi

--
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