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

Message-Id: <1169100970.21535.18.camel@ras>
Date:	Thu, 18 Jan 2007 16:16:10 +1000
From:	Russell Stuart <russell-tcatm@...art.id.au>
To:	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)

On Thu, 2007-01-18 at 05:05 +0100, Patrick McHardy wrote:
> > 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.

No argument with "RTAB works as before".  But aren't
you proposing to feed it the accurate packet lengths
calculated STAB?  For example, if the VOIP IP datagram
is 60 bytes, older kernels will index RTAB by 
(60 + ethernet_header_size), STAB kernels will index
it by 159 bytes (3 ATM cells - say).  If "tc" doesn't
do a uname call or something, then it will send the
same RTAB to both kernels.  Obviously the results
returned by the RTAB lookup will be different.

If you aren't proposing to feed the RTAB lookup with
the output of STAB, then I still don't understand
why the current ATM patch isn't needed.

Or are you proposing tc behave differently on different
kernel versions.  (I have no problem with that, but
isn't it officially frowned upon?)

-
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