netdev - Re: [PATCH 2/2]: [NET_SCHED]: Making rate table lookups more flexible.

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: <Pine.LNX.4.61.0709022006380.20071@ask.diku.dk>
Date:	Sun, 2 Sep 2007 20:56:27 +0200 (CEST)
From:	Jesper Dangaard Brouer <hawk@...u.dk>
To:	Patrick McHardy <kaber@...sh.net>
Cc:	Jesper Dangaard Brouer <jdb@...x.dk>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH 2/2]: [NET_SCHED]: Making rate table lookups more flexible.

On Sun, 2 Sep 2007, Patrick McHardy wrote:

> Jesper Dangaard Brouer wrote:
>>
>> On Sat, 1 Sep 2007, Patrick McHardy wrote:
>>
>
>> This is not a ATM/ADSL only patch.  This patch simply adds more
>> flexibility to the rate tables.  Afterwards we can start the discussion
>> about how to use this new flexibility in tc/iproute2.
>
> I know, but that discussion should happen *before* merging any
> changes to the kernel.

Let not try to solve too many things at once. We need to do this in small 
steps. Please, lets not start long and borrowing discussion again, where 
we try to solve too many things at once.


> Its pointless to add functionality that
> won't be used afterwards or may need to be done differently.

I believe that the functionality _will_ be used, also in the general case.

Lets focus on the general case, where the functionality actually is 
needed right away.

In the general case:

- The rate table needs to be aligned (cell_align=-1).
   (currently, we miscalculates up to 7 bytes on every lookup)

- The existing tc overhead calc can be made more accurate.
   (by adding overhead before doing the lookup, instead of the
    current solution where the rate table is modified with its
    limited resolution)


Patrick, note that your STAB solution will _not_ work without the rate 
table alignment.


See you!
   Jesper Brouer

--
-------------------------------------------------------------------
MSc. Master of Computer Science
Dept. of Computer Science, University of Copenhagen
Author of http://www.adsl-optimizer.dk
-------------------------------------------------------------------
-
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