Re: Broadcom 43xx first results

On Tue, Dec 06, 2005 at 02:47:28PM -0800, Jean Tourrilhes wrote: > DeviceScape stack : > drivers using it : ? > potential drivers : hostap, ipw2100, ipw2200, r8180, adm8211 It's mainly used with Atheros chipsets nowadays, but it has been used with couple of other chipsets, too, includ

Re: Broadcom 43xx first results

On Tue, Dec 06, 2005 at 02:05:07PM -0500, Jeff Garzik wrote: > Harald Welte wrote: > >I also think that there is a lack of knowledge on the architecture of > >802.11 low-level protocols and drivers among many people (including > >myself) in the network community. Only this way I can explain why th

Re: Resend [PATCH netdev-2.6 2/8] e1000: Performance Enhancements

On Tue, Dec 06, 2005 at 06:08:35PM -0500, jamal wrote: > a 2Ghz dual Xeon hyperthreading (shows up as 4 processors); Would it be a burden to make for one run with e1000-2.6.15 and hyperthreading turned off? I'm leery of hyperthreading since really messes with cache in a totally different way. I'm

Re: [PATCH] tcp: make reno default for mortals

From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Tue, 6 Dec 2005 20:18:05 -0800 > For 2.6.16, since BIC will be moving to a new version and there is a > potential for instability; please consider the following that makes Reno > the default unless advanced congestion is selected. > > Signed-off-b

Re: [PATCH] tcp: make reno default for mortals

On 12/7/05, Stephen Hemminger <[EMAIL PROTECTED]> wrote: > For 2.6.16, since BIC will be moving to a new version and there is a > potential for instability; please consider the following that makes Reno > the default unless advanced congestion is selected. > > Signed-off-by: Stephen Hemminger <[EMA

[PATCH] tcp: make reno default for mortals

For 2.6.16, since BIC will be moving to a new version and there is a potential for instability; please consider the following that makes Reno the default unless advanced congestion is selected. Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> --- bic-2.6.orig/net/ipv4/Kconfig +++ bic-2.6/net/

Re: [PATCH] X25: Add ITU-T facilite

From: Andrew Hendry <[EMAIL PROTECTED]> Date: Wed, 07 Dec 2005 14:23:20 +1100 > Any update on the status of this patch? I don't have the capability to review this patch, and I've been burnt in the past blindly merging in x25 and ax.25 changes :) - To unsubscribe from this list: send the line "uns

Re: [PATCH] X25: Add ITU-T facilite

Any update on the status of this patch? Thanks, Andrew. On 10/24/05, Andrew Hendry <[EMAIL PROTECTED]> wrote: Structure alignment corrected. Adds options for ITU DTE facilities to X.25, called address extension and calling address extension Signed-off-by: Andrew

Re: [PATCH 3/3] TCP_Vegas: Remove extra call to tcp_vegas_rtt_calc

On Tue, 2005-12-06 at 17:04 -0800, David S. Miller wrote: > From: Stephen Hemminger <[EMAIL PROTECTED]> > Date: Tue, 6 Dec 2005 10:52:09 -0800 > > > Fixing Vegas was on my TODO list, thanks for attacking it. > > It never really worked well. > > Indeed, thanks a lot Tom. > > I've integrated the t

Re: [PATCH] skge: get rid of warning on race

From: Jeff Garzik <[EMAIL PROTECTED]> Date: Tue, 06 Dec 2005 19:36:29 -0500 > Stephen Hemminger wrote: > > Get rid of warning in case of race with ring full and lockless > > tx on the skge driver. It is possible to be in the transmit > > routine with no available slots and already stopped. > > >

Re: [PATCH] tg3: remove warning on race

From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Tue, 6 Dec 2005 14:59:10 -0800 > This is simpler way to just cut out the message if the race > occurs. > > Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> Fair enough, but I'm going to move the "this is a hard error" comment to the correct s

Re: [PATCH 3/3] TCP_Vegas: Remove extra call to tcp_vegas_rtt_calc

From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Tue, 6 Dec 2005 10:52:09 -0800 > Fixing Vegas was on my TODO list, thanks for attacking it. > It never really worked well. Indeed, thanks a lot Tom. I've integrated the three fixes. - To unsubscribe from this list: send the line "unsubscribe netd

Re: Issue 0 WAS (Re: Oustanding issues WAS(IRe: Consensus? WAS(RFC 2863)

On Tue, 2005-06-12 at 23:34 +0100, Stefan Rompf wrote: > Am Dienstag 06 Dezember 2005 22:25 schrieb Krzysztof Halasa: > > > > Is Stefan's patch going to restore the functionality that you need? > > > > I hope so. If done correctly, it would not only provide the > > functionality my drivers were u

[GIT PATCH] SCTP updates

Dave, Please pull the following SCTP updates from master.kernel.org:/pub/scm/linux/kernel/git/sridhar/lksctp-2.6.git Thanks Sridhar include/net/sctp/structs.h | 76 +++-- include/net/sctp/user.h| 30 ++ net/sctp/associola.c | 81 +++-- net/sctp/input.c | 36 ++ ne

Re: [PATCH] skge: get rid of warning on race

Stephen Hemminger wrote: Get rid of warning in case of race with ring full and lockless tx on the skge driver. It is possible to be in the transmit routine with no available slots and already stopped. Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> Is this for 'upstream' (2.6.16) or 'upst

RE: Resend [PATCH netdev-2.6 2/8] e1000: Performance Enhancements

On Wed, 2005-07-12 at 01:08 +0100, Robert Olsson wrote: > jamal writes: > > > Results: > > > > > > kernel 2.6.11.7: 446Kpps > > kernel 2.6.14: 452kpps > > kernel 2.6.14 with e1000-6.2.15: 470Kpps > > Kernel 2.6.14 with e1000-6.2.15 but rx copybreak commented out: 460Kpps > > cop

RE: Resend [PATCH netdev-2.6 2/8] e1000: Performance Enhancements

jamal writes: > Results: > > > kernel 2.6.11.7: 446Kpps > kernel 2.6.14: 452kpps > kernel 2.6.14 with e1000-6.2.15: 470Kpps > Kernel 2.6.14 with e1000-6.2.15 but rx copybreak commented out: 460Kpps copybreaks help you.. > And lastly to just play with different prefetch on/of

Re: Broadcom 43xx first results

David S. Miller wrote: I'm at the point where I frankly don't care which softmac implementation we go with, but rather I'm more concerned that we pick _ONE_ and just stick with it, and then adding the necessary interfaces and infrastructure as different wireless devices require. Yes, you hear me

Re: Broadcom 43xx first results

From: Ben Greear <[EMAIL PROTECTED]> Date: Tue, 06 Dec 2005 08:43:39 -0800 > Merge now even if it breaks the current tree? DCCP is a good counter example, zero --> some functionality is always preferred. Our DCCP stack is far from being finished, but it is in there and getting polished and maint

Re: Broadcom 43xx first results

From: Harald Welte <[EMAIL PROTECTED]> Date: Tue, 6 Dec 2005 20:40:47 +0530 > I'm also in favor of merging the devicescape code, but I don't see it > happening without somebody taking care to provide all the required > levels of interfaces (I see at least three levels of API's that a wireless > dr

RE: Resend [PATCH netdev-2.6 2/8] e1000: Performance Enhancements

Ok, here are some results - unfortunately i dont have further access to the hardware until tommorow: Hardware: - a 2Ghz dual Xeon hyperthreading (shows up as 4 processors); 512 KB L2 Cache and 1Gig Ram. Two ethernet e1000 82546EB tests: -- Forwarding tests with a single flow into

[PATCH] skge: get rid of warning on race

Get rid of warning in case of race with ring full and lockless tx on the skge driver. It is possible to be in the transmit routine with no available slots and already stopped. Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> --- orig/drivers/net/skge.c +++ new/drivers/net/skge.c @@ -2280,11 +

[PATCH] tg3: remove warning on race

This is simpler way to just cut out the message if the race occurs. Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> --- orig/drivers/net/tg3.c +++ new/drivers/net/tg3.c @@ -3567,10 +3567,12 @@ static int tg3_start_xmit(struct sk_buff /* This is a hard error, log it. */ if (

Re: Broadcom 43xx first results

Jiri Benc wrote : > On Mon, 05 Dec 2005 13:46:43 -0500, Jeff Garzik wrote: > > Use the stack that's already in the kernel. > > > > Encouraging otherwise hinders continued wireless progress under Linux. > > There is nothing like a "802.11 stack" currently in the kernel, > regardless what James Ket

Re: Issue 0 WAS (Re: Oustanding issues WAS(IRe: Consensus? WAS(RFC 2863)

Am Dienstag 06 Dezember 2005 22:25 schrieb Krzysztof Halasa: > > Is Stefan's patch going to restore the functionality that you need? > > I hope so. If done correctly, it would not only provide the > functionality my drivers were using before the breakage, it would > enable me to cut the dirty link

Re: [PATCH] natsemi: NAPI support

Mark Brown <[EMAIL PROTECTED]> : [...] > Prior to waiting dev_close() clears __LINK_STATE_START which will cause > netif_rx_schedule_prep() to return false. > As far as I can see that should prevent the interrupt handler scheduling > any further poll() calls? netif_rx_schedule_prep return netif_ru

Re: Issue 0 WAS (Re: Oustanding issues WAS(IRe: Consensus? WAS(RFC 2863)

jamal <[EMAIL PROTECTED]> writes: > I ask you a very specific question, you start playing silly games with > words. This is why it has been hard to make progress with you. > I didnt ask what you are doing without the patch or whether you will use > the patch at all, rather whether it will restore

Re: [PATCH] natsemi: NAPI support

On Tue, Dec 06, 2005 at 01:19:34AM +0100, Francois Romieu wrote: > Mark Brown <[EMAIL PROTECTED]> : > > I had been under the impression that the stack was supposed to make sure > > that no poll() is running before the driver close() gets called? > Not exactly. dev_close() waits a bit but it can n

Re: Issue 0 WAS (Re: Oustanding issues WAS(IRe: Consensus? WAS(RFC 2863)

On Tue, 2005-06-12 at 20:45 +0100, Krzysztof Halasa wrote: > jamal <[EMAIL PROTECTED]> writes: > > > Lets start with the basics: With this patch, can you still do what you > > used to do before the change that broke things for you? > > I have put workarounds in place and my drivers are currently

[RFC] TCP MTU probing

(aka. Packetization Layer Path MTU Discovery) The patch can be found at: This is based on work by the IETF pmtud wg to make PMTUD work correctly in the absence of correct ICMP delivery. The currently published internet-draft is at:

Re: Issue 0 WAS (Re: Oustanding issues WAS(IRe: Consensus? WAS(RFC 2863)

jamal <[EMAIL PROTECTED]> writes: > Lets start with the basics: With this patch, can you still do what you > used to do before the change that broke things for you? I have put workarounds in place and my drivers are currently working, without any additional patch. So unless something is broken a

Re: Broadcom 43xx first results

Pavel Machek wrote: No, it does not work like that. You don't get nice, reviewable, mergeable patches by developing code independently for 3 years or so then attempting merge. If devicescape code is better than mainline, merge it _now_. If it is not, drop it and start from mainline code. Agree

Re: Broadcom 43xx first results

Harald Welte wrote: I also think that there is a lack of knowledge on the architecture of 802.11 low-level protocols and drivers among many people (including myself) in the network community. Only this way I can explain why there are always people who claim that the kernel already has a 802.11 '

Re: [PATCH 1/3] TCP_Vegas: stop resetting rtt every ack

On Mon, 05 Dec 2005 21:28:26 -0800 (PST) "David S. Miller" <[EMAIL PROTECTED]> wrote: > From: Tom Young <[EMAIL PROTECTED]> > Date: Tue, 06 Dec 2005 15:37:22 +1100 > > > Move the resetting of rtt measurements to inside the once per RTT block > > of > > code. > > > > Signed-off-by: Thomas Young <

Re: [PATCH 3/3] TCP_Vegas: Remove extra call to tcp_vegas_rtt_calc

On Tue, 06 Dec 2005 17:12:27 +1100 Tom Young <[EMAIL PROTECTED]> wrote: > On Mon, 2005-12-05 at 21:43 -0800, David S. Miller wrote: > > From: Tom Young <[EMAIL PROTECTED]> > > Date: Tue, 06 Dec 2005 15:40:57 +1100 > > > > > Remove unneeded call to tcp_vegas_rtt_calc. The more accurate > > > micro

Re: [PATCH 3/3] TCP_Vegas: Remove extra call to tcp_vegas_rtt_calc

On Tue, 06 Dec 2005 15:40:57 +1100 Tom Young <[EMAIL PROTECTED]> wrote: > Remove unneeded call to tcp_vegas_rtt_calc. The more accurate > microsecond value has already been registered prior to calling > tcp_vegas_cong_avoid. > > Signed-off-by: Thomas Young <[EMAIL PROTECTED]> > --- > > diff --gi

Re: Broadcom 43xx first results

Pavel Machek wrote: Hi! That's because you still don't get how we do development. The last thing we want is full-scale rewrites. Submit patches to fix things based on whatever you want but do it incremental. We have got almost finished and working stack. Everything we need to do is: 1. ide

RE: Resend [PATCH netdev-2.6 2/8] e1000: Performance Enhancements

On Tue, 2005-06-12 at 16:55 +0100, Robert Olsson wrote: > Ronciak, John writes: > > > So we still need to see a case where performance is hurt by the > > prefetching. We have some data coming from another group here at Intel > > next week which we'll share once we have it which also shows the

Re: Issue 0 WAS (Re: Oustanding issues WAS(IRe: Consensus? WAS(RFC 2863)

jamal <[EMAIL PROTECTED]> writes: > Ok, please explain again, slowly if you can. > What is it that wont work for you that is in Stefans patch or missing > from his patch? Please ask for a specific thing. > [I am going to leave the rest of your message out so we avoid > conflicts]. I can't see a

Re: Issue 0 WAS (Re: Oustanding issues WAS(IRe: Consensus? WAS(RFC 2863)

On Tue, 2005-06-12 at 17:10 +0100, Krzysztof Halasa wrote: > jamal <[EMAIL PROTECTED]> writes: > > > Ok, please explain again, slowly if you can. > > What is it that wont work for you that is in Stefans patch or missing > > from his patch? > > Please ask for a specific thing. > Lets start with

RE: Resend [PATCH netdev-2.6 2/8] e1000: Performance Enhancements

Ronciak, John writes: > So we still need to see a case where performance is hurt by the > prefetching. We have some data coming from another group here at Intel > next week which we'll share once we have it which also shows the > performance gains with prefetching. Hello! Well here is anot

Re: Issue 0 WAS (Re: Oustanding issues WAS(IRe: Consensus? WAS(RFC 2863)

On Tue, 2005-06-12 at 16:19 +0100, Krzysztof Halasa wrote: > jamal <[EMAIL PROTECTED]> writes: > I think I made myself clear. If you don't understand something, just ask > for explanation. > Ok, please explain again, slowly if you can. What is it that wont work for you that is in Stefans patch o

Re: Issue 0 WAS (Re: Oustanding issues WAS(IRe: Consensus? WAS(RFC 2863)

jamal <[EMAIL PROTECTED]> writes: > I dont remember asking you not to CC me. What i remember asking you is > to _stop_ talking about your useless patch. I will, of course, not mention my patch to you anymore but could you please leave decisions related to me and third parties just to me and those

Re: Broadcom 43xx first results

Hi! > > That's because you still don't get how we do development. The last thing > > we want is full-scale rewrites. Submit patches to fix things based on > > whatever you want but do it incremental. > > We have got almost finished and working stack. Everything we need to do > is: > 1. identify

Re: Broadcom 43xx first results

Hi! > > Please stop beeing a freaking jackass. There are various projects using > > the current code. It's not perfect but people are working on it. > > Yes, and everyone implements his own softmac (this is the third one I > know about). I tried to put all of these efforts together (google > th

Re: Issue 0 WAS (Re: Oustanding issues WAS(IRe: Consensus? WAS(RFC 2863)

On Tue, 2005-06-12 at 15:11 +0100, Krzysztof Halasa wrote: > Jamal's address ommited as requested. > I dont remember asking you not to CC me. What i remember asking you is to _stop_ talking about your useless patch. But the way this is going i am probably going to ask you to _not CC_ me. The que

Re: Broadcom 43xx first results

On Mon, Dec 05, 2005 at 02:53:29PM -0500, Dave Jones wrote: > > ieee80211 is used by Intel. Some bits used by HostAP, which also > > duplicates a lot of ieee80211 code. And bcm43xx. And another couple > > drivers found in -mm or out-of-tree. > > Orinoco also uses it now no ? Dave, the Ori

Re: Issue 0 WAS (Re: Oustanding issues WAS(IRe: Consensus? WAS(RFC 2863)

Jamal's address ommited as requested. Stefan Rompf <[EMAIL PROTECTED]> writes: > I'm more unhappy about the fact that a driver can (and could) do a > netif_carrier_off()/-on() sequence too fast for the workqueue to follow. Precisely. So there will always be the "glitches". And we can't "fix" it

[PATCH] Socket filter instruction limit validation

This patch checks to make sure that the number of instructions doesn't surpass BPF_MAXINSNS in sk_chk_filter(). Signed-off-by: Kris Katterjohn <[EMAIL PROTECTED]> --- This is a diff from 2.6.15-rc5. And I am not subscribed, so please CC me on any replies. The previous check in sk_chk_filter() d

Re: Broadcom 43xx first results

On Tue, Dec 06, 2005 at 04:26:50AM -0500, Kyle Moffett wrote: > On Dec 05, 2005, at 15:42, Jiri Benc wrote: > >On Mon, 5 Dec 2005 21:23:42 +0100, Michael Buesch wrote: > >>This is __not__ "yet another stack". It is an _extension_. It is > >>all about management frames, which the in-kernel code d

Re: [PATCH 12/14] spidernet: check if firmware was loaded correctly

On Dinsdag 06 Dezember 2005 01:59, Paul Mackerras wrote: > Arnd Bergmann writes: > > > Uploading the device firmware may fail if wrong input data > > was provided by the user. This checks for the condition. > > > > From: [EMAIL PROTECTED] > > Cc: netdev@vger.kernel.org > > This one should be sen

Re: Broadcom 43xx first results

On Dec 05, 2005, at 15:42, Jiri Benc wrote: On Mon, 5 Dec 2005 21:23:42 +0100, Michael Buesch wrote: This is __not__ "yet another stack". It is an _extension_. It is all about management frames, which the in-kernel code does not manage. But this code should be part of the stack, as nearly