I don't know how the unicode non-breaking spaces leaked into the
previous version. Sorry about that.
Configuration
=
A box running Debian stretch is acting as a NAT'ing router.
It has a single Ethernet NIC and a wireless NIC servicing the local
LAN. These devices are bridged.
Configuration
=
A box running Debian stretch is acting as a NAT'ing router.
It has a single Ethernet NIC and a wireless NIC servicing the local
LAN. These devices are bridged. Since it has only one wired NIC
it is used to connect to both the LAN and internet via a switch.
T
Package: src:linux
Version: 4.9.30-2+deb9u1
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Configuration:
A box running Debian4.9.0-3-amd64 is acting as a NAT'ing router.
It has a single Ethernet NIC and a wireless NIC servicing the local
LAN. These devices are bridged.
On Thu, 2007-01-25 at 01:06 +0100, Patrick McHardy wrote:
> Of course he has to, just like your "atm" parameter. In case
> of stabs it would be something like "stab atm".
The difference being with "atm" he is telling the kernel
he has an ATM line, but with STAB he is telling the
kernel how it sho
On Wed, 2007-01-24 at 17:38 +0100, Patrick McHardy wrote:
> > The two RTAB's are different. Thus you must send
> > different RTAB's to pre-STAB and post-STAB kernels.
> > How is "tc" to decide which one to send? I did add
> > code that checked uname once to solve a very
> > similar problem i
On Sat, 2007-01-20 at 09:47 +0100, Patrick McHardy wrote:
> Russell Stuart wrote:
> > b. There is no compatibility problem.
>
> Again, (b). You seem to have something in mind, it would be
> easier if you would just explain exactly where you think there
> is a pro
On Fri, 2007-01-19 at 13:19 +0100, Patrick McHardy wrote:
> Russell Stuart wrote:
> > I thought that some degree of compatibility was
> > expected. At the very least the newest version
> > of "tc" must work on _any_ kernel as least as
> > well as the ver
On Thu, 2007-01-18 at 12:37 +0100, Patrick McHardy wrote:
> > Or are you proposing tc behave differently on different
> > kernel versions. (I have no problem with that, but
> > isn't it officially frowned upon?)
>
> Yes. There is no way you can make this work on old kernels,
> nobody expects that
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_s
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
On Tue, 2006-10-24 at 18:19 +0200, Patrick McHardy wrote:
> No, my patch works for qdiscs with and without RTABs, this
> is where they overlap.
Could you explain how this works? I didn't see how
qdiscs that used RTAB to measure rates of transmission
could use your STAB to do the same thing. At
On Mon, 2006-10-23 at 14:39 +0200, Patrick McHardy wrote:
> The implementation may be different, but the intention and the
> result is the same. I probably would mind less if it wouldn't
> affect userspace compatibility, but we need to carry this stuff
> for ever even if we add another implementati
On Thu, 2006-10-19 at 16:38 +0200, Patrick McHardy wrote:
> I still think this patch shouldn't go in. There's no point in doing the
> same thing twice, and I haven't heard a compelling argument why it has
> to be done in a way that only helps qdiscs using rtabs while ignoring
> statistics and estim
Signed-off-by: Russell Stuart <[EMAIL PROTECTED]>
---
diff -Nurp kernel-source-2.6.16.orig/include/linux/pkt_sched.h
kernel-source-2.6.16/include/linux/pkt_sched.h
--- kernel-source-2.6.16.orig/include/linux/pkt_sched.h 2006-03-20
15:53:29.0 +1000
+++ kernel-source-2.6.16/include/
On Wed, 2006-08-09 at 07:33 -0400, jamal wrote:
> > Jamal - unless there are other outstanding issues I have
> > missed or someone has had second thoughts this means you
> > should be OK with the patch going in. Can we get it into
> > Dave M's tree now?
>
> Hi Russell,
>
> My apologies; at some
On Mon, 2006-07-31 at 09:06 +1000, Russell Stuart wrote:
> It has gone quiet again. In my mind the one unresolved issue
> is whether Patrick intended to remove RTAB with his patch.
> If not, the ATM patch as it stands will have to go in.
>
> Patrick - it would be nice to hea
On Thu, 2006-07-20 at 14:56 +1000, Russell Stuart wrote:
> On Wed, 2006-07-19 at 16:50 +0200, Patrick McHardy wrote:
> > Please excuse my silence, I was travelling and am still catching up
> > with my mails.
>
> Sorry. Had I realised you were busy I would of
> waited.
>
On Thu, 2006-07-20 at 01:00 +0400, Alexey Kuznetsov wrote:
> Hello!
So you really do exist? I thought it was just
rumour.
> Well, if fixed point arithmetics is not a problem.
It shouldn't be. Any decimal number can be expressed
as a fraction, eg:
0.00123 = 123/10
Which can be calculate
t
> size. Optimizing size and lookup speed for ethernet makes
> a lot more sense than optimizing for ADSL.
I was just responding to a point you made earlier, when
you said STAB could only use 16 entries as opposed to the
256 used by RTAB. I suspect nobody would actually do that
because of th
On Tue, 2006-07-18 at 22:46 +0100, Andy Furniss wrote:
> FWIW I think it may be possible to do it Patricks' way, as if I read it
> properly he will end up with the ATM cell train length which gets
> shifted by cell_log and looked up as before. The ATM length will be in
> steps of 53 so with cel
On Sat, 2006-06-24 at 10:13 -0400, jamal wrote:
> And yes, I was arguing that the tc scheme you describe would not be so
> bad either if the cost of making a generic change is expensive.
> Patrick seems to have a simple way to compensate generically for link
> layer fragmentation, so i will not ar
On Fri, 2006-07-07 at 10:00 +0200, Patrick McHardy wrote:
> Russell Stuart wrote:
> > Unfortunately you do things in the wrong order for ATM.
> > See: http://mailman.ds9a.nl/pipermail/lartc/2006q1/018314.html
> > for an overview of the problem, and then the attached ema
On Tue, 2006-07-04 at 15:29 +0200, Patrick McHardy wrote:
> Unfortunately I still didn't got to cleaning them up, so I'm sending
> them in their preliminary state. Its not much that is missing, but
> the netem usage of skb->cb needs to be integrated better, I failed
> to move it to the qdisc_skb_cb
On 26/06/2006 9:10 PM, Patrick McHardy wrote:
5. We still did have to modify the kernel for ATM. That was
because of its rather unusual characteristics. However,
it you look at the size of modifications made to the kernel
verses the size made to the user space tool, (37 lines
versu
On 25/06/2006 12:13 AM, jamal wrote:
You can actually stop reading here if you have gathered the view at
this point that i am not objecting to the simple approach Patrick is
going with...
Perhaps this is my problem. I am not sure I understand
what Patrick is proposing. I can wait for his patc
On Fri, 2006-06-23 at 17:21 +0200, Patrick McHardy wrote:
> Not really. The randomization doesn't happen by default, but it doesn't
> influence this anyway. SFQ allows flows to send up to "quantum" bytes
> at a time before moving on to the next one. A flow that sends 75 * 20
> byte will in the eye
On Thu, 2006-06-22 at 14:29 -0400, jamal wrote:
> Russell,
>
> I did look at what you sent me and somewhere in those discussions i
> argue that the changes compensate to make the rate be a goodput
> instead of advertised throughput.
I did see that, but didn't realise you were responding to
me.
On Thu, 2006-06-15 at 11:49 +0200, Martin Devera wrote:
> At time of HTB implementation I needed to reach 100MBit speed on
> relatively slow box. The hysteresis was a way. On other side I used
> hand-made TSC based measure tool to compute exact (15%) performance
> gain. Today I'd measure it usin
ion will make life easier for the bulk of
its users.
Further documentation on the patch and its usage can be
found here:
http://www.stuart.id.au/russell/files/tc/tc-atm
Signed-off-by: Russell Stuart <[EMAIL PROTECTED]>
Signed-off-by: Jesper Dangaard Brouer <[EMAIL PROTECTED]>
---
d
ion will make life easier for the bulk of
its users.
Further documentation on the patch and its usage can be
found here:
http://www.stuart.id.au/russell/files/tc/tc-atm
This is a combined effort of Jesper Brouer and Russell
Stuart, to get these patches into the upstream kernel.
Let the discu
ion will make life easier for the bulk of
its users.
Further documentation on the patch and its usage can be
found here:
http://www.stuart.id.au/russell/files/tc/tc-atm
Signed-off-by: Russell Stuart <[EMAIL PROTECTED]>
Signed-off-by: Jesper Dangaard Brouer <[EMAIL PROTECTED]>
---
On Wed, 2006-06-14 at 11:57 +0100, Alan Cox wrote:
> The other problem I see with this code is it is very tightly tied to ATM
> cell sizes, not to solving the generic question of packetisation.
Others have made this point also. I can't speak for Jesper,
but I did consider making it generic. The
On Tue, 2006-03-21 at 14:39 -0800, Stephen Hemminger wrote:
> Back to the original question...
>
> What should the iproute2 utilities contain?
>
> Does it have to have the utsname hack to work?
Hi Stephen,
I think the resolution was:
- No to the utsname hack. Ergo the "tc" sample clause
On Tue, 2006-03-21 at 09:57 -0500, jamal wrote:
> I accessed them - unfortunately, though i am trying to, I dont
> see anything outstanding that would justify any changes to the
> hash. Lets just drop this. We can talk about other things if you want.
If you still are not convinced, then I don't se
On Mon, 2006-03-20 at 10:00 -0500, jamal wrote:
> I have to say i am scratching my head - now that i was forced to run the
> tests - to see if there is infact a scenario where you could show 2.4 to
> be better...
So that is the underlying reason you are resisting -
you just can't see that it coul
On Sun, 2006-03-19 at 11:32 -0500, jamal wrote:
> Conclusion
> --
>
> Other than fixing a bug, then new hash is at least equal to the old
> hash in about 16% of the cases and better in the rest(>80% of the
> time).
> This is true in the case of both memory abuse and worst case lookups.
>
On Sun, 2006-03-19 at 11:47 -0500, jamal wrote:
> Your scheme for least square fit for evaluating the hash results
> seems to be mostly fine for worst case lookups (I havent found a spot
> where it lied about this at least). The only problem is it doesnt take
> into consideration the spread as well
On Fri, 2006-03-17 at 09:34 -0500, jamal wrote:
> If you are unable to do this then I will. I just dont have time until this
> Sunday.
> I will not respond to any further emails which do not contain data - instead
> I am going to produce mine.
After that wrist-slap I spent some time putting togeth
On Fri, 2006-03-17 at 09:34 -0500, jamal wrote:
> - the 2.4 algorithm performs very poorly for < 8 bits if you use a
> standard mask for ALL cases except when you use a lot of memory, most of
> which is _wasted_, in which case it performs equally. There are only 8
> masks in an 8 bit ranging from l
On Thu, 2006-03-16 at 08:51 -0500, jamal wrote:
> > BTW, in this example, the new hash I suggested would be as good
> > as the 2.6 case.
> >
>
> Yes, if you used 256 buckets per hash table ;->
No - you haven't understood what the new algorithm does.
It will get the same performance of the 2.6 v
On Wed, 2006-03-15 at 22:07 -0500, jamal wrote:
> Suppose you pick octet 3 of the dst IP address and we assume the full
> range of that octet i.e a range of values 0-255
> (the details are a lot more complicated of where this byte belongs,
> example this could be part of an IPV6 address and we tak
On Wed, 2006-03-15 at 20:56 -0500, jamal wrote:
> I dont think Stephen would like that #if 0; however, this is not why
> i am speaking up;->
I put it in there so it would be easy for someone using
2.4 to revert the patch, if they felt so inclined. Stephen
let me know if you want it removed.
> Yo
On Wed, 2006-03-15 at 20:28 -0500, jamal wrote:
> The variables again are:
> a) the mask/mask size
> b) the size of the buckets available example if you are masking on 2
> bits, then it doesnt matter if you have 256 buckets - only 4 get used.
> So creating more than 4 is a waste of memory.
> c) Th
Much discussion bashing this issue to death.
(sorry, jamal - this one is CC'ed to lartc.)
Here is are revised versions of the 2 as yet unapplied
patches.
PATCH 1
===
[Has been applied.]
PATCH 2
===
In tc, the u32 sample clause uses the 2.4 hashing algorithm.
The hashing algorithm use
On Wed, 2006-03-15 at 10:21 -0500, jamal wrote:
> It could - if it can proven to maintain backward compatibility. I
> think backward compatibility would probably be fine to be defined as "it
> works with one byte".
> But you are right. It is a pain. One suggestion Stephen Hemminger had
> was to tra
On Mon, 2006-03-13 at 22:39 -0500, jamal wrote:
> Trust me - I understand this stuff;-> (I have described these two to
> many people). And i will take a look at your doc at some point.
>
> What i mean is: that you could achieve the result of stitching
> hashtables together to direct a packet to e
On Mon, 2006-03-13 at 22:10 -0500, jamal wrote:
> I will try to find the scripts.
Just the data sets will do. I can then pump it through my
python script. But before launching into this, I don't
see the choice of algorithm as very important. Yes, I
believe the 2.4 one was better. But not by s
On Mon, 2006-03-13 at 21:39 -0500, jamal wrote:
> On Tue, 2006-14-03 at 12:29 +1000, Russell Stuart wrote:
> > On Sat, 2006-03-11 at 08:11 -0500, jamal wrote:
> > > On Fri, 2006-10-02 at 12:33 +1000, Russell Stuart wrote:
> > > > This patch adds a "divisor"
On Mon, 2006-03-13 at 21:24 -0500, jamal wrote:
> If you dont mind please stop ccing lartc - they keep bouncing my mail.
OK. Somebody should fix that. A kernel net developer
not being able to post to lartc is just plain wrong.
> On Tue, 2006-14-03 at 10:31 +1000, Russell Stuart
On Sat, 2006-03-11 at 10:56 -0500, jamal wrote:
> Right - take a look at the use of hashkey with varying divisors to see
> where the 2.4 folding breaks[1]. Note you should be able to use hashkey
> instead of sample and it would work fine.
> [1] Essentially, if you teach u32 in 2.4 to spread rule
On Sat, 2006-03-11 at 08:11 -0500, jamal wrote:
> On Fri, 2006-10-02 at 12:33 +1000, Russell Stuart wrote:
> > This patch adds a "divisor" option to tc's "sample"
> > clause:
>
> While this looks right - can we have more test data with tc filte
On Mon, 2006-03-13 at 13:50 -0800, Stephen Hemminger wrote:
> On Tue, 14 Mar 2006 07:43:57 +1000
> Russell Stuart <[EMAIL PROTECTED]> wrote:
>
> > On Mon, 2006-03-13 at 10:04 -0800, Stephen Hemminger wrote:
> > > The memset fix is in current CVS. I just wasn't
On Mon, 2006-03-13 at 10:04 -0800, Stephen Hemminger wrote:
> The memset fix is in current CVS. I just wasn't going to take the
> patch that looked at utsname to decide what hash to use.
Stephen, could you describe your objections to it please?
-
To unsubscribe from this list: send the line "uns
On Sat, 2006-03-11 at 08:11 -0500, jamal wrote:
> > On my machine tc does not parse filter "sample" for the u32
> > filter. Eg:
> >
> > tc filter add dev eth2 parent 1:0 protocol ip prio 1 u32 ht 801: \
> > classid 1:3 \
> > sample ip protocol 1 0xff match ip protocol 1 0xff
> > Illeg
On Sat, 2006-03-11 at 09:01 -0500, jamal wrote:
> > sample never worked 100% of the time with that hash. It works _most_ of
> > the time with 256 buckets. Infact it will work some of the time as it is
> > right now with 2.6.x. Can you post the output of tc -s filter ls on 2.6
> > with and without y
55 matches
Mail list logo
