Evgeniy Polyakov wrote:
> Question with kevents removal from syscall stays open until Ulrich
> accepts or declines mapped buffer implementation.
It was my idea in the first place to use the ring buffer. I'm sure
others had the same idea but that's what I presented. So, I see no
reason you should
On Tue, Aug 08, 2006 at 11:31:56PM -0700, David Miller ([EMAIL PROTECTED])
wrote:
> From: Evgeniy Polyakov <[EMAIL PROTECTED]>
> Date: Wed, 9 Aug 2006 10:25:15 +0400
>
> > Unfortunately it is impossible to use list_empty(), since due to RCU
> > issues kevent can not use list_del_init(), so list_e
On Wed, Aug 09, 2006 at 01:35:05AM -0400, Jeff Garzik wrote:
> Kyle McMartin wrote:
> >From: Grant Grundler <[EMAIL PROTECTED]>
> >
> >IRQs are racing with tulip_down().
> >DMA can be restarted by tulip_interrupt() _after_ we call
> >tulip_stop_rxtx() and the DMA buffers are unmapped. The result
>
From: Ville Nuorvala <[EMAIL PROTECTED]>
Date: Wed, 09 Aug 2006 09:31:15 +0300
> But the ip6_null_entry not always discarded after a failed route lookup!
> On a forwarding router it triggers the ICMPv6 Destination Unreachable
> message to the sender.
Good point, but I remember that in some cases
From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Wed, 9 Aug 2006 10:25:15 +0400
> Unfortunately it is impossible to use list_empty(), since due to RCU
> issues kevent can not use list_del_init(), so list_empty() will
> always show that list is not empty.
I see, just use the LIST_POISON* scheme fo
David Miller wrote:
> From: Thomas Graf <[EMAIL PROTECTED]>
> Date: Wed, 9 Aug 2006 00:16:51 +0200
>
>> * Ville Nuorvala <[EMAIL PROTECTED]> 2006-08-09 01:05
>>> [IPV6]: Make sure fib6_rule_lookup doesn't return NULL
>>>
>>> The callers of fib6_rule_lookup don't expect it to return NU
David Miller wrote:
From: Daniel Phillips <[EMAIL PROTECTED]>
Date: Tue, 08 Aug 2006 22:51:20 -0700
Elaborate please. Do you think that all drivers should be updated to
fix the broken blockdev semantics, making NETIF_F_MEMALLOC redundant?
If so, I trust you will help audit for it?
I think he
On Wed, Aug 09, 2006 at 10:11:59AM +0400, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
> On Tue, Aug 08, 2006 at 10:52:30PM -0700, David Miller ([EMAIL PROTECTED])
> wrote:
> > > Using LIST_POISON is a flag that kevent is in appropriate queue or not,
> > > I can add some flag into the structure, b
Please pull from 'upstream-greg' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git upstream-greg
to receive the following updates:
drivers/net/myri10ge/myri10ge.c |2 +-
net/core/wireless.c | 24 +++-
2 files changed, 24 insertion
On Tue, Aug 08, 2006 at 10:52:30PM -0700, David Miller ([EMAIL PROTECTED])
wrote:
> > Using LIST_POISON is a flag that kevent is in appropriate queue or not,
> > I can add some flag into the structure, but why, if it is clear just by
> > looking into list's pointers.
>
> What is wrong with using
From: Daniel Phillips <[EMAIL PROTECTED]>
Date: Tue, 08 Aug 2006 22:51:20 -0700
> Elaborate please. Do you think that all drivers should be updated to
> fix the broken blockdev semantics, making NETIF_F_MEMALLOC redundant?
> If so, I trust you will help audit for it?
I think he's saying that he
From: Daniel Phillips <[EMAIL PROTECTED]>
Date: Tue, 08 Aug 2006 22:52:34 -0700
> Agreed. But probably more intrusive than davem would be happy with
> at this point.
I'm much more happy with Evgeniy's network tree allocator, which has a
real design and well thought our long term consequences, th
On Tue, Aug 08, 2006 at 10:53:55PM -0700, David Miller ([EMAIL PROTECTED])
wrote:
> From: Evgeniy Polyakov <[EMAIL PROTECTED]>
> Date: Wed, 9 Aug 2006 09:46:48 +0400
>
> > There is another approach for that - do not use slab allocator for
> > network dataflow at all. It automatically has all you
From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Wed, 9 Aug 2006 09:31:14 +0400
I am burnt out on reviewing this endless kevent patch resubmissions,
so I will only comment briefly.
> That's why I'm asking for what exactly should be moved into the
> patchset. I.e. do we need poll/select (it is the
From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Wed, 9 Aug 2006 09:46:48 +0400
> There is another approach for that - do not use slab allocator for
> network dataflow at all. It automatically has all you pros amd if
> implemented correctly can have a lot of additional usefull and
> high-performan
Evgeniy Polyakov wrote:
On Tue, Aug 08, 2006 at 09:33:25PM +0200, Peter Zijlstra ([EMAIL PROTECTED])
wrote:
http://lwn.net/Articles/144273/
"Kernel Summit 2005: Convergence of network and storage paths"
We believe that an approach very much like today's patch set is
necessary for NBD, iSC
Jeff Garzik wrote:
Peter Zijlstra wrote:
Update the driver to make use of the netdev_alloc_skb() API and the
NETIF_F_MEMALLOC feature.
NETIF_F_MEMALLOC does not exist in the upstream tree... nor should it,
IMO.
Elaborate please. Do you think that all drivers should be updated to
fix the b
From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Wed, 9 Aug 2006 09:35:24 +0400
> We can separate kmalloced data from page by using internal page structures
> (lru pointers and PG_slab bit).
Yes, it is one idea.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a
From: Michael Buesch <[EMAIL PROTECTED]>
Date: Wed, 9 Aug 2006 07:03:41 +0200
> I am wondering about d80211 mainline merge plans.
I think this is a non-started until the SMP problems are worked
out. Is it still SMP challenged?
-
To unsubscribe from this list: send the line "unsubscribe netdev" i
From: Daikichi Osuga <[EMAIL PROTECTED]>
Date: Wed, 09 Aug 2006 14:02:37 +0900
> In current RFC3465 Appropriate Byte Count implementation,
> slow start after retransmit timeout does not work.
> I fixed it.
Please provide diffs in unified format.
Also, your email client has corrupted the patch, c
On Tue, Aug 08, 2006 at 09:33:25PM +0200, Peter Zijlstra ([EMAIL PROTECTED])
wrote:
>http://lwn.net/Articles/144273/
>"Kernel Summit 2005: Convergence of network and storage paths"
>
> We believe that an approach very much like today's patch set is
> necessary for NBD, iSCSI, AoE or the l
David Miller wrote:
From: Daniel Phillips <[EMAIL PROTECTED]>
>>Can you please characterize the conditions under which skb->dev changes
after the alloc? Are there writings on this subtlety?
The packet scheduler and classifier can redirect packets to different
devices, and can the netfilter
David Miller wrote:
From: Daniel Phillips <[EMAIL PROTECTED]>
David Miller wrote:
I think the new atomic operation that will seemingly occur on every
device SKB free is unacceptable.
Alternate suggestion?
Sorry, I have none. But you're unlikely to get your changes
considered seriously unle
Michael Buesch wrote:
To heavily reduce maintainance burden I would like to see d80211
going mainline as soon as possible, so that we can feature-freeze
the softmac port of bcm43xx and reduce maintainance to next to zero
there. So if people want freaky features, we simply point them
to the d80211
Kyle McMartin wrote:
From: Helge Deller <[EMAIL PROTECTED]>
WARNING: drivers/net/tulip/de2104x.o - Section mismatch: reference to
.init.text:de_init_one from .data.rel.local after 'de_driver' (at offset 0x20)
WARNING: drivers/net/tulip/de2104x.o - Section mismatch: reference to
.exit.text:de_r
Kyle McMartin wrote:
From: Thibaut Varene <[EMAIL PROTECTED]>
Signed-off-by: Thibaut Varene <[EMAIL PROTECTED]>
Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]>
---
drivers/net/tulip/tulip_core.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/tulip/tulip_c
On Tue, Aug 08, 2006 at 05:58:39PM -0700, David Miller ([EMAIL PROTECTED])
wrote:
> From: Herbert Xu <[EMAIL PROTECTED]>
> Date: Wed, 9 Aug 2006 10:36:16 +1000
>
> > I'm not sure whether the problem is where we store skb_shared_info,
> > or the fact that we can't put kmalloc'ed memory into
> > sk
Kyle McMartin wrote:
From: Grant Grundler <[EMAIL PROTECTED]>
IRQs are racing with tulip_down().
DMA can be restarted by tulip_interrupt() _after_ we call
tulip_stop_rxtx() and the DMA buffers are unmapped. The result
is an MCA (hard crash on ia64) because of an IO TLB miss.
Signed-off-by: Gra
Kyle McMartin wrote:
From: Grant Grundler <[EMAIL PROTECTED]>
The obvious safe registers to read is one from PCI config space.
Signed-off-by: Grant Grundler <[EMAIL PROTECTED]>
Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]>
---
drivers/net/tulip/tulip_core.c |2 ++
1 files changed, 2 ins
Kyle McMartin wrote:
From: Grant Grundler <[EMAIL PROTECTED]>
Include "tulip.h" in winbond-840.c and clean up lots of redundant
definitions.
Signed-off-by: Grant Grundler <[EMAIL PROTECTED]>
Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]>
---
drivers/net/tulip/tulip.h | 17 ++
On Tue, Aug 08, 2006 at 02:32:31PM -0700, Zach Brown ([EMAIL PROTECTED]) wrote:
> Evgeniy Polyakov wrote:
> > Generic event handling mechanism.
> >
> > I send this patchset for comments and review, it still contains AIO and
> > aio_sendfile() implementation on top of get_block() abstraction, whic
Kyle McMartin wrote:
From: Grant Grundler <[EMAIL PROTECTED]>
Signed-off-by: Grant Grundler <[EMAIL PROTECTED]>
Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]>
ACK patches 2-3
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
M
Kyle McMartin wrote:
From: Grant Grundler <[EMAIL PROTECTED]>
A whole slew of fixes for tulip_select_media for:
- Flush posted MMIO writes as per PCI spec
- Polling the reset bit (bit 15) is required to determine when
the "init" sequence can be sent.
This fixes tulip on HP PA-RISC systems,
On Tue, Aug 08, 2006 at 03:02:59PM -0700, Zach Brown ([EMAIL PROTECTED]) wrote:
>
> > +++ b/include/linux/kevent.h
>
> ...
>
> > +#ifdef CONFIG_KEVENT_SOCKET
> > +
> > +extern struct file_operations socket_file_ops;
>
> This doesn't build because socket_file_ops was left static in net/socket.c
Hi,
I am wondering about d80211 mainline merge plans.
Short:
I would like to see a mainline merge of d80211 happening
as soon as possible (next feature merge window).
Long:
I, as one of the main maintainers of the bcm43xx driver, am
maintaining two different branches of the driver at the moment.
In current RFC3465 Appropriate Byte Count implementation,
slow start after retransmit timeout does not work.
I fixed it.
--
Daikichi Osuga
*** linux-2.6.15.i686.org/net/ipv4/tcp_input.c 2006-07-25 15:44:35.0
+0900
--- linux-2.6.15.i686/net/ipv4/tcp_input.c 2006-08-08 14:38:24.0
On Tuesday 08 August 2006 21:42, you wrote:
> And it seems to be your fault. ;-)
Uh, oh. I'm trapped.
> commit 58e5528ee464d38040b9489e10033c9387a10d56
> Author: Michael Buesch <[EMAIL PROTECTED]>
> Date: Sat Jul 8 22:02:18 2006 +0200
>
> [PATCH] bcm43xx: init routine rewrite
Ah, I guess
applied
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Dummy RDMA are always enabled on device startup since commit
9a71db721a2cbb9921b929b2699ab181f5a3c6c0 (to work around buggy
PCIe chipsets which do not implement resending properly). But,
we also need to always re-enable them when resuming the device.
Signed-off-by: Brice Goglin <[EMAIL PROTECTED]>
Don Fry wrote:
I noticed this morning that I had the polarity wrong in my patch
yesterday for older chips in the pcnet32_suspend routine. Here is the
correct patch to test.
A change I made for 2.6.17 and another for 2.6.18 do not work on older
pcnet32 chips which I do not have access to. Plea
applied
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
applied 1-2
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
pulled
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 2006-08-08 at 17:09 -0700, David Miller wrote:
> Trond, I think the highmem check in xs_sendpages() is completely
> bogus, do you mind if we remove it? :-)
>
> The socket layer will properly check the device to make sure it
> can handle highmem pages, and if not it will copy the data into
From: Daniel Phillips <[EMAIL PROTECTED]>
Date: Tue, 08 Aug 2006 18:35:42 -0700
> David Miller wrote:
> > I think the new atomic operation that will seemingly occur on every
> > device SKB free is unacceptable.
>
> Alternate suggestion?
Sorry, I have none. But you're unlikely to get your change
From: Daniel Phillips <[EMAIL PROTECTED]>
Date: Tue, 08 Aug 2006 18:34:43 -0700
> Can you please characterize the conditions under which skb->dev changes
> after the alloc? Are there writings on this subtlety?
The packet scheduler and classifier can redirect packets to different
devices, and can
Using the bcm43xx-d80211 driver/stack combination, my system will usually lock
if the interface is plugged in while booting. On one occasion, it was able to
boot with the following message in my logs. This was run with a non-premptible
unit-processor x86 system. If you need further details, plea
From: Daniel Phillips <[EMAIL PROTECTED]>
Date: Tue, 08 Aug 2006 18:33:20 -0700
> Minor rant: the whole skb_alloc familly has degenerated into an unholy
> mess and could use some rethinking. I believe the current patch gets as
> far as three _'s at the beginning of a function, this shows it is hi
Hi Dave,
David Miller wrote:
I think the new atomic operation that will seemingly occur on every
device SKB free is unacceptable.
Alternate suggestion?
You also cannot modify netdev->flags in the lockless manner in which
you do, it must be done with the appropriate locking, such as holding
t
Thomas Graf wrote:
> skb->dev is not guaranteed to still point to the "allocating" device
once the skb is freed again so reserve/unreserve isn't symmetric.
You'd need skb->alloc_dev or something.
Can you please characterize the conditions under which skb->dev changes
after the alloc? Are ther
Stephen Hemminger wrote:
How much of this is just building special case support for large allocations
for jumbo frames? Wouldn't it make more sense to just fix those drivers to
do scatter and add the support hooks for that?
Short answer: none of it is. If it happens to handle jumbo frames nice
On Wed, Aug 09, 2006 at 10:25:30AM +1000, Herbert Xu wrote:
> The problem here is that the TX clean function does not take the lock
> (nor do we want it to). It can thus come in while you're transmitting
> and empty the queue.
That can be solved with sequence numbers -- ie, we keep track of the n
> But there's alot of state to update (more or less
> atomically, too)
Why does it need to be atomic? It might be enough
to just check a flag and poll for it in the readers and then redo the
lookup.
> in the TCP hashes. Looks tricky to
> do that without hurting performance, especially since
>
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Wed, 9 Aug 2006 10:36:16 +1000
> I'm not sure whether the problem is where we store skb_shared_info,
> or the fact that we can't put kmalloc'ed memory into
> skb_shinfo->frags.
That's a good point.
I guess we could do something like:
struct skb_frag_st
On Tue, Aug 08, 2006 at 07:21:08PM -0400, Benjamin LaHaise wrote:
>
> Looking at e1000, NETIF_F_LLTX is a waste -- the driver takes a spinlock
> almost immediately after entering. Taking the spinlock higher up in the
> network stack, preferably for multiple packets, would at least let the
> CP
On Tue, Aug 08, 2006 at 04:39:15PM -0700, David Miller wrote:
>
> I'm beginning to think that where we store the
> skb_shared_info() is a weakness of the SKB design.
I'm not sure whether the problem is where we store skb_shared_info,
or the fact that we can't put kmalloc'ed memory into skb_shinfo
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Wed, 9 Aug 2006 02:24:04 +0200
> Yes, but even with dynamic growth you still need some upper boundary
> (otherwise a DOS could eat all your memory). And it would need
> to be figured out what it is.
Absolutely. Otherwise the GC'ing of the routing cache
Indan Zupancic wrote:
Hello,
Saw the patch on lkml, and wondered about some things.
On Tue, August 8, 2006 21:33, Peter Zijlstra said:
+static inline void dev_unreserve_skb(struct net_device *dev)
+{
+ if (atomic_dec_return(&dev->rx_reserve_used) < 0)
+ atomic_inc(&dev->rx_r
On Wednesday 09 August 2006 02:11, David Miller wrote:
> From: Andi Kleen <[EMAIL PROTECTED]>
> Date: Wed, 9 Aug 2006 01:23:01 +0200
>
> > The problem is to find out what a good boundary is.
>
> The more I think about this the more I lean towards
> two conclusions:
>
> 1) dynamic table growth is
From: [EMAIL PROTECTED]
Date: Tue, 8 Aug 2006 17:11:29 -0700 (PDT)
> But there's alot of state to update (more or less
> atomically, too) in the TCP hashes. Looks tricky to
> do that without hurting performance, especially since
> you'll probably want to resize the tables when you've
> discovered
On Tue, 8 Aug 2006, David Miller wrote:
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Wed, 9 Aug 2006 01:23:01 +0200
The problem is to find out what a good boundary is.
The more I think about this the more I lean towards
two conclusions:
1) dynamic table growth is the only reasonable way to
On Wed, 9 Aug 2006, Andi Kleen wrote:
I don't think it makes any sense to continue scaling at all after
some point - you won't get better shorter hash chains anymore and the
large hash tables actually cause problems: e.g. there are situations where we
walk
the complete tables and that take
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Wed, 9 Aug 2006 01:23:01 +0200
> The problem is to find out what a good boundary is.
The more I think about this the more I lean towards
two conclusions:
1) dynamic table growth is the only reasonable way to
handle this and not waste memory in all ca
From: Sridhar Samudrala <[EMAIL PROTECTED]>
Date: Tue, 08 Aug 2006 10:19:51 -0700
> We cannot do this as xs_sendpages() doesn't like to use sendpage()
> with highmem pages and has the following check before making the
> actual call.
> /* Hmm... We might be dealing with highmem page
> >
> > IMHO there needs to be a maximum size (maybe related to the sum of
> > caches of all CPUs in the system?)
> >
> > Best would be to fix this for all large system hashes together.
>
> How about using an algorithm like this: up to a certain "size"
> (memory size, cache size,...), scale the h
Part 7 of 8 to add wireless statistics to the bcm43xx-d80211 system.
This patch modifies ieee80211_rx_h_sta_process to transfer the new
status variables into struct sta_info.
The patch is for the August 8 version of Linville's wireless-dev tree.
Signed-Off-By: Larry Finger <[EMAIL PROTECTED]>
d
Part 8 of 8 to add wireless statistics to the bcm43xx-d80211 system.
This patch adds the appropriate range parameters and routine
ieee80211_get_wireless_stats to ieee80211_ioctl.c.
The patch is for the August 8 version of Linville's wireless-dev tree.
Signed-Off-By: Larry Finger <[EMAIL PROTECTE
Part 6 of 8 to add wireless statistics to the bcm43xx-d80211 system.
This patch stores the new variables in 'status' for transmission to
ieee80211.
The patch is for the August 8 version of Linville's wireless-dev tree.
Signed-Off-By: Larry Finger <[EMAIL PROTECTED]>
diff --git a/drivers/net/wi
Part 5 of 8 to add wireless statistics to the bcm43xx-d80211 system.
This patch removes the bogus calculation of link_quality and saves the
value of link_noise in the new variable bcm->stats.link_noise.
The patch is for the August 8 version of Linville's wireless-dev tree.
Signed-Off-By: Larry
Part 4 of 8 to add wireless statistics to the bcm43xx-d80211 system.
This patch removes link_quality and adds link_noise to struct
bcm43xx_stats and defines BCM43xx_RX_MAX_SSI, which is the maximum value for
rssi.
The patch is for the August 8 version of Linville's wireless-dev tree.
Signed-Off-
Part 2 of 8 to add wireless statistics to the bcm43xx-d80211 system. This patch
adds new variables
to struct ieee80211_local to contain the link_quality and noise. These could be
u8's for bcm43xx,
but have been left as int's in case other drivers need a larger range.
The patch is for the Augus
Part 1 of 8 to add wireless statistics to the bcm43xx-d80211 system. This patch
adds new variables
to struct ieee80211_rx_status to contain the latest values for signal, noise,
and the maximum value
of the received ssi. These could be u8's, but I left them as integers in case
other drivers need
Part 3 of 8 to add wireless statistics to the bcm43xx-d80211 system.
This patch adds new variables last_signal, last_noise and max_rssi to
struct sta_info.
The patch is for the August 8 version of Linville's wireless-dev tree.
Signed-Off-By: Larry Finger <[EMAIL PROTECTED]>
diff --git a/net/d8
This set of 8 patches implement wireless statistics for bcm43xx using
the d80211 stack.They also set the framework for the implementation in
other drivers that use the d80211 code. The specific parts are as follows:
1. Add new variables to struct ieee80211_rx_status to contain the
latest values f
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Tue, 8 Aug 2006 11:01:00 -0700
> Ther is no point in using a more expensive reader/writer lock
> for a low contention lock like the fib_info_lock. The only
> reader case is in handling route redirects.
>
> Signed-off-by: Stephen Hemminger <[EMAIL
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Tue, 8 Aug 2006 16:18:24 -0700
> Need to check some more cases in IPX receive.
> If the skb is purely fragments, the IPX header needs to
> be extracted. The function pskb_may_pull() may in theory invalidate
> all the pointers in the skb, so referen
From: Thomas Graf <[EMAIL PROTECTED]>
Date: Wed, 9 Aug 2006 00:16:51 +0200
> * Ville Nuorvala <[EMAIL PROTECTED]> 2006-08-09 01:05
> > [IPV6]: Make sure fib6_rule_lookup doesn't return NULL
> >
> > The callers of fib6_rule_lookup don't expect it to return NULL,
> > therefore it mu
I'm beginning to think that where we store the
skb_shared_info() is a weakness of the SKB design.
It makes it more difficult to have local memory
management schemes and to just wrap SKB's around
arbitrary pieces of data.
The e1000 issue is just one example of this, another
would be any attempt t
On Tue, Aug 08, 2006 at 03:06:07PM -0700, David Miller wrote:
> The driver ->hard_start_xmit() method is invoked with the queue
> unlocked, so this kind of scheme would not be workable.
Looking at e1000, NETIF_F_LLTX is a waste -- the driver takes a spinlock
almost immediately after entering. Ta
Need to check some more cases in IPX receive.
If the skb is purely fragments, the IPX header needs to
be extracted. The function pskb_may_pull() may in theory invalidate
all the pointers in the skb, so references to ipx header must be
refreshed.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
From: Thomas Graf <[EMAIL PROTECTED]>
Date: Wed, 9 Aug 2006 01:11:03 +0200
> Hold on with this patch, netlink pid handling for netlink events
> is completely inconsistent. I want to figure out the right way
> to do it first.
Ok.
-
To unsubscribe from this list: send the line "unsubscribe netdev"
* Thomas Graf <[EMAIL PROTECTED]> 2006-08-08 00:00
> Introduces struct fib_config replacing the ugly struct kern_rta
> prone to ordering issues. Avoids creating faked netlink messages
> for auto generated routes or requests via ioctl.
>
> A new interface net/nexthop.h is added to help navigate thr
Peter Zijlstra wrote:
Update the driver to make use of the netdev_alloc_skb() API and the
NETIF_F_MEMALLOC feature.
NETIF_F_MEMALLOC does not exist in the upstream tree... nor should it, IMO.
netdev_alloc_skb() is in the tree, and that's fine.
Jeff
-
To unsubscribe from this list:
David Miller wrote:
From: Auke Kok <[EMAIL PROTECTED]>
Date: Tue, 08 Aug 2006 13:50:33 -0700
can we really delete these??
netdev_alloc_skb() does it for you
yeah I didn't spot that patch #2 in that series introduces that code - my bad.
Thanks.
Auke
-
To unsubscribe from this list: send t
From: Auke Kok <[EMAIL PROTECTED]>
Date: Tue, 08 Aug 2006 13:50:33 -0700
> can we really delete these??
netdev_alloc_skb() does it for you
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.o
On Tue, 8 Aug 2006, David Miller wrote:
> From: Steven Rostedt <[EMAIL PROTECTED]>
> Date: Tue, 8 Aug 2006 08:24:10 -0400 (EDT)
>
> > Of the 4 timers, only one is a timeout. The other three expire every time,
> > forcing the timer wheel into effect. Even though it's one timer
> > implementing 4,
* Ville Nuorvala <[EMAIL PROTECTED]> 2006-08-09 01:05
> [IPV6]: Make sure fib6_rule_lookup doesn't return NULL
>
> The callers of fib6_rule_lookup don't expect it to return NULL,
> therefore it must return ip6_null_entry whenever fib_rule_lookup fails.
>
> Signed-off-by: V
Michael Buesch wrote:
On Monday 07 August 2006 23:04, Adrian Bunk wrote:
This patch removes three no longer used functions (that are even
generating gcc warnings).
This patch doesn't look right, but it is the result of
58e5528ee464d38040b9489e10033c9387a10d56 in git-netdev...
Hm, can't find
I think the new atomic operation that will seemingly occur on every
device SKB free is unacceptable.
You also cannot modify netdev->flags in the lockless manner in which
you do, it must be done with the appropriate locking, such as holding
the RTNL semaphore.
-
To unsubscribe from this list: send
From: Benjamin LaHaise <[EMAIL PROTECTED]>
Date: Tue, 8 Aug 2006 13:04:32 -0400
> Maybe the way NETDEV_TX_BUSY is implemented is wrong -- that is, it should
> be possible to return a result saying "we sent the packet, but the queue is
> now full". That would eliminate the atomic op that netif_q
Hi David,
please apply the attached patch!
Regards,
Ville
commit 1fb9864632af5a493353643e7acf970da1d4f59f
tree 569fd122cad577f80138a3014c390a7999f5
parent a66c990b9f6b0b9b4c4d2b84f96ddd019b7a8eb3
author Ville Nuorvala <[EMAIL PROTECTED]> 1155073548 +0300
committer Ville Nuorvala <[EMAIL PROTE
On Mon, 2006-07-31 at 09:06 +1000, Russell Stuart wrote:
> It has gone quiet again. In my mind the one unresolved issue
> is whether Patrick intended to remove RTAB with his patch.
> If not, the ATM patch as it stands will have to go in.
>
> Patrick - it would be nice to hear from you.
It appear
> +++ b/include/linux/kevent.h
...
> +#ifdef CONFIG_KEVENT_SOCKET
> +
> +extern struct file_operations socket_file_ops;
This doesn't build because socket_file_ops was left static in net/socket.c.
In any case, kevent.h has no business exposing socket_file_ops to users
of the kevent api just so
From: Steven Rostedt <[EMAIL PROTECTED]>
Date: Tue, 8 Aug 2006 08:24:10 -0400 (EDT)
> Of the 4 timers, only one is a timeout. The other three expire every time,
> forcing the timer wheel into effect. Even though it's one timer
> implementing 4, it's expensive to use it as a watchdog.
It's not a
On Tuesday 08 August 2006 14:27, Mohamed Abbas wrote:
> 2- Scanning; in 3945 driver, we can not tune to other channels while we
> are connected, this will cause a firmware error. The firmware provides a
> scanning command we call so the firmware will take care of switching of
> the available channe
Evgeniy Polyakov wrote:
> Generic event handling mechanism.
>
> I send this patchset for comments and review, it still contains AIO and
> aio_sendfile() implementation on top of get_block() abstraction, which was
> decided to postpone for a while (it is simpler right now to generate patchset
> a
Hi
I am currently working on porting 3945 driver to use d80211. The porting
is going well, thanks for the great stack. I ran into some problems and
issues that I had to use some work around to have it functioning. I hope
I can find the help to point me to right way of using the stack.
1- I ne
* Peter Zijlstra <[EMAIL PROTECTED]> 2006-08-08 21:33
> +struct sk_buff *__netdev_alloc_skb(struct net_device *dev,
> + unsigned length, gfp_t gfp_mask)
> +{
> + struct sk_buff *skb;
> +
> + if (dev && (dev->flags & IFF_MEMALLOC)) {
> + WARN_ON(gfp_mask & (__GFP_NOME
On Tue, 2006-08-08 at 13:50 -0700, Auke Kok wrote:
> Peter Zijlstra wrote:
> > Update the driver to make use of the NETIF_F_MEMALLOC feature.
> >
> > Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
> > Signed-off-by: Daniel Phillips <[EMAIL PROTECTED]>
> >
> > ---
> > drivers/net/e1000/e1000_m
On Tue, 2006-08-08 at 13:57 -0700, Stephen Hemminger wrote:
> On Tue, 08 Aug 2006 21:33:45 +0200
> Peter Zijlstra <[EMAIL PROTECTED]> wrote:
>
> >
> > The core of the VM deadlock avoidance framework.
> >
> > From the 'user' side of things it provides a function to mark a 'struct
> > sock'
> > a
1 - 100 of 196 matches
Mail list logo
