* Comparison of several congestion control algorithms
From: Baruch Even @ 2005-05-28 21:19 UTC (permalink / raw)
To: netdev, Stephen Hemminger; +Cc: Doug Leith
Hello,
I wanted to point you to a comparison of congestion control algorithm
done at the Hamilton Institute. These experiments compare Scalable-TCP,
High-Speed TCP, FAST-TCP, BIC-TCP, H-TCP and Standard TCP. They compared
fairness, compatibility with TCP and link utilisation.
You can find the results and a report at http://hamilton.ie/net/eval/
Regards,
Baruch
^ permalink raw reply
* Re: [PATCH] r8169: support restricting speed+duplex in autonegotiation
From: Richard Dawe @ 2005-05-28 20:39 UTC (permalink / raw)
To: Francois Romieu; +Cc: Ben Greear, Linux netdev
In-Reply-To: <20050528144207.GA17021@electric-eye.fr.zoreil.com>
Hello.
Francois Romieu wrote:
> Richard Dawe <rich@phekda.gotadsl.co.uk> :
> [...]
>
>>This particular code is to support the "media" option for the r8169
>>module. The "media" option is marked as deprecated in favour of ethtool.
>
>
> The current code is supposed to provide via ethtool the same function that
> the media option did in Realtek's version of the driver (i.e. mostly a
> current 'ethtool -s ethX autoneg off speed foo duplex bar').
AFAICS the current r8169 driver always autonegotiates in xMII mode.
> Afaik, neither in Realtek's code nor in the current in-kernel driver does
> the (obsolescent) "media" code do what one would expect from a "media"
> option.
My patch doesn't change the behaviour of the "media" option.
Is the "media" part of the patch confusing?
Bye, Rich =]
--
Richard Dawe [ http://homepages.nildram.co.uk/~phekda/richdawe/ ]
"You can't evaluate a man by logic alone."
-- McCoy, "I, Mudd", Star Trek
^ permalink raw reply
* [PATCH] [DECNET] Remove unnecessary initilization of unused variable entries
From: Thomas Graf @ 2005-05-28 16:26 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
This patch was supposed to be part of the neighbour tables related
patchset but apparently got lost.
Signed-off-by: Thomas Graf <tgraf@suug.ch>
---
commit eb870ca30d39dd41d9e70103aeef4d9c6e896697
tree 9a945f37582c6f1a503366fa0831916d99cba013
parent 31006b6a5e72afbc76f95fe778e6370dd820dda0
author Thomas Graf <tgraf@suug.ch> Sat, 28 May 2005 18:21:48 +0200
committer Thomas Graf <tgraf@suug.ch> Sat, 28 May 2005 18:21:48 +0200
net/decnet/dn_neigh.c | 1 -
1 files changed, 1 deletion(-)
Index: net/decnet/dn_neigh.c
===================================================================
--- 4df388ef25005542b65fc297e0d1fc45acbd1d5a/net/decnet/dn_neigh.c (mode:100644)
+++ 9a945f37582c6f1a503366fa0831916d99cba013/net/decnet/dn_neigh.c (mode:100644)
@@ -101,7 +101,6 @@
.id = "dn_neigh_cache",
.parms ={
.tbl = &dn_neigh_table,
- .entries = 0,
.base_reachable_time = 30 * HZ,
.retrans_time = 1 * HZ,
.gc_staletime = 60 * HZ,
^ permalink raw reply
* Re: PATCH: rtnetlink explicit flags setting
From: Thomas Graf @ 2005-05-28 16:16 UTC (permalink / raw)
To: jamal; +Cc: David S. Miller, netdev
In-Reply-To: <1117296041.19563.6.camel@localhost.localdomain>
* jamal <1117296041.19563.6.camel@localhost.localdomain> 2005-05-28 12:00
> > I just tested both patches for about 30 minutes. Everything OK. Feel
> > free to apply the patches.
>
> We have another problem. What tree is this against? Both patches have
> failures patching against latest davem and linus git trees.
It's against my davem-pending tree which should reflect the current
state of davem's tree so they _should_ apply on his side. In this
specific case you're probably missing the neighbour table patches.
Basically I produce diffs this way:
separate tree per patchset -> merge into testing tree ->
testing period -. merge into $person-pending -> extraction
of patches and submission.
I was trying to get some more quality control into my workflow,
so I started testing patches for 3-4 weeks to avoid fallouts
but apparently this is failing miserably at the moment due to
some broken scripts of mine.
^ permalink raw reply
* Re: PATCH: rtnetlink explicit flags setting
From: jamal @ 2005-05-28 16:00 UTC (permalink / raw)
To: Thomas Graf; +Cc: David S. Miller, netdev
In-Reply-To: <20050528121827.GQ15391@postel.suug.ch>
On Sat, 2005-28-05 at 14:18 +0200, Thomas Graf wrote:
> I wanted to have some time for testing today without the need
> to resubmit the patches. ;->
>
fair enough ;->
> I just tested both patches for about 30 minutes. Everything OK. Feel
> free to apply the patches.
We have another problem. What tree is this against? Both patches have
failures patching against latest davem and linus git trees.
I am kind of distracted right now but I could fix this later.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH] r8169: support restricting speed+duplex in autonegotiation
From: Francois Romieu @ 2005-05-28 14:42 UTC (permalink / raw)
To: Richard Dawe; +Cc: Ben Greear, Linux netdev
In-Reply-To: <429871F9.6040305@phekda.gotadsl.co.uk>
Richard Dawe <rich@phekda.gotadsl.co.uk> :
[...]
> This particular code is to support the "media" option for the r8169
> module. The "media" option is marked as deprecated in favour of ethtool.
The current code is supposed to provide via ethtool the same function that
the media option did in Realtek's version of the driver (i.e. mostly a
current 'ethtool -s ethX autoneg off speed foo duplex bar').
Afaik, neither in Realtek's code nor in the current in-kernel driver does
the (obsolescent) "media" code do what one would expect from a "media"
option.
--
Ueimor
^ permalink raw reply
* Re: [RFC] textsearch infrastructure et al v2
From: Thomas Graf @ 2005-05-28 13:58 UTC (permalink / raw)
To: Pablo Neira; +Cc: jamal, netdev
In-Reply-To: <42986A85.9060001@eurodev.net>
* Pablo Neira <42986A85.9060001@eurodev.net> 2005-05-28 14:56
> hm, i don't understand quite well, i bet that libqsearch was already
> fragment-aware.
I'll rephrase, libqsearch, according to my understanding, is not able
to do optimized scanning over borders, i.e. it uses the same naive
approach as your proposal. This isn't necessarly a weakness, it
heavly depends on the length of the pattern and the amount of
fragments.
One of the major differences between libqsearch and the textsearch
I propose is that libqsearch implements "jokers", a subset of
what ts_regexp.c does. This heavly complicates their reference
implementation of bm. Again, this isn't necessarly a weakness, since
the framework doesn't require the algorithm to actually implement
these.
I cannot really tell which of the proposals we have right now
is the best/fastest/cleanest/fanciest/whatever. For that reason
I decided to transfer as much responsibility as possibly away
from the core into the actual algorithms, respectively made
it configureable via callback functions. It is still possible
to write a ts_(kmp|bm)_state.c which saves the state of the
scanning progress but other than in libqsearch this is not
a requirement.
> For small pattern and long packets, such pattern searching on the
> fragment borders doesn't really hurt the performance.
Exactly.
> boyer-moore (BM) and other variants are definitely a must to have. I'm
> still reading some papers about string matching and practical
> applications (p2p traffic recognition based on string matching, ids, etc
> etc) and the most interesting practical results come always from the use
> of BM friends.
Absolultely, I implemented KMP because it doesn't require random
access to the text and thus serves well as a reference implementation.
I'll be glad to see your BM ported.
> I'm not familiar with those problems jamal has mentioned though, could
> they really affect the string matching infrastructure in some way? I
> truly prefer avoiding linearizing skb's.
I think we have to differ between non-linear skbs which we should have
without linearization and the scanning through real fragments.
In order to make some progress we have to answer these questions:
* Do we want to be able to search on non-linear data in general?
I say: yes
* Do we want to be able to search on non-linear data which is
not completely available and/or present at the time the search
starts? In other words, do we want a search to be interruptable
to continue later on. e.g. search over multiple skbs without
queueing them up.
I say: no
* Do we want to provide random access to the text to be searched?
If so, optionally or as a requirement? This merely has impact
on a) BM could be efficiently implemented w/o naive scanning
around the borders and b) requires the text segments to be
completely maped/prepare at the risk they'll never be used. [0]
I say: probably no
[0] This impact can be limited by having the user specify strict
searching area limits.
^ permalink raw reply
* Re: netdev-2.6, wireless queues updated
From: Domenico Andreoli @ 2005-05-28 13:33 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Netdev, Linux Kernel
In-Reply-To: <4297E93D.2060003@pobox.com>
On Fri, May 27, 2005 at 11:45:01PM -0400, Jeff Garzik wrote:
>
> And finally a patch containing _only_ the changes on the we18-ieee80211
> branch,
> http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.12-rc5-git2-ieee80211-1.patch.bz2
jeff, i am using a separate ipw2200 1.0.4 module with the proper hotplug firmware.
after i read this message i wanted to try your patch but during the
build i realized that you may have merged a different version (indeed
it looks like 1.0.0).
i don't really know what would be happened after reboot, using driver
1.0.0 and firmware for 1.0.4. i'd put a big notice in the help of ipw2*
modules about matching driver and firmware versions. mixing them is
probably a bad gift to your hardware.
yes, people should read those readmes.
cheers
domenico
-----[ Domenico Andreoli, aka cavok
--[ http://people.debian.org/~cavok/gpgkey.asc
---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
^ permalink raw reply
* Re: [PATCH] r8169: support restricting speed+duplex in autonegotiation
From: Richard Dawe @ 2005-05-28 13:28 UTC (permalink / raw)
To: Ben Greear; +Cc: Francois Romieu, Linux netdev
In-Reply-To: <4297B479.1080404@candelatech.com>
Hello.
Ben Greear wrote:
> Richard Dawe wrote:
>
>> Hello.
>>
>> Attached is a patch for drivers/net/r8169.c against Linux 2.6.11 that
>> allows adjustment of the speed and duplex advertised via
>> autonegotiation. Example usage:
>>
>> ethtool -s eth0 autoneg on speed 10 duplex half
[snip]
>> r8169: Allow adjustment of speed and duplex advertised via
>> autonegotiation
>>
>> Signed-off-by: Richard Dawe <rich@phekda.gotadsl.co.uk>
>>
>>
>> ------------------------------------------------------------------------
>>
>> --- r8169.c.orig 2005-05-27 21:12:21.000000000 +0100
>> +++ r8169.c 2005-05-27 22:14:59.000000000 +0100
[snip]
>> @@ -579,6 +583,23 @@ static void rtl8169_link_option(int idx,
>> *autoneg = p->autoneg;
>> *speed = p->speed;
>> *duplex = p->duplex;
>> +
>> + if (p->media == _10_Half)
>> + *advertising = ADVERTISED_10baseT_Half;
>> + if (p->media == _10_Full)
>> + *advertising = ADVERTISED_10baseT_Full;
>> + if (p->media == _100_Half)
>> + *advertising = ADVERTISED_100baseT_Half;
>> + if (p->media == _100_Full)
>> + *advertising = ADVERTISED_100baseT_Full;
>> + if (p->media == _1000_Full)
>> + *advertising = ADVERTISED_1000baseT_Full;
>> + if (p->media == 0xff)
>> + *advertising = ADVERTISED_10baseT_Half |
>> + ADVERTISED_10baseT_Full |
>> + ADVERTISED_100baseT_Half |
>> + ADVERTISED_100baseT_Full |
>> + ADVERTISED_1000baseT_Full;
>> }
>
>
> So, is there no way to advert just 100Mbps-half and -full ?
>
> Seems like you should be able to set each flag by itself and
> create a bit-mask of the particular flags that you want...
This particular code is to support the "media" option for the r8169
module. The "media" option is marked as deprecated in favour of ethtool.
It looks like you could control what is advertised by using the ethool
ioctls, since you can pass a bitmask to that. I can't see a way to do
that with the ethtool command, since you can only specify one pair of
"speed" and "duplex" arguments.
One thing I forgot to mention in my mail is that there is no way of
disabling autonegotiation with the r8169 driver. I started working on
this, but I don't know how to force the PHY to a particular speed+duplex
combination with autonegotation switched off. I'm guessing that
autonegotiation enabled with one advertised speed+duplex != fixed
speed+duplex.
Bye, Rich =]
--
Richard Dawe [ http://homepages.nildram.co.uk/~phekda/richdawe/ ]
"You can't evaluate a man by logic alone."
-- McCoy, "I, Mudd", Star Trek
^ permalink raw reply
* Re: [RFC] textsearch infrastructure et al v2
From: Pablo Neira @ 2005-05-28 12:58 UTC (permalink / raw)
To: Pablo Neira; +Cc: Thomas Graf, jamal, netdev
In-Reply-To: <42986A85.9060001@eurodev.net>
Pablo Neira wrote:
>> Same for my infrastructure with the difference that libqsearch uses
>> a single input buffer so no chance for non-linear data.
>
>
> hm, i don't understand quite well, i bet that libqsearch was already
> fragment-aware. Anyway the main difference is that libqsearch wasn't
> designed to be used in user space so, for example, it needed a complete
> rework to reduce dynamic memory allocations.
sorry, i meant '/s/wasn't/was/g'. libqsearch was designed to be used by
snort.
--
Pablo
^ permalink raw reply
* Re: [RFC] textsearch infrastructure et al v2
From: Pablo Neira @ 2005-05-28 12:58 UTC (permalink / raw)
To: Pablo Neira; +Cc: Thomas Graf, jamal, netdev
In-Reply-To: <42986A85.9060001@eurodev.net>
Pablo Neira wrote:
>> Same for my infrastructure with the difference that libqsearch uses
>> a single input buffer so no chance for non-linear data.
>
>
> hm, i don't understand quite well, i bet that libqsearch was already
> fragment-aware. Anyway the main difference is that libqsearch wasn't
> designed to be used in user space so, for example, it needed a complete
> rework to reduce dynamic memory allocations.
sorry, i meant '/s/wasn't/was/g'. libqsearch was designed to be used my
snort.
--
Pablo
^ permalink raw reply
* Re: [RFC] textsearch infrastructure et al v2
From: Pablo Neira @ 2005-05-28 12:56 UTC (permalink / raw)
To: Thomas Graf; +Cc: jamal, netdev
In-Reply-To: <20050528123542.GR15391@postel.suug.ch>
Thomas Graf wrote:
> * jamal <1117281581.6251.68.camel@localhost.localdomain> 2005-05-28 07:59
>
>>I dont have opinions on this since you and Pablo seem to agree on it.
to be frank, i'm still willing to propose some changes to Thomas, I'll
do soon since he's pulled my ear with this second rfc request ;).
>>What I remember is that libssearch (or whatever that thing Harald was
>>looking at) did it differently (callback invoked and it return a code
>>which said to continue or not).
>
>
> Same for my infrastructure with the difference that libqsearch uses
> a single input buffer so no chance for non-linear data.
hm, i don't understand quite well, i bet that libqsearch was already
fragment-aware. Anyway the main difference is that libqsearch wasn't
designed to be used in user space so, for example, it needed a complete
rework to reduce dynamic memory allocations.
>>Also the design should (I think you do already, just double checking) -
>>should be wary of optimizing for a specific algorithmn; i see you have
>>KMP but not Boyer-Moore for example and i am not sure what the
>>repurcassions of above approach are etc etc.
>
>
> This is a weakness of the current implementation, it could be
> addresses via the other method that I proposed. The current patch
> doesn't allow for random access over fragment borders which means
> that Boyer-Moore would require a temporary buffer with a size of
> the pattern length in order to do random access over multiple
> fragments. However, I haven't seen any infrastructure yet that can
> handle non-linear data with bm wihout a complete prefetch in the
> beginning though. You could still implement a bm by either using a
> naive search at the borders or simply define the limitation that you
> can only look at the first fragment so you'd have to linearize.
For small pattern and long packets, such pattern searching on the
fragment borders doesn't really hurt the performance. Anyway the matter
of having several algorithms will let users choose that one that suits
better their needs.
boyer-moore (BM) and other variants are definitely a must to have. I'm
still reading some papers about string matching and practical
applications (p2p traffic recognition based on string matching, ids, etc
etc) and the most interesting practical results come always from the use
of BM friends.
>>I think the best approach would be to first linearize then search.
>
>
> This is what I'm trying to avoid. ;->
sure, agree with Thomas.
Netfilter used to follow this approach in early 2.6 kernels and Patrick
McHardy demostrated with some oprofile stuff that skb_copy_bits
decreased performance.
I'm not familiar with those problems jamal has mentioned though, could
they really affect the string matching infrastructure in some way? I
truly prefer avoiding linearizing skb's.
>>The only other comment i have is on the patch you called naive regexp;
>>I think you should probably call it something else instead of regexp
>>since you invented it.
>
>
> I was never good at names, any suggestions?
nor me, i'd propose flamenco-dancing-regexp ;->.
--
Pablo
^ permalink raw reply
* Re: [RFC] textsearch infrastructure et al v2
From: Thomas Graf @ 2005-05-28 12:35 UTC (permalink / raw)
To: jamal; +Cc: netdev
In-Reply-To: <1117281581.6251.68.camel@localhost.localdomain>
* jamal <1117281581.6251.68.camel@localhost.localdomain> 2005-05-28 07:59
> I dont have opinions on this since you and Pablo seem to agree on it.
> What I remember is that libssearch (or whatever that thing Harald was
> looking at) did it differently (callback invoked and it return a code
> which said to continue or not).
Same for my infrastructure with the difference that libqsearch uses
a single input buffer so no chance for non-linear data.
> Also the design should (I think you do already, just double checking) -
> should be wary of optimizing for a specific algorithmn; i see you have
> KMP but not Boyer-Moore for example and i am not sure what the
> repurcassions of above approach are etc etc.
This is a weakness of the current implementation, it could be
addresses via the other method that I proposed. The current patch
doesn't allow for random access over fragment borders which means
that Boyer-Moore would require a temporary buffer with a size of
the pattern length in order to do random access over multiple
fragments. However, I haven't seen any infrastructure yet that can
handle non-linear data with bm wihout a complete prefetch in the
beginning though. You could still implement a bm by either using a
naive search at the borders or simply define the limitation that you
can only look at the first fragment so you'd have to linearize.
> > So basically we save the state of the segment fetching
> > instead of saving the state of the search algorithm which
> > would be way too complex for things like regular expression
> > string matching.
> >
>
> Can you explain this a little more. Didnt quiet understand.
> If you are going across skbs, dont you need to save state?
Most people look at it from the angle of iterate over text segments
and apply a text search algorithm. I inverted this and said,
start the text search algorithm and iterate over all text
segments inside the algorithm. This makes many things a lot
easier because we only have to save the state of the iterator.
This brings up another limitation though, we cannot stop a search
in progress and continue later on.
> I think the best approach would be to first linearize then search.
This is what I'm trying to avoid. ;->
> On ingress as well you are also better off to assemble fragments first
> on that side before doing text searches.
We can still do this optionally, just because we support it doesn't
mean we have to use it.
> Perhaps implementing an action like the one used by openbsd to
> "normalize" packets before a string match.
> i.e
> classifier (pkt header) --> normalize --> classifier(string match)-> ?
> Infact one could argue that if you are to scan a virus you may need
> to assemble more than one skb on ingress (essentially a message).
http://oss.sgi.com/archives/netdev/2005-05/msg00298.html
See the section after <<coffee break>>
> The only other comment i have is on the patch you called naive regexp;
> I think you should probably call it something else instead of regexp
> since you invented it.
I was never good at names, any suggestions?
^ permalink raw reply
* Re: PATCH: rtnetlink explicit flags setting
From: Thomas Graf @ 2005-05-28 12:18 UTC (permalink / raw)
To: jamal; +Cc: David S. Miller, netdev
In-Reply-To: <1117244893.6251.41.camel@localhost.localdomain>
* jamal <1117244893.6251.41.camel@localhost.localdomain> 2005-05-27 21:48
> I did check netfilter, net/sched/ tcp_diag, xfrm and they do things
> right.
OK.
> Hrm - you should probably have said that in the patch text ;->
I wanted to have some time for testing today without the need
to resubmit the patches. ;->
> I did test the one i sent - basic things and by code inspection saw
> little risk as well. Perhaps we should push mine then you can add on top
> of it.
I just tested both patches for about 30 minutes. Everything OK. Feel
free to apply the patches.
^ permalink raw reply
* Re: [PATCH 3/4] [NEIGH] neighbour table configuration and statistics via rtnetlink
From: Thomas Graf @ 2005-05-28 12:07 UTC (permalink / raw)
To: jamal; +Cc: David S. Miller, netdev
In-Reply-To: <1117244567.6251.34.camel@localhost.localdomain>
* jamal <1117244567.6251.34.camel@localhost.localdomain> 2005-05-27 21:42
> On Fri, 2005-27-05 at 18:35 +0200, Thomas Graf wrote:
>
> > I do NOT agree on moving gc_ into this architecture as well,
> > it doesn't belong there.
>
> Well, you do realize they are part of the in_dev ? ;->
Huh? They cannot be device specific, there is only one gc
per neighbour table. So even _iff_ there was a device specific
setting it wouldn't make much sense ;->
> I see a little main service header with ifindex always no different than
> IFA or IFLINK etc followed by appropriate TLVs which are nested.
I guess we could simply move NDTPA_PARMS into the devconfig family.
>
> Unfortunately i still cant find the patch - i started with a different
> approach; my immediate interest was to get events when someone made
> in_device changes. BTW, this is going to be one of the main challenges
> since there are many paths to configure these things.
Right.
> Well, if you look at the structure there is no reason they should really
> be separate; infact theres a comment:
> -----------
> struct neigh_parms parms;
> /* HACK. gc_* shoul follow parms without a gap! */
> int gc_interval;
> int gc_thresh1;
> int gc_thresh2;
> ----------
You do realize the reason for that comment? ;-> The author of
the neighbour procfs code was simply too lazy to put these
into a separate place so he introduced a nasty hack.
> > I understand your architecture and if we follow this thought
> > we'd have a "default" netdevice which repesents all default
> > settings.
>
> >From looking at the code, the default stuff seems to be "hardcoded".
> Example in the definition arp_tbl.
These are just the default values for the default parameter set.
> The model like i said is clean. There are some issues i have qualms with
> - such as IP address arrangements and tight integration with netdevices
> - but those can addressed at a later time.
What about this, we move the device specific part into the new devconfig
layer but leave the main configuration, statistics, and gc parameters
in RTM_NEIGHTBL? i.e.
arp_cache entries 2 reachable-time 23s 993msec retransmit-time 1s
key-len 4 entry-size 152 last-flush 55m 44s 572msec
gc threshold 128/512/1024 interval 30s chain-position 3
hash-rand 0x69650257/0x00000003 last-rand 1m 44s 571msec
? refcnt 1 pending-queue-limit 3 proxy-delayed-queue-limit 64
? num-userspace-probes 0 num-unicast-probes 3 num-multicast-probes 3
? min-age 1s base-reachable-time 30s stale-check-interval 1m
? initial-probe-delay 5s answer-delay 1s proxy-answer-delay 800msec
lookups 195 hits 190 failed 0 allocations 3 destroys 1
hash-grows 1 forced-gc-runs 0 periodic-gc-runs 910
rcv-unicast-probes 0 rcv-multicast-probes 0
Xarp_cache<eth0> reachable-time 35s 967msec retransmit-time 1s
X refcnt 3 pending-queue-limit 3 proxy-delayed-queue-limit 64
X num-userspace-probes 0 num-unicast-probes 3 num-multicast-probes 3
X min-age 1s base-reachable-time 30s stale-check-interval 1m
X initial-probe-delay 5s answer-delay 1s proxy-answer-delay 800msec
Everything marked with X is clearly device specific so it will move.
Everything marked with '?' is the default parameter set, we can either
leave it or move it as well and put it under into a 'default' ifindex.
I don't care about the latter, either is fine with me.
^ permalink raw reply
* Re: [RFC] textsearch infrastructure et al v2
From: jamal @ 2005-05-28 11:59 UTC (permalink / raw)
To: Thomas Graf; +Cc: netdev
In-Reply-To: <20050527224725.GG15391@postel.suug.ch>
On Sat, 2005-28-05 at 00:47 +0200, Thomas Graf wrote:
> Dave, I'm going through another RFC round to hopefully get
> some comments on the notes below.
>
> I'm not yet satistifed with the core infrastructure wrt to
> non-linear data, especially for complex cases such as non
> linear skbs. The current way can be easly described as:
>
> search_occurrance()
> search-algorithm()
> while get-next-segment()
> process-segment()
>
I dont have opinions on this since you and Pablo seem to agree on it.
What I remember is that libssearch (or whatever that thing Harald was
looking at) did it differently (callback invoked and it return a code
which said to continue or not).
Also the design should (I think you do already, just double checking) -
should be wary of optimizing for a specific algorithmn; i see you have
KMP but not Boyer-Moore for example and i am not sure what the
repurcassions of above approach are etc etc.
> So basically we save the state of the segment fetching
> instead of saving the state of the search algorithm which
> would be way too complex for things like regular expression
> string matching.
>
Can you explain this a little more. Didnt quiet understand.
If you are going across skbs, dont you need to save state?
> In the case of non linear skbs this would lead to:
>
I think the best approach would be to first linearize then search.
On the egress side this would mean annoying things like no TSO or what
was posted yesterday USO etc. Same thing with ingress, but i suspect
other than the netiron NIC we probably wont be seeing much of non-linear
skbs on the ingress.
On ingress as well you are also better off to assemble fragments first
on that side before doing text searches.
Perhaps implementing an action like the one used by openbsd to
"normalize" packets before a string match.
i.e
classifier (pkt header) --> normalize --> classifier(string match)-> ?
Infact one could argue that if you are to scan a virus you may need
to assemble more than one skb on ingress (essentially a message).
The only other comment i have is on the patch you called naive regexp;
I think you should probably call it something else instead of regexp
since you invented it.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH 4/5] [NET] Add skb_find_text() to search for a text pattern in skbs
From: Thomas Graf @ 2005-05-28 11:32 UTC (permalink / raw)
To: Pablo Neira; +Cc: netdev, Jamal Hadi Salim
In-Reply-To: <4297E172.5020907@eurodev.net>
* Pablo Neira <4297E172.5020907@eurodev.net> 2005-05-28 05:11
> Still miss something here. You aren't looking for matches in skbs
> inserted in skb_shinfo(skb)->frag_list. Have a look at rusty's skb_iter
> functions. Since he cooked those for this purpose (string matching), why
> don't we use them instead of yours ?
Absolutely, I'm planning to use rusty's skb_iter instead. I postponed
this to when the core infrastructure is stable but thanks a lot for
this comment.
^ permalink raw reply
* netdev-2.6, wireless queues updated
From: Jeff Garzik @ 2005-05-28 3:45 UTC (permalink / raw)
To: Netdev; +Cc: Linux Kernel
The net driver change queue has been updated, most notably with some new
wireless drivers and wireless stack updates.
Intel contributed drivers for their Centrino hardware, "ipw2100" and
"ipw2200". SuSE has begun contributing work that advances the ieee80211
stack work, taking it much closer to the goal of having ieee802.11
support fully integrated into the network stack as "real" protocol layer.
Git repository containing a great many branches:
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
The branch of note for wireless developers is currently 'we18-ieee80211'.
Git instructions, for those needing an introduction:
http://lkml.org/lkml/2005/5/26/11
And finally a patch containing _only_ the changes on the we18-ieee80211
branch,
http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.12-rc5-git2-ieee80211-1.patch.bz2
Notably, this patch does not include HostAP, which is stored in a child
branch 'we18-ieee80211-wifi'.
^ permalink raw reply
* Re: [2/5] ieee80211: ieee80211_device alignment fix and cleanup
From: Jeff Garzik @ 2005-05-28 3:37 UTC (permalink / raw)
To: Jiri Benc; +Cc: NetDev, LKML, pavel
In-Reply-To: <20050524151117.5e059d1d@griffin.suse.cz>
Comments on the remaining patches in this series:
1) I am not convinced that the subclassing of net_device should be done
in this manner. Read drivers/net/wan/hdlc_generic.c and .../pc300_drv.c
for examples of how hdlc_device is handled.
Comments and thoughts welcome.
2) Please put all the new, protocol-layer functions
ieee80211_type_trans(), ieee80211_change_mtu(), ieee80211_header(), etc.
in their own file.
3) Temporary or not, the following construct is simply not necessary.
Modify the definition rather than repeating this two-call piece of code
in multiple areas:
ieee80211_priv(netdev_priv(dev));
4) A low-level wireless hardware driver should look like other net
drivers, and use the existing driver API. The low level driver should
implement its own dev->hard_start_xmit().
ieee = netdev_priv(dev);
- dev->hard_start_xmit = ieee80211_xmit;
-
ieee->dev = dev;
+ ieee->priv = ieee80211_priv(ieee);
+
+ dev->hard_start_xmit = ieee80211_xmit;
Certainly, the driver will make many calls to generic ieee80211_xxx
functions to get things done.
I understand this was not your change; you simply moved the
dev->hard_start_xmit() assignment down. I just wanted to take this
opportunity to make a point.
5) The wireless code in -mm all sourced directly from my netdev-2.6.git
tree. I strongly encourage everyone who wants to work on wireless to
download git (read http://lkml.org/lkml/2005/5/26/11) and check out
branches 'we18' (wireless ex 18), 'we18-ieee80211' (we18 + ieee80211),
and 'we18-ieee80211-wifi' (we18 + ieee80211 + hostAP) of
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
^ permalink raw reply
* Re: [0/5] Improvements to the ieee80211 layer
From: Jeff Garzik @ 2005-05-28 3:18 UTC (permalink / raw)
To: Jiri Benc; +Cc: NetDev, LKML, pavel
In-Reply-To: <20050524150711.01632672@griffin.suse.cz>
Jiri Benc wrote:
> The ieee80211 layer, now present in -mm, lacks many important features
> (actually it's just a part of the ipw2100/ipw2200 driver; these cards do
> a lot of the processing in the hardware/firmware and thus the layer
> currently can not be used for simpler devices).
Agreed.
> This is the first series of patches that try to convert it to a generic
> IEEE 802.11 layer, usable for most of today's wireless cards.
Great!
> The long term plan is:
> - to implement a complete 802.11 stack in the kernel, making it easy to
> write drivers for simple (cheap) devices
> - to implement all of Ad-Hoc, AP and monitor modes in the layer, so it
> will be easy to support them in the drivers
> - to integrate Wireless Extensions to unify the kernel-userspace
> interface of all the drivers
>
> This means that drivers for "stupid" (simple, cheap) cards should be
> very short and easy to write, whereas drivers for "clever" cards will be
> longer (but still shorter than they are now).
>
> We have a couple of cards for testing, and we gradually modify the
> drivers for ipw2100 and ipw2200 with the development of the layer. When
> the layer is mature enough for the "stupid" cards, we will rewrite the
> driver for Atheros-based cards to use this layer. We plan to send all
> the patches for these drivers to the netdev list. Of course, we are in
> close contact with Pavel Machek, who is pushing the ipw2100 driver
> upstream.
I'm interesting in writing a RealTek driver using ieee80211. As the
ieee80211 layer matures, I'll start publishing that code.
Jeff
^ permalink raw reply
* Re: [3/5] netdev: HH_DATA_OFF bugfix
From: Jeff Garzik @ 2005-05-28 3:15 UTC (permalink / raw)
To: Jiri Benc, David S. Miller; +Cc: NetDev, LKML, pavel
In-Reply-To: <20050524151204.554f73cb@griffin.suse.cz>
Jiri Benc wrote:
> When the hardware header size is a multiple of HH_DATA_MOD, HH_DATA_OFF()
> incorrectly returns HH_DATA_MOD (instead of 0).
>
> Signed-off-by: Jiri Benc <jbenc@suse.cz>
>
> --- linux/include/linux/netdevice.h
> +++ work/include/linux/netdevice.h
> @@ -204,7 +209,7 @@
> /* cached hardware header; allow for machine alignment needs. */
> #define HH_DATA_MOD 16
> #define HH_DATA_OFF(__len) \
> - (HH_DATA_MOD - ((__len) & (HH_DATA_MOD - 1)))
> + (HH_DATA_MOD - (((__len - 1) & (HH_DATA_MOD - 1)) + 1))
> #define HH_DATA_ALIGN(__len) \
> (((__len)+(HH_DATA_MOD-1))&~(HH_DATA_MOD - 1))
> unsigned long hh_data[HH_DATA_ALIGN(LL_MAX_HEADER) / sizeof(long)];
You'll want to run this one by DaveM. He would be the appropriate one
to merge this, since it affects all ethernet devices (net/ethernet/eth.c
uses HH_DATA_OFF macro).
I'm going over the rest of the ieee80211/ipw patches...
Jeff
^ permalink raw reply
* Re: [PATCH 4/5] [NET] Add skb_find_text() to search for a text pattern in skbs
From: Pablo Neira @ 2005-05-28 3:11 UTC (permalink / raw)
To: Thomas Graf; +Cc: netdev, Jamal Hadi Salim
In-Reply-To: <20050527224858.GK15391@postel.suug.ch>
Thomas Graf wrote:
> +static int get_skb_text(int offset, unsigned char **text,
> + struct ts_config *conf, struct ts_state *state)
> +{
> + /* args[0]: lower limit
> + * args[1]: upper limit
> + * args[2]: skb
> + * args[3]: fragment index
> + * args[4]: current fragment data buffer
> + * args[5]: octets consumed up to previous fragment */
> + int from = state->args[0], to = state->args[1];
> + struct sk_buff *skb = (struct sk_buff *) state->args[2];
> + int limit = min_t(int, skb_headlen(skb), to);
> + int real_offset = offset + from;
> + skb_frag_t *f;
> +
> + if (!skb_is_nonlinear(skb)) {
> + if (real_offset < limit) {
> +linear:
> + *text = skb->data + real_offset;
> + return limit - real_offset;
> + }
> +
> + return 0;
> + }
> +
> + if (real_offset < limit)
> + goto linear;
> +
> +next_fragment:
> + f = &skb_shinfo(skb)->frags[state->args[3]];
> + limit = min_t(int, f->size + state->args[5], to);
> +
> + if (!state->args[4])
> + state->args[4] = (long) kmap_skb_frag(f);
> +
> + if (real_offset < limit) {
> + *text = (unsigned char *) state->args[4] + f->page_offset +
> + (real_offset - (int) state->args[5]);
> + return limit - real_offset;
> + }
> +
> + kunmap_skb_frag((void *) state->args[4]);
> + state->args[3]++;
> + state->args[4] = (long) NULL;
> + state->args[5] += f->size;
> +
> + if (state->args[3] >= skb_shinfo(skb)->nr_frags)
> + return 0;
> +
> + goto next_fragment;
> +}
Still miss something here. You aren't looking for matches in skbs
inserted in skb_shinfo(skb)->frag_list. Have a look at rusty's skb_iter
functions. Since he cooked those for this purpose (string matching), why
don't we use them instead of yours ?
--
Pablo
^ permalink raw reply
* Re: [1/5] ieee80211: cleanup
From: Jeff Garzik @ 2005-05-28 2:43 UTC (permalink / raw)
To: Jiri Benc; +Cc: NetDev, LKML, pavel
In-Reply-To: <20050524151018.3304fbeb@griffin.suse.cz>
applied
^ permalink raw reply
* Re: [PATCH] Tulip interrupt uses non IRQ safe spinlock
From: Jeff Garzik @ 2005-05-28 2:24 UTC (permalink / raw)
To: Mark Broadbent; +Cc: linux-kernel, netdev
In-Reply-To: <E1DRFqC-00028H-Qi@tigger>
Mark Broadbent wrote:
> The interrupt handling code in the tulip network driver appears to use a non
> IRQ safe spinlock in an interrupt context. The following patch should correct
> this.
>
> Signed-off-by: Mark Broadbent <markb@wetlettuce.com>
>
> Index: linux-2.6.11/drivers/net/tulip/interrupt.c
> ===================================================================
> --- linux-2.6.11.orig/drivers/net/tulip/interrupt.c 2005-03-07 18:11:23.000000000 +0000
> +++ linux-2.6.11/drivers/net/tulip/interrupt.c 2005-04-28 16:16:23.000000000 +0100
> @@ -567,8 +567,9 @@
>
> if (csr5 & (TxNoBuf | TxDied | TxIntr | TimerInt)) {
> unsigned int dirty_tx;
> + unsigned long flags;
>
> - spin_lock(&tp->lock);
> + spin_lock_irqsave(&tp->lock, flags);
>
> for (dirty_tx = tp->dirty_tx; tp->cur_tx - dirty_tx > 0;
> dirty_tx++) {
> @@ -640,7 +641,7 @@
> dev->name, csr5, ioread32(ioaddr + CSR6), tp->csr6);
> tulip_restart_rxtx(tp);
> }
> - spin_unlock(&tp->lock);
> + spin_unlock_irqrestore(&tp->lock, flags);
It's already inside the interrupt handler, so this patch is not needed.
Jeff
^ permalink raw reply
* netdev-2.6.git updated, ipw wireless drivers merged
From: Jeff Garzik @ 2005-05-28 2:13 UTC (permalink / raw)
To: Netdev; +Cc: James Ketrenos, Andrew Morton, Linux Kernel
The ipw 2100/2200 wireless drivers were merged into the netdev-2.6.git
repository, under the 'we18-ieee80211' branch.
There is also the we18-ieee80211-wifi branch, which lumps HostAP on top
of that.
(if you need info on git, read http://lkml.org/lkml/2005/5/26/11)
Also, Andrew: I fixed that compilation error you mentioned a week or so
ago.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox