* Re: [PATCH 1/3] Eleminate HZ from AX.25 kernel interfaces
From: David S. Miller @ 2006-05-04 6:27 UTC (permalink / raw)
To: ralf; +Cc: netdev, linux-hams
In-Reply-To: <20060429141244.GA2407@linux-mips.org>
From: Ralf Baechle DL5RB <ralf@linux-mips.org>
Date: Sat, 29 Apr 2006 15:12:44 +0100
> Convert all AX.25 sysctl time values from jiffies to ms as units.
>
> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Applied.
^ permalink raw reply
* Re: [ROSE] Fix routing table locking in rose_remove_neigh.
From: David S. Miller @ 2006-05-04 6:26 UTC (permalink / raw)
To: ralf; +Cc: netdev, pidoux, linux-hams
In-Reply-To: <20060429133141.GA31820@linux-mips.org>
From: Ralf Baechle <ralf@linux-mips.org>
Date: Sat, 29 Apr 2006 14:31:41 +0100
> The locking rule for rose_remove_neigh() are that the called needs to
> hold rose_neigh_list_lock, so we better don't take it yet again in
> rose_neigh_list_lock.
>
> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Applied, thanks.
^ permalink raw reply
* Re: [AX.25] Move AX.25 symbol exports
From: David S. Miller @ 2006-05-04 6:25 UTC (permalink / raw)
To: ralf; +Cc: netdev, linux-hams
In-Reply-To: <20060429134023.GA32158@linux-mips.org>
From: Ralf Baechle <ralf@linux-mips.org>
Date: Sat, 29 Apr 2006 14:40:23 +0100
> Move AX.25 symbol exports to next to their definitions where they're
> supposed to be these days.
>
> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Applied.
^ permalink raw reply
* Re: [HAMRADIO] Remove remaining SET_MODULE_OWNER calls from hamradio drivers.
From: David S. Miller @ 2006-05-04 6:24 UTC (permalink / raw)
To: ralf; +Cc: jeff, netdev, linux-hams
In-Reply-To: <20060429143413.GA4630@linux-mips.org>
From: Ralf Baechle DL5RB <ralf@linux-mips.org>
Date: Sat, 29 Apr 2006 15:34:13 +0100
> Signed-off-by: Ralf Baechle DL5RB <ralf@linux-mips.org>
Applied.
^ permalink raw reply
* Re: [AX25, ROSE] Remove useless SET_MODULE_OWNER calls.
From: David S. Miller @ 2006-05-04 6:23 UTC (permalink / raw)
To: ralf; +Cc: netdev, linux-hams
In-Reply-To: <20060429142943.GA4402@linux-mips.org>
From: Ralf Baechle DL5RB <ralf@linux-mips.org>
Date: Sat, 29 Apr 2006 15:29:43 +0100
> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Applied, thanks.
^ permalink raw reply
* Re: [ROSE] Remove useless prototype for rose_remove_neigh().
From: David S. Miller @ 2006-05-04 6:22 UTC (permalink / raw)
To: ralf; +Cc: netdev
In-Reply-To: <20060429132553.GA31622@linux-mips.org>
From: Ralf Baechle <ralf@linux-mips.org>
Date: Sat, 29 Apr 2006 14:25:53 +0100
> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Applied, thanks.
^ permalink raw reply
* Re: [AX.25] Spelling fix
From: David S. Miller @ 2006-05-04 6:22 UTC (permalink / raw)
To: ralf; +Cc: netdev, linux-hams
In-Reply-To: <20060429142427.GA3684@linux-mips.org>
From: Ralf Baechle DL5RB <ralf@linux-mips.org>
Date: Sat, 29 Apr 2006 15:24:27 +0100
> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Applied.
^ permalink raw reply
* Re: [PATCH 1/3] Rough VJ Channel Implementation - vj_core.patch
From: Kelly Daly @ 2006-05-04 2:59 UTC (permalink / raw)
Cc: David S. Miller, rusty, netdev
In-Reply-To: <20060426.232501.119306252.davem@davemloft.net>
On Thursday 27 April 2006 16:25, you wrote:
> So the idea in your scheme is to give the buffer pools to the NIC
> in a per-channel way via a simple descriptor table? And the u32's
> are arbitrary keys that index into this descriptor table, right?
>
yeah - it _was_... Although since having a play with coding it into your
implementation we've come up with the following:
Using the descriptor table adds excess complexity for kernel buffers, and is
really only useful for userspace. So instead of using descriptor tables for
everything we've come up with a dynamic descriptor table scheme instead where
they are used only for userspace.
The move to skb-ising the buffers has made it more difficult to keep track of
buffer lifetimes. Previously we were leaving the buffers in the ring until
completely finished with them. The producer could reuse the buffer once the
consumer head had moved on. With the graft to skb we can no longer do this
unless the packets are processed serially (which is ok for socket channels,
but not realistic for the default).
We DID write an infrastructure to resolve this issue, although it is more
complex than the dynamic descriptor scheme for userspace. And we want to
keep this simple - right?
Cheers,
K
^ permalink raw reply
* Re: latest -stable breaks Squid
From: Ian McDonald @ 2006-05-04 1:59 UTC (permalink / raw)
To: Ben Greear
Cc: Herbert Xu, Dave Jones, netdev, stable, fedora-list, fedoralist
In-Reply-To: <4459574D.6000303@candelatech.com>
On 5/4/06, Ben Greear <greearb@candelatech.com> wrote:
> Herbert Xu wrote:
> > Dave Jones <davej@redhat.com> wrote:
> >
> >>So I pushed out an update for Fedora Core 5 users yesterday
> >>that moved the kernel from 2.6.16.9 to 2.6.16.13.
> >>I've since heard "My network performance is awful", and worse
> >>yet, some apps seem broken as in the report below.
> >>
> >>Anyone have any ideas ?
> >
> >
> > Try reverting the e1000 truesize patch. Although the fix is 100%
> > correct, it might have a negative impact on user-space apps with
> > particuarly small rcvbuf settings. Prior to the fix, due to the
> > incorrect accounting we are essentially enlarging rcvbuf by as much
> > as 10 times.
>
> At least one of the reports shows problems with non e1000 NICs, so it's
> probably not just the e1000 change.
>
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190620
>
> Ben
>
Wouldn't it be more likely commit 5d0b6f2bdaf7e016e750cd24164a241512d968a3
as this touches net/ipv4/tcp_output.c and is also in same general area?
--
Ian McDonald
Web: http://wand.net.nz/~iam4
Blog: http://imcdnzl.blogspot.com
WAND Network Research Group
Department of Computer Science
University of Waikato
New Zealand
^ permalink raw reply
* Fw: [Bugme-new] [Bug 6484] New: dropouts with user mode PPPoE
From: Andrew Morton @ 2006-05-04 1:56 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Tue, 2 May 2006 13:28:22 -0700
From: bugme-daemon@bugzilla.kernel.org
To: bugme-new@lists.osdl.org
Subject: [Bugme-new] [Bug 6484] New: dropouts with user mode PPPoE
http://bugzilla.kernel.org/show_bug.cgi?id=6484
Summary: dropouts with user mode PPPoE
Kernel Version: 2.6.16 and above
Status: NEW
Severity: normal
Owner: acme@conectiva.com.br
Submitter: lkml@jawad.org
Distribution: Debian
Hardware Environment: P4 Northwood, 2 GB, i875, e1000 CSA
Software Environment: pppd, rp-pppoe
Problem Description:
ADSL connection through PPPoE occasionally stalls for 30 to 50 seconds,
especially under load. During these dropouts, packets are received but none that
are supposed to be sent appear on ppp0. Ethernet interface continues to work,
telnet session to modem does not stall.
Exhibition of the bug is not affected by:
SMP or uniprocessor kernel, Hyper Threading disabled or enabled, pppd version
(tested with 2.4.2 and 2.4.4b1), rp-pppoe version (tested 3.5 & 3.8).
CPU load is probably not a factor either.
Dropouts seem to appear more frequently when the connection is under load (large
Bittorrent swarms are a good test). They can appear as soon as a few minutes
after start but it also took more than 5 hours once. Most of the time, they will
appear every half to one hour.
Problem does not occur with 2.6.15.7 or earlier. Second system with AMD64
SanDiego & NForce4 is not affected, will try to match configuration as closely
as possible and retest.
Kernel mode PPPoE using the rp-pppoe plugin does also not exhibit the bug.
2.6.17-rc3 .config:
http://jawad.org/.config
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply
* Re: latest -stable breaks Squid
From: Ben Greear @ 2006-05-04 1:22 UTC (permalink / raw)
To: Herbert Xu; +Cc: Dave Jones, netdev, stable, fedora-list, fedoralist
In-Reply-To: <E1FbSM8-0002lx-00@gondolin.me.apana.org.au>
Herbert Xu wrote:
> Dave Jones <davej@redhat.com> wrote:
>
>>So I pushed out an update for Fedora Core 5 users yesterday
>>that moved the kernel from 2.6.16.9 to 2.6.16.13.
>>I've since heard "My network performance is awful", and worse
>>yet, some apps seem broken as in the report below.
>>
>>Anyone have any ideas ?
>
>
> Try reverting the e1000 truesize patch. Although the fix is 100%
> correct, it might have a negative impact on user-space apps with
> particuarly small rcvbuf settings. Prior to the fix, due to the
> incorrect accounting we are essentially enlarging rcvbuf by as much
> as 10 times.
At least one of the reports shows problems with non e1000 NICs, so it's
probably not just the e1000 change.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190620
Ben
>
> Cheers,
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: latest -stable breaks Squid
From: Herbert Xu @ 2006-05-04 1:10 UTC (permalink / raw)
To: Dave Jones; +Cc: netdev, stable, fedora-list, fedoralist
In-Reply-To: <20060503211915.GD27368@redhat.com>
Dave Jones <davej@redhat.com> wrote:
>
> So I pushed out an update for Fedora Core 5 users yesterday
> that moved the kernel from 2.6.16.9 to 2.6.16.13.
> I've since heard "My network performance is awful", and worse
> yet, some apps seem broken as in the report below.
>
> Anyone have any ideas ?
Try reverting the e1000 truesize patch. Although the fix is 100%
correct, it might have a negative impact on user-space apps with
particuarly small rcvbuf settings. Prior to the fix, due to the
incorrect accounting we are essentially enlarging rcvbuf by as much
as 10 times.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: latest -stable breaks Squid
From: Dave Jones @ 2006-05-04 0:43 UTC (permalink / raw)
To: netdev; +Cc: stable, Andreas M. Kirchwitz, Vassilios Kotoulas
In-Reply-To: <20060503211915.GD27368@redhat.com>
On Wed, May 03, 2006 at 05:19:15PM -0400, Dave Jones wrote:
> So I pushed out an update for Fedora Core 5 users yesterday
> that moved the kernel from 2.6.16.9 to 2.6.16.13.
> I've since heard "My network performance is awful", and worse
> yet, some apps seem broken as in the report below.
Further problems found (not all network related, but there does
seem to be a pattern amongst some of them) can be seen at
http://tinyurl.com/o7uqj
Dave
--
http://www.codemonkey.org.uk
^ permalink raw reply
* Re: [PATCH 2/2] ipg: redundancy with mii.h
From: Francois Romieu @ 2006-05-03 23:35 UTC (permalink / raw)
To: Pekka J Enberg; +Cc: David Vrabel, linux-kernel, netdev, david
In-Reply-To: <Pine.LNX.4.58.0605030913210.6032@sbz-30.cs.Helsinki.FI>
Pekka J Enberg <penberg@cs.Helsinki.FI> :
[...]
> maintain the tree, I can send you my patches so you can recreate the full
> history. The first steps were produced by quilt on the original
> out-of-tree driver, though, so they're probably not helpful.
It will be welcome.
I have added a few little things (changelog below). Next step will
probably be some mii/ethtool stuff.
The branch 'netdev-ipg' is available at:
git://electric-eye.fr.zoreil.com/home/romieu/linux-2.6.git.
Serie of patches (ala 'git format-patch'):
http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.17-rc3/ip1000a/
All-in-one patch:
http://www.fr.zoreil.com/people/francois/misc/20060504-2.6.17-rc3-git-ip1000-test.patch
ChangeLog from yesterday version:
commit 8b0a8db32d1ac6e9bc23300a6a0533b4d7e251e3
Author: Francois Romieu <romieu@fr.zoreil.com>
Date: Thu May 4 00:29:59 2006 +0200
ipg: remove forward declarations
It makes no sense in a new driver.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
commit 65940e5e0ab88d92fbac0f96b5d46ddfbd5cfa93
Author: Francois Romieu <romieu@fr.zoreil.com>
Date: Thu May 4 00:04:57 2006 +0200
ipg: replace #define with enum
Added some underscores to improve readability.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
commit ab87a106690d6eaba4b7426fb074270e2e503e40
Author: Francois Romieu <romieu@fr.zoreil.com>
Date: Wed May 3 22:51:16 2006 +0200
ipg: removal of useless #defines
IPG_TX_NOTBUSY apart (one occurence in ipg.c), the #defines appear
nowhere in the sources.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
commit ef7bfd886bc436d14649e962edb6f5189cc4dcac
Author: Francois Romieu <romieu@fr.zoreil.com>
Date: Wed May 3 22:44:47 2006 +0200
ipg: redundancy with mii.h - take II
Replace a bunch of #define with their counterpart from mii.h
It is applied to the usual MII registers this time.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
--
Ueimor
^ permalink raw reply
* Re: netlink+ARP+CLIP == broken,
From: Stephen Hemminger @ 2006-05-03 21:43 UTC (permalink / raw)
To: Simon Kelley; +Cc: netdev, linux-kernel
In-Reply-To: <44592177.5080801@thekelleys.org.uk>
On Wed, 03 May 2006 22:32:39 +0100
Simon Kelley <simon@thekelleys.org.uk> wrote:
> Both net/ipv4/arp.c and net/arm/clip.c create neighbour tables with
> family == AF_INET. For most purposes this is fine, since the two modules
> each hold a pointer to their table and pass it into the neigh_* functions.
>
> A problem arises in neigh_add, which is called by the rtnetlink code and
> which iterates through all the neighbour tables looking for the first
> one with the correct family. Since there are two different tables with
> family == AF_INET, sometimes it picks the wrong one.
>
> This leads to the situation where sending a RTM_NEWNEIGH message via
> netlink can generate an ignored and useless entry in the clip table,
> whilst the not affecting another entry in the ARP table, both entries
> for the same IP.
>
> Viz:
> sid:~# ip neigh
> 192.168.3.40 dev eth0 lladdr 52:54:00:12:34:59 REACHABLE
> 192.168.3.40 dev eth0 FAILED
>
>
> It's not immediately obvious how to fix this in a conceptually clean
> manner: neighbour tables are not associated with single netdevices, and
> they don't carry an address-type field. Given a {IP,lladdr,device}
> triple, its easy to determine if the device is ether-like or CLIP, but
> then the update call would have to go via the ARP and CLIP modules,
> instead of direct to the neighbour module in an address independent way.
> New address types would need further additions to the netlink/neighbour
> code.
>
> OTOH there are several obvious hacks that will fix the immediate
> problem. I'm happy to provide a patch implementing one if that's desired.
>
> Looking again, I think this is also a security hole, since the CLIP code
> keeps a whole struct including pointers in the neighbour table entry
> where ARP has the MAC address. So this might provide a way to poke
> arbitrary pointers into the kernel via RTM_NEWNEIGH. Only for root, though.
>
This was fixed in 2.6.16.6 and current 2.6.17
^ permalink raw reply
* netlink+ARP+CLIP == broken,
From: Simon Kelley @ 2006-05-03 21:32 UTC (permalink / raw)
To: netdev, linux-kernel
Both net/ipv4/arp.c and net/arm/clip.c create neighbour tables with
family == AF_INET. For most purposes this is fine, since the two modules
each hold a pointer to their table and pass it into the neigh_* functions.
A problem arises in neigh_add, which is called by the rtnetlink code and
which iterates through all the neighbour tables looking for the first
one with the correct family. Since there are two different tables with
family == AF_INET, sometimes it picks the wrong one.
This leads to the situation where sending a RTM_NEWNEIGH message via
netlink can generate an ignored and useless entry in the clip table,
whilst the not affecting another entry in the ARP table, both entries
for the same IP.
Viz:
sid:~# ip neigh
192.168.3.40 dev eth0 lladdr 52:54:00:12:34:59 REACHABLE
192.168.3.40 dev eth0 FAILED
It's not immediately obvious how to fix this in a conceptually clean
manner: neighbour tables are not associated with single netdevices, and
they don't carry an address-type field. Given a {IP,lladdr,device}
triple, its easy to determine if the device is ether-like or CLIP, but
then the update call would have to go via the ARP and CLIP modules,
instead of direct to the neighbour module in an address independent way.
New address types would need further additions to the netlink/neighbour
code.
OTOH there are several obvious hacks that will fix the immediate
problem. I'm happy to provide a patch implementing one if that's desired.
Looking again, I think this is also a security hole, since the CLIP code
keeps a whole struct including pointers in the neighbour table entry
where ARP has the MAC address. So this might provide a way to poke
arbitrary pointers into the kernel via RTM_NEWNEIGH. Only for root, though.
Cheers,
Simon.
^ permalink raw reply
* latest -stable breaks Squid
From: Dave Jones @ 2006-05-03 21:19 UTC (permalink / raw)
To: netdev; +Cc: stable, Andreas M. Kirchwitz, Vassilios Kotoulas
[-- Attachment #1: Type: text/plain, Size: 290 bytes --]
So I pushed out an update for Fedora Core 5 users yesterday
that moved the kernel from 2.6.16.9 to 2.6.16.13.
I've since heard "My network performance is awful", and worse
yet, some apps seem broken as in the report below.
Anyone have any ideas ?
Dave
--
http://www.codemonkey.org.uk
[-- Attachment #2: Type: message/rfc822, Size: 4270 bytes --]
From: "Andreas M. Kirchwitz" <fedora-list@list.zikzak.de>
To: fedora-list@redhat.com
Subject: Kernel 2.6.16-1.2107_FC5 breaks Squid
Date: Wed, 3 May 2006 12:53:04 +0000 (UTC)
Message-ID: <slrne5h9tg.or2.amk@nautilus.zikzak.de>
Hi folks!
Just installed the new kernel 2.6.16-1.2107_FC5 (32-bit, i686),
and everything seems to work fine -- except Squid (not matter
if I use the one that ships with FC5 or my own).
No problem with small data objects (a few kilobytes).
telnet localhost 3128
GET http://www.kirchwitz.de/test.html HTTP/1.0
Large data objects won't work. According to ethereal, the data
is loaded successfully. And I also find the complete objects
in /var/spool/squid, but the data is not output to the application:
telnet localhost 3128
GET http://www.heise.de/ HTTP/1.0
After a few kilobytes, the stream suddenly stops. Sometimes,
Squid doesn't do any output at all, although the object is in
the cache.
With the previous kernel 2.6.16-1.2096_FC5 all is well.
What has changed in the kernel that makes Squid break so hardly?
Maybe other applications are affected as well. Don't know yet.
The error with squid was simply very obvious. ;-)
Greetings, Andreas
--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
^ permalink raw reply
* Re: [PATCH 2/3] ipg: leaks in ipg_probe
From: David Gómez @ 2006-05-03 21:00 UTC (permalink / raw)
To: Pekka Enberg; +Cc: Francois Romieu, David Vrabel, linux-kernel, netdev
In-Reply-To: <1146596687.13675.1.camel@localhost>
Hi Pekka,
On May 02 at 10:04:47, Pekka Enberg wrote:
> > No clear idea but it matches the significant part of the BAR register
> > for the 256 bytes of I/O space that the device uses.
>
> OK. David & David, would appreciate if either you could give the patch a
> spin with Francois' changes. Thanks.
I applied latest Francois patch and the changes (and specially the dma
changes) seems to be ok.
On the other hand i'm having some problems. Nothing related to the
patches, because it happens with the original driver too: After some
time using it, the driver becomes unresponsive and i need to restart
the interface and/or unload-load the ipg module. I'd need to compile
it with debug enabled when i have some time to see what it's going
on...
cheers,
--
David Gómez Jabber ID: davidge@jabber.org
^ permalink raw reply
* RE: VJ Channel API - driver level (PATCH)
From: Caitlin Bestler @ 2006-05-03 20:40 UTC (permalink / raw)
To: David S. Miller, johnpol; +Cc: Leonid.Grossman, shemminger, alex, netdev
David S. Miller wrote:
> From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
> Date: Wed, 3 May 2006 22:07:40 +0400
>
>> On Wed, May 03, 2006 at 08:56:23AM -0700, Caitlin Bestler
> (caitlinb@broadcom.com) wrote:
>>>> I'd expect high end NIC ASICs to implement rx steering based upon
>>>> some sort of hash (for load balancing), as well as explicit "1:1"
>>>> steering between a sw channel and a hw channel. Both options for
>>>> channel configuration are present in the driver interface.
>>>> If netfilter assists can be done in hardware, I agree the driver
>>>> interface will need to add support for these - otherwise,
>>>> netfilter processing will stay above the driver.
>>>>
>>>>
>>>
>>> Even if the hardware cannot fully implement netfilter rules there is
>>> still value in having an interface that documents exactly how much
>>> filtering a given piece of hardware can do.
>>> There is no point in having the kernel repeat packet classifications
>>> that have already been done by the NIC.
>>
>> Please do not suppose that vj channel must rely on underlaying
>> hardware.
>
> I am not. I am just saying that it is futile to build
> hardware that cannot handle netfilter at least to some
> extent, because this will result in HW net channels being
> disabled for %99 of real users which makes the hardware just a waste.
Or netfilters being disabled, which would be just as bad or worse.
The kernel and hardware need to co-operate so that users are not
asked to make artificial choices between performance and security.
^ permalink raw reply
* Re: VJ Channel API - driver level (PATCH)
From: David S. Miller @ 2006-05-03 20:35 UTC (permalink / raw)
To: johnpol; +Cc: caitlinb, Leonid.Grossman, shemminger, alex, netdev
In-Reply-To: <20060503180740.GA14506@2ka.mipt.ru>
From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Date: Wed, 3 May 2006 22:07:40 +0400
> On Wed, May 03, 2006 at 08:56:23AM -0700, Caitlin Bestler (caitlinb@broadcom.com) wrote:
> > > I'd expect high end NIC ASICs to implement rx steering based
> > > upon some sort of hash (for load balancing), as well as
> > > explicit "1:1" steering between a sw channel and a hw
> > > channel. Both options for channel configuration are present
> > > in the driver interface.
> > > If netfilter assists can be done in hardware, I agree the
> > > driver interface will need to add support for these -
> > > otherwise, netfilter processing will stay above the driver.
> > >
> > >
> >
> > Even if the hardware cannot fully implement netfilter rules
> > there is still value in having an interface that documents
> > exactly how much filtering a given piece of hardware can do.
> > There is no point in having the kernel repeat packet classifications
> > that have already been done by the NIC.
>
> Please do not suppose that vj channel must rely on underlaying hardware.
I am not. I am just saying that it is futile to build hardware that
cannot handle netfilter at least to some extent, because this will
result in HW net channels being disabled for %99 of real users which
makes the hardware just a waste.
^ permalink raw reply
* Re: VJ Channel API - driver level (PATCH)
From: David S. Miller @ 2006-05-03 20:23 UTC (permalink / raw)
To: Leonid.Grossman; +Cc: shemminger, alex, netdev
In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD7766E23D@nekter>
From: "Leonid Grossman" <Leonid.Grossman@neterion.com>
Date: Wed, 3 May 2006 09:56:18 -0400
> Do you have suggestions on potential hardware assists/offloads for
> netfilter?
We don't know yet what things will look like, that's why we
shouldn't be defining APIs and I cannot give any such advice
yet.
^ permalink raw reply
* sky2 1.3-rc1
From: Stephen Hemminger @ 2006-05-03 19:05 UTC (permalink / raw)
To: Bill Hoover, Thomas Glanzmann, Bertrand Jacquin, micheleschi,
Daniel Drake
Cc: netdev
In-Reply-To: <1146667951.3056.25.camel@fc5test.deadmoose.com>
Here is a new version that addresses some of the outstanding bugs.
* There was a race in receive processing that would cause hang
* Some more support for Yukon Ultra found in dual-core Centrino
laptops (I want one of these).
It does not fix the problems with dual port cards corrupting receive
data (and possibly memory).
http://developer.osdl.org/shemminger/prototypes/sky2-1.3-rc1.tar.bz2
If this works for most people, I'll post as separate patches for 2.6.17
tomorrow.
^ permalink raw reply
* [PATCH] bcm43xx-d80211: measure the channel change time
From: Michael Buesch @ 2006-05-03 19:05 UTC (permalink / raw)
To: John W. Linville; +Cc: Jiri Benc, netdev, bcm43xx-dev
Measure the channel change time with the
bcm43xx tsf timer and remove the guesswork constant. ;)
Tests on my 4306 show that the time comes damn
close to reality.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
===================================================================
--- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c 2006-05-03 18:12:27.000000000 +0200
+++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c 2006-05-03 20:51:24.000000000 +0200
@@ -354,6 +354,33 @@
bcm43xx_write32(bcm, BCM43xx_MMIO_STATUS_BITFIELD, status);
}
+static void bcm43xx_measure_channel_change_time(struct bcm43xx_private *bcm)
+{
+ struct bcm43xx_radioinfo *radio;
+ u64 start, stop;
+ unsigned long flags;
+ u8 oldchan, testchan;
+
+ /* We (ab)use the bcm43xx TSF timer to measure the time needed
+ * to switch channels. This information is handed over to
+ * the ieee80211 subsystem.
+ * Time is measured in microseconds.
+ */
+
+ bcm43xx_lock_mmio(bcm, flags);
+ radio = bcm43xx_current_radio(bcm);
+ oldchan = radio->channel;
+ testchan = (oldchan == 6) ? 7 : 6;
+ bcm43xx_tsf_read(bcm, &start);
+ bcm43xx_radio_selectchannel(bcm, testchan, 0);
+ bcm43xx_tsf_read(bcm, &stop);
+ bcm43xx_radio_selectchannel(bcm, oldchan, 0);
+ bcm43xx_unlock_mmio(bcm, flags);
+
+ assert(stop > start);
+ bcm->ieee->channel_change_time = stop - start;
+}
+
static
void bcm43xx_macfilter_set(struct bcm43xx_private *bcm,
u16 offset,
@@ -3706,6 +3733,7 @@
dprintk(KERN_INFO PFX "80211 cores initialized\n");
bcm43xx_setup_modes(bcm);
bcm43xx_security_init(bcm);
+ bcm43xx_measure_channel_change_time(bcm);
ieee80211_update_hw(bcm->net_dev, bcm->ieee);
ieee80211_netif_oper(bcm->net_dev, NETIF_ATTACH);
ieee80211_netif_oper(bcm->net_dev, NETIF_START);
@@ -4329,7 +4357,6 @@
ieee->host_gen_beacon = 1;
ieee->rx_includes_fcs = 1;
ieee->monitor_during_oper = 1;
- ieee->channel_change_time = 20000;
ieee->tx = bcm43xx_net_hard_start_xmit;
ieee->open = bcm43xx_net_open;
ieee->stop = bcm43xx_net_stop;
--
Greetings Michael.
^ permalink raw reply
* Re: VJ Channel API - driver level (PATCH)
From: Stephen Hemminger @ 2006-05-03 18:49 UTC (permalink / raw)
To: Caitlin Bestler
Cc: Evgeniy Polyakov, Leonid Grossman, David S. Miller, alex, netdev
In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F149E8B4@NT-SJCA-0751.brcm.ad.broadcom.com>
On Wed, 3 May 2006 11:12:15 -0700
"Caitlin Bestler" <caitlinb@broadcom.com> wrote:
> Evgeniy Polyakov wrote:
> > On Wed, May 03, 2006 at 08:56:23AM -0700, Caitlin Bestler
> > (caitlinb@broadcom.com) wrote:
> >>> I'd expect high end NIC ASICs to implement rx steering based upon
> >>> some sort of hash (for load balancing), as well as explicit "1:1"
> >>> steering between a sw channel and a hw channel. Both options for
> >>> channel configuration are present in the driver interface.
> >>> If netfilter assists can be done in hardware, I agree the driver
> >>> interface will need to add support for these - otherwise, netfilter
> >>> processing will stay above the driver.
> >>>
> >>>
> >>
> >> Even if the hardware cannot fully implement netfilter rules there is
> >> still value in having an interface that documents exactly how much
> >> filtering a given piece of hardware can do.
> >> There is no point in having the kernel repeat packet classifications
> >> that have already been done by the NIC.
> >
> > Please do not suppose that vj channel must rely on
> > underlaying hardware.
> > New interface MUST work better or at least not worse than
> > existing skb queueing for majority of users, and I doubt
> > users with netfilter capable hardware are there.
> > It is only some hint to the SW, not rules, that hardware can provide.
> > The best would be ipv4/ipv6 hashing, and I think it is enough.
>
> I agree. I was just stating that *if* there is direct hardware
> support then the software should be enabled to skip
> redundant checks. What I'm suggesting is really the
> equivalent of knowing whether the hardware generates
> or checks CRCs and TCP checksums. Don't mandate
> the feature, just have the option to avoid redundant work.
>
Also like mulitcast filtering, you need to allow for the partial
match case. If hardware can do some of the work, it is helps.
^ permalink raw reply
* Re: VJ Channel API - driver level (PATCH)
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2006-05-03 18:45 UTC (permalink / raw)
To: netdev
Cc: johnpol, caitlinb, Leonid.Grossman, davem, shemminger, alex,
yoshfuji
In-Reply-To: <20060503180740.GA14506@2ka.mipt.ru>
In article <20060503180740.GA14506@2ka.mipt.ru> (at Wed, 3 May 2006 22:07:40 +0400), Evgeniy Polyakov <johnpol@2ka.mipt.ru> says:
> > Even if the hardware cannot fully implement netfilter rules
> > there is still value in having an interface that documents
> > exactly how much filtering a given piece of hardware can do.
> > There is no point in having the kernel repeat packet classifications
> > that have already been done by the NIC.
>
> Please do not suppose that vj channel must rely on underlaying hardware.
> New interface MUST work better or at least not worse than existing skb
> queueing for majority of users, and I doubt users with netfilter capable
> hardware are there.
> It is only some hint to the SW, not rules, that hardware can provide.
> The best would be ipv4/ipv6 hashing, and I think it is enough.
And, I believe that, if a packet contains any ipv6 extension header(s),
including routing header, fragmentation header, etc.,
we should process it in kernel as we do for now.
Regards,
--yoshfuji
^ 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