From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Wed, 18 Oct 2006 07:42:17 +0200
> How many people are using DECNET and want to pay the price of this
> 20 bytes dnports structure ?
I bet you could make that cost get hidden by careful rearrangement
of the struct flow, or adjustment of the implementati
On Tuesday, October 17, 2006 2:54 PM, Eric Dumazet wrote:
>
> Well, did you solve Lennert problem if the final (third packet of
> three packet TCP establishment handshake) packet is missing ? It
> seems no timer will fire and tell you the socket is not usable...
>
Sorry, but I don't know what y
On Tue, 2006-10-17 at 21:55 -0700, Stephen Hemminger wrote:
> > On Tue, 2006-10-17 at 18:51 -0700, Stephen Hemminger wrote:
> > > I would consider this a BAD thing. You are creating a derived work
> > > out of GPL and non-GPL software. This actually will hurt the possible
> > > acceptance
> > > of
David Miller a écrit :
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Wed, 18 Oct 2006 07:08:07 +0200
Each route entry includes a 'struct flow'. This structure has a
current size of 80 bytes. This patch makes a size reduction
depending on
CONFIG_IPV6/CONFIG_IPV6_MODULE/CONFIG_DECNET/CONFIG_IP_ROU
YOSHIFUJI Hideaki / a écrit :
In article <[EMAIL PROTECTED]> (at Wed, 18 Oct 2006 07:08:07 +0200), Eric Dumazet
<[EMAIL PROTECTED]> says:
+#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
struct {
struct in6_addr dadd
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Wed, 18 Oct 2006 07:08:07 +0200
> Each route entry includes a 'struct flow'. This structure has a
> current size of 80 bytes. This patch makes a size reduction
> depending on
> CONFIG_IPV6/CONFIG_IPV6_MODULE/CONFIG_DECNET/CONFIG_IP_ROUTE_FWMARK
> For a
In article <[EMAIL PROTECTED]> (at Wed, 18 Oct 2006 07:08:07 +0200), Eric
Dumazet <[EMAIL PROTECTED]> says:
>
> +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
> struct {
> struct in6_addr daddr;
> struct in
Hi David
Each route entry includes a 'struct flow'. This structure has a current size
of 80 bytes. This patch makes a size reduction depending on
CONFIG_IPV6/CONFIG_IPV6_MODULE/CONFIG_DECNET/CONFIG_IP_ROUTE_FWMARK
For a platform doing IPV4 only, the new size is 36 bytes (instead of 80)
As man
On Wed, 18 Oct 2006 00:26:00 -0400
Pavel Roskin <[EMAIL PROTECTED]> wrote:
> Hello!
>
> On Tue, 2006-10-17 at 18:51 -0700, Stephen Hemminger wrote:
> > I would consider this a BAD thing. You are creating a derived work
> > out of GPL and non-GPL software. This actually will hurt the possible
> >
Evgeniy Polyakov a e'crit :
On Tue, Oct 17, 2006 at 06:45:54PM +0200, Eric Dumazet ([EMAIL PROTECTED])
wrote:
I am not sure I understand what you wrote, English is not our native language.
I think many people gave you feedbacks. I feel that all feedback on this
mailing list is constructive. M
The bcm43xx driver uses 4 locations in the devices sprom to determine
the behavior of the leds. Certain defaults are assigned if all bits are
set in those locations. On at least one BCM4303 chip, the sprom contains
values other than the default, which executes an assertion placed in the
default cas
Signed-off-by: Dave Jones <[EMAIL PROTECTED]>
diff --git a/drivers/net/sb1250-mac.c b/drivers/net/sb1250-mac.c
index db23249..1eae16b 100644
--- a/drivers/net/sb1250-mac.c
+++ b/drivers/net/sb1250-mac.c
@@ -2903,7 +2903,7 @@ #endif
dev = alloc_etherdev(sizeof(struct sbmac_softc))
Hello!
On Tue, 2006-10-17 at 18:51 -0700, Stephen Hemminger wrote:
> I would consider this a BAD thing. You are creating a derived work
> out of GPL and non-GPL software. This actually will hurt the possible
> acceptance
> of the d80211 stack into the mainline kernel.
On the contrary, I think th
On Tue, Oct 17, 2006 at 06:45:54PM +0200, Eric Dumazet ([EMAIL PROTECTED])
wrote:
> On Tuesday 17 October 2006 18:35, Evgeniy Polyakov wrote:
> > On Tue, Oct 17, 2006 at 06:26:04PM +0200, Eric Dumazet ([EMAIL PROTECTED])
> wrote:
> > > On Tuesday 17 October 2006 18:01, Evgeniy Polyakov wrote:
> >
From: [EMAIL PROTECTED] (Stephen J. Bevan)
Date: Tue, 17 Oct 2006 20:21:46 -0700
> * You write "frames will be delivered in order, so on the other side
> IV can be always in sync."
In fact, in addition to your comments, Linux can reorder packets
locally within the system even within traffic for
Dawid Ciezarkiewicz writes:
> I'd be thankful for your opinions about that idea. Please forgive me any
> nuances that I didn't know about.
* I suggest extending the documentation with some motivating examples
of why someone would want to use this rather than IPsec for IP
and/or in what scen
The glue of xfrm.
Signed-off-by: Kazunori MIYAZAWA <[EMAIL PROTECTED]>
---
include/linux/pfkeyv2.h |1 +
net/xfrm/xfrm_algo.c| 18 ++
2 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/include/linux/pfkeyv2.h b/include/linux/pfkeyv2.h
index d5dd471..636e0fb
XCBC needs to allocate the tfm as CBC mode to use
"xor" function in the tfm.
Signed-off-by: Kazunori MIYAZAWA <[EMAIL PROTECTED]>
---
crypto/algapi.c |2 +-
include/crypto/algapi.h |1 +
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/crypto/algapi.c b/crypto/algapi
This is core code of XCBC.
Signed-off-by: Kazunori MIYAZAWA <[EMAIL PROTECTED]>
---
crypto/Kconfig | 10 ++
crypto/Makefile |1
crypto/xcbc.c | 328 +++
3 files changed, 339 insertions(+), 0 deletions(-)
diff --git a/crypto/Kconfig b
Test vectors of XCBC with AES-128.
Signed-off-by: Kazunori MIYAZAWA <[EMAIL PROTECTED]>
---
crypto/tcrypt.c |3 ++
crypto/tcrypt.h | 68 +++
2 files changed, 71 insertions(+), 0 deletions(-)
diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
Hello,
I send patches to support XCBC mode of IPsec.
This patch is for linux-2.6.19-rc2. I checked to also apply
this to net-2.6.
The patches does not use CBC mode in blkcipher. I think
blkcipher provides encryption function of blocks. XCBC
however needs only the last block of encryption. If I us
On Tue, 17 Oct 2006 17:14:29 -0700
David Kimdon <[EMAIL PROTECTED]> wrote:
> Hi,
>
> DadWifi is a port of MadWifi to the d80211 stack. It works now in
> managed and monitor mode, lightly tested. Any card supported by
> MadWifi should be supported by DadWifi [1]. This allows a large
> number of
On Wednesday 18 October 2006 10:14, David Kimdon wrote:
> Hi,
>
> DadWifi is a port of MadWifi to the d80211 stack. It works now in
> managed and monitor mode, lightly tested. Any card supported by
> MadWifi should be supported by DadWifi [1]. This allows a large
> number of cards to now take ad
Hi,
DadWifi is a port of MadWifi to the d80211 stack. It works now in
managed and monitor mode, lightly tested. Any card supported by
MadWifi should be supported by DadWifi [1]. This allows a large
number of cards to now take advantage of the d80211 stack.
DadWifi uses the same (binary only) h
From: Ulrich Kunitz <[EMAIL PROTECTED]>
This patch fixes the bug as reported in the kernel bug tracker
under the id 7244. The bug was simply that the interrupt lock has
been locked outside an interrupt without blocking the interrupt.
Signed-off-by: Ulrich Kunitz <[EMAIL PROTECTED]>
Signed-off-by:
Tested by Newsome on IRC
zd1211 chip 0586:3401 v4330 high 00-13-49 AL2230_RF pa0 g---
Signed-off-by: Daniel Drake <[EMAIL PROTECTED]>
---
This is suitable for 2.6.19
Index: linux/drivers/net/wireless/zd1211rw/zd_usb.c
===
--- linu
Larry Finger pointed out a problem with my ieee80211 IV/ICV stripping patch,
which I forgot about. Sorry about that.
The patch readds the frame_ctl assignment which was accidently dropped.
Signed-off-by: Daniel Drake <[EMAIL PROTECTED]>
Index: linux/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c
==
Ville Nuorvala wrote:
As the IPv6 route lookup now also returns the selected source address
there is no need for a separate source address lookup. In fact, the
source address selection needs to be moved to get_dst() because the
selected IPv6 source address isn't always stored in the route.
Someti
From: "Eric Barton" <[EMAIL PROTECTED]>
Date: Tue, 17 Oct 2006 13:23:10 +0100
> > Even if your two pointers addition (16 bytes on x86_64)
> > doesnt cross a 64bytes
> > line (I didn't checked), they are going to be set to NULL
> > each time a skbuff
> > is allocated , and checked against NULL
From: jamal <[EMAIL PROTECTED]>
Date: Tue, 17 Oct 2006 09:05:31 -0400
> It sounds to me that ethttool needs to have this semantic fix.
> IOW, ethttool doesnt differentiate the two items:
> a) advertised parameters.
> b) link partner negotiated parameters.
>
> and instead #a becomes #b after negot
The following changes since commit 51018b0a3160d253283173c2f54f16746cee5852:
Ulrich Drepper:
make UML compile (FC6/x86-64)
are found in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
upstream-fixes
Dave Kleikamp:
airo: check if n
On Tue, Oct 03, 2006 at 02:57:33PM +0200, [EMAIL PROTECTED] wrote:
> This patch (prism54-en-wpa3.patch) brings WPA/WPA2(RSN) with
> TKIP-Cipher to everyone with a FULLMAC Prism GT/Indigo/Duette card.
> I removed all the parts(e.g.: Hostapd Support) which are not relevant for
> wpa_supplicant (cli
jamal wrote:
On Mon, 2006-16-10 at 11:55 -0700, Auke Kok wrote:
jamal wrote:
I think when the e1000 says via ethtool "rx is on" - it means that it
is _advertising_ flow control as opposed to detecting partner has flow
control capability.
Auke, can you also check this as well?
>>
Just found
On 10/17/06 14:35, Thomas Graf wrote:
Hi Thomas,
> Because otherwise a rule containing only a source prefix match is
> equivalent to a catch-all rule for all lookups not providing a
> source address. An example: Someone adding the rule
>
> ip rule add from 2001::1/128 unreachable
>
> resu
Allocations using alloc_page are taking too long for normal MTU, so
use LPE only for jumbo frames. Disable packet split for IPV6 extension
headers since malformed headers can hang the RX.
Signed-off-bu: Jesse Brandeburg <[EMAIL PROTECTED]>
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
drivers
Move the length (rx_bytes counter) adjustment of 4 bytes down to after the
TBI_ACCEPT workaround.
Signed-off-by: Jesse Brandeburg <[EMAIL PROTECTED]>
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_main.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
Hi,
The following fixes targeted to netdev-2.6#upstream-fixes are available
through git:
git pull git://lost.foo-projects.org/~ahkok/git/netdev-2.6 upstream-fixes
And apply against 4a1d2d81fa327d095a0a8a1f961bace5b0a2f7da
Cheers,
Auke
---
Jesse Brandeburg <[EMAIL PROTECTED]>:
e1000: F
The MANC register should not be read for PCI-E adapters at all, as well as
82543 and older where 82543 would master abort when this register was
accessed.
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_ethtool.c |3 ++-
drivers/net/e1000/e1000_main.c| 21 +
Threshold bitmasks for prefetch, host and writeback were clearing
bits that they were not supposed to. The leftmost 2 bits in the byte
for each threshold are reserved.
Signed-off-by: Bruce Allan <[EMAIL PROTECTED]>
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_hw.h |
Significant fixes -> increment driver version.
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_main.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 89ab34d..8c84863 100644
-
82571 and newer chispets don't need to limit desc. length to 4kb and can
handle 8kb sizes.
Signed-off-by: Jesse Brandeburg <[EMAIL PROTECTED]>
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_main.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --gi
Exclude 82542 when setting up WoL. This card does not do WoL at all.
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_ethtool.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/e1000/e1000_ethtool.c
b/drivers/net/e1000/e1000_ethtool.c
When rebooting with netconsole over e100, the driver shutdown code
would deadlock with netpoll. Reduce shutdown code to a bare minimum
while retaining WoL functionality.
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/net/e100.c | 52 ++
On Tue, 17 Oct 2006 09:05:31 -0400
jamal <[EMAIL PROTECTED]> wrote:
> On Mon, 2006-16-10 at 11:55 -0700, Auke Kok wrote:
> > jamal wrote:
>
> > > I think when the e1000 says via ethtool "rx is on" - it means that it
> > > is _advertising_ flow control as opposed to detecting partner has flow
> >
On Tue, 17 Oct 2006, Adrian Bunk wrote:
On Mon, Oct 16, 2006 at 04:58:14PM -0700, Andrew Morton wrote:
On Mon, 16 Oct 2006 14:16:13 -0400
Vivek Goyal <[EMAIL PROTECTED]> wrote:
Can you please have a look at the attached patch
Looks like a fine patch to me, although it could benefit from a
I am not particularily attached to bitfields or no bitfields. I am
interested in getting d80211 merged. Bitfields have been discussed
as an important TODO. Perhaps this can serve as a starting point for
discussion of the tasks to complete before d80211 is merged?
On Mon, Oct 16, 2006 at 12:34:
jamal wrote:
On Mon, 2006-16-10 at 11:55 -0700, Auke Kok wrote:
jamal wrote:
I think when the e1000 says via ethtool "rx is on" - it means that it
is _advertising_ flow control as opposed to detecting partner has flow
control capability.
Auke, can you also check this as well?
Just found thi
All three one-bit bitfields have been subsumed into the new 'flags'
structure member and the new IEEE80211_KEY_* definitions. The 8 bit
keyidx bitfield is converted to type s8.
Signed-off-by: David Kimdon <[EMAIL PROTECTED]>
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
=
All twelve one-bit bitfields have been subsumed into the new 'flags'
structure member and the new IEEE80211_HW_* definitions.
Signed-off-by: David Kimdon <[EMAIL PROTECTED]>
Index: wireless-dev/drivers/net/wireless/d80211/adm8211/adm8211.c
Both one-bit bitfields have been subsumed into the new 'flags'
structure member and the new IEEE80211_TX_STATUS_* definitions.
Signed-off-by: David Kimdon <[EMAIL PROTECTED]>
Index: wireless-dev/include/net/d80211.h
===
--- wireless
All four one-bit bitfields have been subsumed into the new 'flags'
structure member and the new IEEE80211_CONF_* definitions.
Signed-off-by: David Kimdon <[EMAIL PROTECTED]>
Index: wireless-dev/include/net/d80211.h
===
--- wireless-
On Mon, Oct 16, 2006 at 06:07:25PM +0200, Michael Buesch wrote:
> On Friday 13 October 2006 21:20, David Kimdon wrote:
> > All one-bit bitfields have been subsumed into the new 'flags'
> > structure member and the new IEEE80211_TXCTL_* definitions. The
> > multiple bit members were converted to u8
All one-bit bitfields have been subsumed into the new 'flags'
structure member and the new IEEE80211_TXCTL_* definitions. The
multiple bit members were converted to u8, s8 or u16 as appropriate.
Signed-off-by: David Kimdon <[EMAIL PROTECTED]>
Index: wireless-dev/include/net/d80211.h
Continue d80211 bitfield removal. In general, compilers have
difficulty generating efficient code for bitfields. This patchset
removes all bitfields from include/net/d80211.h.
I converted the 1 bit bitfields into a bit in a u32/u16 or u8 flags
structure member. Larger bitfields I converted into
On Tuesday 17 October 2006 18:35, Evgeniy Polyakov wrote:
> On Tue, Oct 17, 2006 at 06:26:04PM +0200, Eric Dumazet ([EMAIL PROTECTED])
wrote:
> > On Tuesday 17 October 2006 18:01, Evgeniy Polyakov wrote:
> > > Ok, there is one apologist for mmap buffer implementation, who forced
> > > me to create
In article <[EMAIL PROTECTED]> (at Tue, 17 Oct 2006 14:34:15 +0200), Thomas
Graf <[EMAIL PROTECTED]> says:
> Right, that works as well but duplicating the rule for every
> interface is not very practical.
Though I think it is, but we could have "non-local" flag or such.
> Anyways, the point is
On Tue, Oct 17, 2006 at 06:26:04PM +0200, Eric Dumazet ([EMAIL PROTECTED])
wrote:
> On Tuesday 17 October 2006 18:01, Evgeniy Polyakov wrote:
>
> > Ok, there is one apologist for mmap buffer implementation, who forced me
> > to create first implementation, which was dropped due to absense of
> >
On Tuesday 17 October 2006 18:01, Evgeniy Polyakov wrote:
> Ok, there is one apologist for mmap buffer implementation, who forced me
> to create first implementation, which was dropped due to absense of
> remote mental reading abilities.
> Ulrich, does above approach sound good for you?
> I actual
On Tue, Oct 17, 2006 at 05:32:28PM +0200, Eric Dumazet ([EMAIL PROTECTED])
wrote:
> > So the most complex case is when user is going to use both interfaces,
> > and it's steps when mapped ring buffer has overflow.
> > In that case user can either read and mark some events as ready in ring
> > buff
On Tuesday 17 October 2006 11:43, Dan Williams wrote:
> On Tue, 2006-10-17 at 11:05 -0400, Michael Wu wrote:
> > The attached patch adds support for 3887 based prism54 usb wireless
> > adaptors. It is partially based on the islsm driver by Jean-Baptiste
> > Note, but most of the code is new (and us
On Tue, 2006-10-17 at 11:05 -0400, Michael Wu wrote:
> (originally sent to John Linville, forgot to CC netdev..)
>
> Hi,
>
> The attached patch adds support for 3887 based prism54 usb wireless adaptors.
> It is partially based on the islsm driver by Jean-Baptiste Note, but most of
> the code is
On Tuesday 17 October 2006 17:09, Evgeniy Polyakov wrote:
> On Tue, Oct 17, 2006 at 04:25:00PM +0200, Eric Dumazet ([EMAIL PROTECTED])
wrote:
> > On Tuesday 17 October 2006 16:07, Evgeniy Polyakov wrote:
> > > On Tue, Oct 17, 2006 at 03:52:34PM +0200, Eric Dumazet
> > > ([EMAIL PROTECTED])
> >
> >
On Tuesday 17 October 2006 16:25, Eric Dumazet wrote:
> On Tuesday 17 October 2006 16:07, Evgeniy Polyakov wrote:
> > On Tue, Oct 17, 2006 at 03:52:34PM +0200, Eric Dumazet
([EMAIL PROTECTED])
> wrote:
> > > > What about the case, which I described in other e-mail, when in case
of
> > > > the fu
On Tue, Oct 17, 2006 at 04:25:00PM +0200, Eric Dumazet ([EMAIL PROTECTED])
wrote:
> On Tuesday 17 October 2006 16:07, Evgeniy Polyakov wrote:
> > On Tue, Oct 17, 2006 at 03:52:34PM +0200, Eric Dumazet ([EMAIL PROTECTED])
> wrote:
> > > > What about the case, which I described in other e-mail, whe
On Tue, Oct 17, 2006 at 08:59:13AM +0200, Johannes Berg wrote:
> On Mon, 2006-10-16 at 11:39 -0700, David Kimdon wrote:
> You want to adjust that last constant there too, I guess.
Indeed, updated patch inline.
> Why is it an
> enum anyway if things are assigned statically?
I don't have a good a
(originally sent to John Linville, forgot to CC netdev..)
Hi,
The attached patch adds support for 3887 based prism54 usb wireless adaptors.
It is partially based on the islsm driver by Jean-Baptiste Note, but most of
the code is new (and uses d80211 instead of madwifi). It doesn't work
perfect
On Tuesday 17 October 2006 16:07, Evgeniy Polyakov wrote:
> On Tue, Oct 17, 2006 at 03:52:34PM +0200, Eric Dumazet ([EMAIL PROTECTED])
wrote:
> > > What about the case, which I described in other e-mail, when in case of
> > > the full ring buffer, no new events are written there, and when
> > > us
On Tue, Oct 17, 2006 at 03:52:34PM +0200, Eric Dumazet ([EMAIL PROTECTED])
wrote:
> > What about the case, which I described in other e-mail, when in case of
> > the full ring buffer, no new events are written there, and when
> > userspace commits (i.e. marks as ready to be freed or requeued by ke
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6/include/net/ip_fib.h
===
--- net-2.6.orig/include/net/ip_fib.h 2006-10-17 14:35:00.0 +0200
+++ net-2.6/include/net/ip_fib.h2006-10-17 14:36:16.0
On Tuesday 17 October 2006 15:42, Evgeniy Polyakov wrote:
> On Tue, Oct 17, 2006 at 03:19:36PM +0200, Eric Dumazet ([EMAIL PROTECTED])
wrote:
> > On Tuesday 17 October 2006 12:39, Evgeniy Polyakov wrote:
> > > I can add such notification, but its existense _is_ the broken design.
> > > After such
On Tue, Oct 17, 2006 at 03:19:36PM +0200, Eric Dumazet ([EMAIL PROTECTED])
wrote:
> On Tuesday 17 October 2006 12:39, Evgeniy Polyakov wrote:
>
> > I can add such notification, but its existense _is_ the broken design.
> > After such condition happend, all new events will dissapear (although
> >
On Tue, Oct 17, 2006 at 08:12:04AM -0500, Chase Venters ([EMAIL PROTECTED])
wrote:
> > > > Regarding mukevent I'm thinking of a event-type specific struct, that
> > > > is filled by the originating code, and placed into a per-event-type
> > > > ring buffer (which requires modification of kevent_w
On Tuesday 17 October 2006 12:39, Evgeniy Polyakov wrote:
> I can add such notification, but its existense _is_ the broken design.
> After such condition happend, all new events will dissapear (although
> they are still accessible through usual queue) from mapped buffer.
>
> While writing this I h
On Tue, Oct 17, 2006 at 01:50:04PM +0100, Eric Barton ([EMAIL PROTECTED]) wrote:
> Evgeniy,
>
> > You can use existing skb destructor and appropriate reference
> > counter is already there. In your own destructor you need to
> > call old one of course, and it's type can be determined from
> > the
On Tuesday 17 October 2006 05:42, Evgeniy Polyakov wrote:
> On Tue, Oct 17, 2006 at 12:59:47AM -0500, Chase Venters
([EMAIL PROTECTED]) wrote:
> > On Tuesday 17 October 2006 00:09, Johann Borck wrote:
> > > Regarding mukevent I'm thinking of a event-type specific struct, that
> > > is filled by th
On Tue, 2006-17-10 at 09:34 +1000, Russell Stuart wrote:
> The Linux traffic's control engine inaccurately calculates
> transmission times for packets sent over ADSL links. For
> some packet sizes the error rises to over 50%. This occurs
> because ADSL uses ATM as its link layer transport, and AT
On Mon, 2006-16-10 at 11:55 -0700, Auke Kok wrote:
> jamal wrote:
> > I think when the e1000 says via ethtool "rx is on" - it means that it
> > is _advertising_ flow control as opposed to detecting partner has flow
> > control capability.
> > Auke, can you also check this as well?
>
> Just found
Hi David
We currently allocate a fixed size 512 (TCP_SYNQ_HSIZE) slots hash table for
each LISTEN socket, regardless of various parameters (listen backlog for
example)
On x86_64, this means order-1 allocations (might fail), even for 'small'
sockets, expecting few connections. On the contrary,
On Tuesday 17 October 2006 14:04, Martin Schiller wrote:
> On Monday, October 16, 2006 9:02 AM, Lennert Buytenhek wrote:
> > I wrote something like this a couple of years ago:
> >
> > http://marc.theaimsgroup.com/?l=linux-netdev&m=103666165629419&w=2
> > http://marc.theaimsgroup.com/?l=linu
Evgeniy,
> You can use existing skb destructor and appropriate reference
> counter is already there. In your own destructor you need to
> call old one of course, and it's type can be determined from
> the analysis of the headers and skb itself (there are not so
> much destructor's types actually).
* YOSHIFUJI Hideaki / ?$B5HF#1QL@ <[EMAIL PROTECTED]> 2006-10-17 21:17
> In article <[EMAIL PROTECTED]> (at Tue, 17 Oct 2006 13:35:11 +0200), Thomas
> Graf <[EMAIL PROTECTED]> says:
>
> :
> > different logic. In order to solve this, rules must be restricted to
> > one of these paths, i.e. a rule
> In addition to that I'm pretty sure I remember that some clusterfs
> person already posted these patches a while ago and got ripped apart
> in the same way.
Yes - unfortunately I didn't submit my patch personally. And I've
rewritten it since to to avoid the obvious criticisms. This time
around
David Miller wrote:
From: John Heffner <[EMAIL PROTECTED]>
Date: Tue, 17 Oct 2006 00:18:33 -0400
Stephen Hemminger wrote:
On Mon, 16 Oct 2006 20:53:20 -0400 (EDT)
John Heffner <[EMAIL PROTECTED]> wrote:
This patch limits the amount of time you will defer sending a TSO segment
to less than two
> > Also, (please correct me if I'm wrong) I didn't
> > think this would push the allocation over to the next entry in
> > 'malloc_sizes'.
>
> Well, skbuff heads are allocated from dedicated kmem_cache
> (skbuff_fclone_cache & skbuff_head_cache), and these caches are not
> constrained by the siz
On Mon, 16 Oct 2006, Andrew Morton wrote:
> Vaguely. Why doesn't it deadlock if !current_is_keventd()? I mean,
> whether or not the caller is keventd, the flush_scheduled_work() caller
> will still be dependent upon rtnl_lock() being acquirable.
This !current_is_keventd() condition is just wha
On Mon, Oct 16, 2006 at 04:58:14PM -0700, Andrew Morton wrote:
> On Mon, 16 Oct 2006 14:16:13 -0400
> Vivek Goyal <[EMAIL PROTECTED]> wrote:
>
> >
> > Can you please have a look at the attached patch
>
> Looks like a fine patch to me, although it could benefit from a comment
> explaining why all
In article <[EMAIL PROTECTED]> (at Tue, 17 Oct 2006 13:35:11 +0200), Thomas
Graf <[EMAIL PROTECTED]> says:
:
> different logic. In order to solve this, rules must be restricted to
> one of these paths, i.e. a rule intending to make certain prefixes
> unreachable may not apply to the source select
On Monday, October 16, 2006 9:02 AM, Lennert Buytenhek wrote:
>
> I wrote something like this a couple of years ago:
>
> http://marc.theaimsgroup.com/?l=linux-netdev&m=103666165629419&w=2
> http://marc.theaimsgroup.com/?l=linux-netdev&m=106089519611631&w=2
>
> There wasn't a whole lo
* YOSHIFUJI Hideaki / ?$B5HF#1QL@ <[EMAIL PROTECTED]> 2006-10-17 20:00
> In article <[EMAIL PROTECTED]> (at Tue, 17 Oct 2006 12:14:02 +0200), Thomas
> Graf <[EMAIL PROTECTED]> says:
>
> > * Ville Nuorvala <[EMAIL PROTECTED]> 2006-10-17 03:27
> > > @@ -123,7 +111,7 @@ static int fib6_rule_match(st
On Tue, Oct 17, 2006 at 01:53:02AM +0100, Eric Barton ([EMAIL PROTECTED]) wrote:
> > And these days we're trying to figure
> > out how to eliminate skbuff and skb_shared_info struct members
> > whereas you're adding 16-bytes of space on 64-bit platforms.
>
> Do you think the general concept of a z
In article <[EMAIL PROTECTED]> (at Tue, 17 Oct 2006 12:14:02 +0200), Thomas
Graf <[EMAIL PROTECTED]> says:
> * Ville Nuorvala <[EMAIL PROTECTED]> 2006-10-17 03:27
> > @@ -123,7 +111,7 @@ static int fib6_rule_match(struct fib_ru
> > return 0;
> >
> > if (r->src.plen) {
> > -
On Tue, Oct 17, 2006 at 12:59:47AM -0500, Chase Venters ([EMAIL PROTECTED])
wrote:
> On Tuesday 17 October 2006 00:09, Johann Borck wrote:
> > Regarding mukevent I'm thinking of a event-type specific struct, that is
> > filled by the originating code, and placed into a per-event-type ring
> > buff
On Tue, Oct 17, 2006 at 07:10:14AM +0200, Johann Borck ([EMAIL PROTECTED])
wrote:
> Ulrich Drepper wrote:
> > Evgeniy Polyakov wrote:
> >> Existing design does not allow overflow.
> >
> > And I've pointed out a number of times that this is not practical at
> > best. There are event sources which
YOSHIFUJI Hideaki / 吉藤英明 wrote:
In article <[EMAIL PROTECTED]> (at Tue, 17 Oct 2006 10:01:24 +0200), Jean-Mickael
Guerin <[EMAIL PROTECTED]> says:
Although this conversion is very clean and the next patch
is very logic, I'm going to hold on all patches from 7 onward
so there is some time for s
* Ville Nuorvala <[EMAIL PROTECTED]> 2006-10-17 03:27
> @@ -123,7 +111,7 @@ static int fib6_rule_match(struct fib_ru
> return 0;
>
> if (r->src.plen) {
> - if (!(flags & RT6_LOOKUP_F_HAS_SADDR) ||
> + if (flags & RT6_LOOKUP_F_HAS_SADDR &&
>
On Tuesday 17 October 2006 02:53, Eric Barton wrote:
> If so, do you have any ideas about how to do it more economically? It's 2
> pointers rather than 1 to avoid forcing an unnecessary packet boundary
> between successive zero-copy sends. But I guess that might not be hugely
> significant since
In article <[EMAIL PROTECTED]> (at Tue, 17 Oct 2006 10:01:24 +0200),
Jean-Mickael Guerin <[EMAIL PROTECTED]> says:
> > Although this conversion is very clean and the next patch
> > is very logic, I'm going to hold on all patches from 7 onward
> > so there is some time for some discussion of the R
On 17-10-2006 00:04, Greg KH wrote:
...
> diff --git a/net/sched/cls_basic.c b/net/sched/cls_basic.c
> index dfb300b..0f42544 100644
> --- a/net/sched/cls_basic.c
> +++ b/net/sched/cls_basic.c
> @@ -197,7 +197,7 @@ static int basic_change(struct tcf_proto
> if (handle)
> f->hand
On Monday, 16 October 2006 23:30, Andy Gospodarek wrote:
> On Mon, Oct 16, 2006 at 09:07:57PM +0200, Dawid Ciezarkiewicz wrote:
> > >
> > > Before getting into the technical bits of the patch, what's the
> > > reason for wanting to do this, and why is this rather complex manual
> > > weight assi
David Miller wrote:
From: Ville Nuorvala <[EMAIL PROTECTED]>
Date: Tue, 17 Oct 2006 03:13:17 +0300
This patch moves the normal source address selection from
ip6_dst_lookup() into ip6_pol_route_output(), but shouldn't
change the routing or source address selection behavior in
any way.
Signed-of
1 - 100 of 103 matches
Mail list logo
