netdev - Re: [PATCH REPOST 1/2] NET: Accurate packet scheduling for ATM/ADSL (kernel)

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: <45AEF219.2060304@trash.net>
Date:	Thu, 18 Jan 2007 05:05:45 +0100
From:	Patrick McHardy <kaber@...sh.net>
To:	Russell Stuart <russell-tcatm@...art.id.au>
CC:	hadi@...erus.ca, netdev@...r.kernel.org,
	David Miller <davem@...emloft.net>,
	Jesper Dangaard Brouer <hawk@...u.dk>
Subject: Re: [PATCH REPOST 1/2] NET:	Accurate	packet	scheduling	for	ATM/ADSL
 (kernel)

Russell Stuart wrote:
> On Thu, 2006-11-30 at 14:07 +0100, Patrick McHardy wrote: 
> 
>>Qdiscs don't use RTABs to measure rates but to calculate
>>transmission times. Transmission time is always related
>>to the length, the difference between our patches is that
>>you modify the RTABs in advance to include the overhead
>>in the calculation, my patch changes the length used to
>>look up the transmission time. Which works with or
>>without RTABs.
> 
> 
> Thanks, I understand now.

Glad we found some common ground :)

> I had decided that that STAB was indeed the way forward,
> and hence I should devote my time to making it work 
> with ADSL/ATM.  The only issue is now I don't have 
> any spare time right now.
> 
> Yesterday I was chatting about this at LCA 2007, and 
> it dawned on me that there is a problem with the dual
> RTAB/STAB approach.
> 
> Currently the lookup in the kernel is
>   time_to_transmit_a_packet = RTAB[packet_length_seen_by_kernel]
> 
> As I understand it, you are proposing to change that to
>   time_to_transmit_a_packet
>     = RTAB[STAB[packet_length_seen_by_kernel]]
>     = RTAB[packet_length_seen_on_the_wire]
> 
> Given RTAB is the same in both cases the results of the
> calculation will be different (and ergo wrong in one case
> or the other).  RTAB can't change and remain compatible 
> with old kernels.  Ergo this approach breaks backward 
> compatibility.

RTABs don't change, they continue to work as before. But when
an STAB is present the lookup is based on the STAB size mapping.
Neither one is wrong, RTABs calculate the transmission time based
only on the specified rate, RTABs + STABs calculate the
transmission time based on the rate, but include external overhead.

> I can't see any way forward but to break the link 
> between RTAB and STAB.  Personally I think this is a 
> good thing, as I think STAB should replace RTAB 
> completely.  One way to do this is to give the kernel
> STAB + transmission rate, so the calculation above
> becomes:
> 
>   time_to_transmit_a_packet
>     = STAB[packet_length_seen_by_kernel] * transmission_rate
> 
> RTAB disappears in new kernels, and the compatibility
> problem goes with it.

(STAB[..] / transmission_rate)

Removing RTABs would break compatibilty, I don't really see why
adding STABs would.
-
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