netdev - Re: [PATCH 2/7] ATM cell alignment.

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: <48053D45.40307@andyfurniss.entadsl.com>
Date:	Wed, 16 Apr 2008 00:41:57 +0100
From:	Andy Furniss <lists@...yfurniss.entadsl.com>
To:	Jesper Dangaard Brouer <hawk@...u.dk>
CC:	Stephen Hemminger <stephen.hemminger@...tta.com>,
	netdev <netdev@...r.kernel.org>,
	"David S. Miller" <davem@...emloft.net>,
	Patrick McHardy <kaber@...sh.net>
Subject: Re: [PATCH 2/7] ATM cell alignment.

Jesper Dangaard Brouer wrote:
> On Sun, 13 Apr 2008, Andy Furniss wrote:

>> I see overhead is unsigned short. For me using pppoa/vc mux my 
>> overhead is IP + 10. I am shaping on eth so skb->len is IP+14 hence I 
>> need a negative overhead.
> 
> I'm not completely sure I understand how you end up with a negative 
> overhead.  But I guess what you are saying, is that you need to remove 
> the MAC header from the equation is it has already been added to 
> skb->len (as you are doing routed and not bridged AAL5 encap).

Yep I think there are only two cases that will hit this one.

> 
> That makes a good point for a _seperate_ patch (by you ;-)) where we 
> change the overhead to be signed.  Or else you can do a userspace TC 
> patch that abuse the cell_align, as you mentioned below, to express a 
> negative overhead. (I'm trying to say, lets not mix these things... 
> please!)

Fair enough, I suppose doing it with overhead could be more dangerous 
for accidental user misconfiguration than just in TC.

> 
> 
>> Recently built a 2.6.25-rc7 and noticed the cell_align has been added 
>> and the tables jigged.
> 
> Yes, the tables has been aligned to 2^n and avoids underestimation. 
> Thus, with upto 2^4 (16) the table aligns to 48 bytes (ATM cell payload 
> size), standard TC uses 2^3. (If I remember correctly you, did comment 
> on the patch so you must have read it ;-)).

Hmm did I - was that the post where I wanted overhead to be bigger for 
ingress shaping - what is it with me and overhead :-)

> 
> ps. I'm currently on a roadtrip down the west-coast of USA, so I only 
> have periodic wifi coverage at different campgrounds...

Have a good holiday.

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