The kconfig just moved from one file to another one. The problem is still there. --- From: Randy Dunlap <randy.dunlap@oracle.com> Fix sunrpc/rdma build dependencies. Survives 12 build combinations of INET, IPV6, SUNRPC, INFINIBAND, and INFINIBAND_ADDR_TRANS. ERROR: "rdma_destroy_id" [net/sunrpc/xprtrdma/xprtrdma.ko] undefined! ERROR: "rdma_connect" [net/sunrpc/xprtrdma/xprtrdma.ko] undefined! ERROR: "rdma_destroy_qp" [net/sunrpc/xprtrdma/xprtrdma.ko] undefined! ERROR: "rdma_create_id" ...

Read configuration register during probe and use it to size the available VPD. Move existing code using same register slightly earlier in probe handling. Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> --- a/drivers/net/sky2.c 2009-01-26 12:48:31.399586277 -0800 +++ b/drivers/net/sky2.c 2009-01-26 12:48:34.947586089 -0800 @@ -4335,6 +4335,7 @@ static int __devinit sky2_probe(struct p struct net_device *dev; struct sky2_hw *hw; int err, using_dac = 0, wol_default; + u32 ...

The VPD stuff has more data and isn't generally that useful, so move it into the existing debugfs display and use the new PCI VPD accessor routines. Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> --- a/drivers/net/sky2.c 2009-02-03 08:08:38.063805252 -0800 +++ b/drivers/net/sky2.c 2009-02-03 08:09:02.960523549 -0800 @@ -3905,6 +3905,86 @@ static const struct ethtool_ops sky2_eth static struct dentry *sky2_debug; + +/* + * Read and parse the first part of Vital Product ...

Here are some updates to sky2 driver for net-next. -- --

From: "John W. Linville" <linville@tuxdriver.com> Pulled, thanks a lot John. --

VLAN filtering allows the hypervisor to drop packets from VLANs that we're not a part of, further reducing the number of extraneous packets recieved. This makes use of the VLAN virtqueue command class. The CTRL_VLAN feature bit tells us whether the backend supports VLAN filtering. Signed-off-by: Alex Williamson <alex.williamson@hp.com> --- drivers/net/virtio_net.c | 31 ++++++++++++++++++++++++++++++- include/linux/virtio_net.h | 14 ++++++++++++++ 2 files changed, 44 insertions(+), ...

This series adds infrastructure for a new control virtqueue and makes use of it to support set_rx_mode, unicast and multicast address lists, and supporting a hypervisor based VLAN filter. The goal is to make the virtio-net device support more of the features of a physical NIC and allow the hypervisor to discard packets we don't want. These patches are intended for 2.6.30. This is the 4th and hopefully final revision, incorporating a few more tweaks from Rusty. I've renamed ...

From: Alex Williamson <alex.williamson@hp.com> The second patch doesn't apply to the net-next-2.6 tree. Please regenerate these against net-next-2.6 or -next and I'll apply them, thanks. --

Ack, sorry. I had dropped the original first patch that allows setting the virtio_net MAC address since Rusty already accepted it into his patch queue. I can easily munge these to not rely on that (context-only changes), but that'll just leave Rusty with the merge conflict. Rusty, which way do you want these to hit the tree? Thanks, Alex -- Alex Williamson HP Open Source & Linux Org. --

Some Realtek chips (RTL8169sb/8110sb in my case) are unable to retrieve ethtool statistics when the interface is down. The process stays in endless loop in rtl8169_get_ethtool_stats. This is because these chips need to have receiver enabled (CmdRxEnb bit in ChipCmd register) that is cleared when the interface is going down. It's better to update statistics only when the interface is up and otherwise return copy of statistics grabbed when the interface was up (in rtl8169_close). It is ...

From: Jesper Dangaard Brouer <jdb@comx.dk> The UDP header length field is garbage in all of these packets. In the first two packets here, the source and dest ports are That could be a good clue. Do you happen to have multicast routing enabled on this machine? If the multicast destination is non-local and IN_DEV_FORWARD is set on the interface, that puts the packet through ip_mr_input. ip_mr_input() will clone the SKB if it should be delivered locally as well as be forwarded. If ...

Using gretap is the correct way to go. What do you mean that you don't know how to use it as a tunnel? 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 --

From: Breno Leitao <leitao@linux.vnet.ibm.com> Applied, thanks. --

This patch adds a few device ID's. It also removes an ID that was used in an internal engineering version of a device and will never see commercial light. Even if this ID will be 'recycled' in the future, which is very unlikely, we don't know what kind of device will be behind it. Therefore it's safer to remove it. Signed-off-by: Filip Aben <f.aben@option.com> ---

Hello, As reported and discussed below and in <http://www.mail-archive.com/debian-ipv6@lists.debian.org/msg03753.html>, to accept "route information option" on Linux, you have to manually change accept_ra_rt_info_max_plen sysctl value. Other implementations that I know of accept this by default. Is it intentional that Route Information options are ignored by default? I suspect not -- if so, the default value should be (IMHO) 64 or if that's disagreeable, 48. Even if this is ...

Thanks, I'll queue that one up tomorrow. greg k-h --

Thanks Dave. I've changed this and also added gro to my net-next branch. I will send up this bugfix up for 2.6.29 in a few days. --

As far as I'm aware, the smc911x driver works as is on the majority of ARM platforms. The fact that it works is enough justification to leave well alone during the -rc series. Changing it involves risk that something will break, which will cause a regression. This is not a risk that we want, and we certainly don't want any new regressions in the -rc series. The proper time to take No, and that's the problem with splitting it across two separate trees, which is a point I was trying to ...

Eric Dumazet wrote: > Wes Chow a

On Mon, Feb 2, 2009 at 9:14 AM, Maciej Sosnowski Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> -- Cheers, Jeff --

That ID was used in an internal engineering version of a device and will never see commercial light. Even if this ID will be 'recycled' in the future, which is very unlikely, I don't know what kind of device will be behind it. Therefore it's safer to remove it. Regards, Filip- --

From: Evgeniy Polyakov <zbr@ioremap.net> Applied. --

pcnet_cs: fix misuse of the equality operator. Signed-off-by: Cord Walter <qord@cwalter.net> Signed-off-by: Komuro <komurojun-mbn@nifty.com> --- --- linux-2.6.29-rc3/drivers/net/pcmcia/pcnet_cs.c.orig 2009-01-31 06:44:03.000000000 +0900 +++ linux-2.6.29-rc3/drivers/net/pcmcia/pcnet_cs.c 2009-01-31 06:44:21.000000000 +0900 @@ -586,7 +586,7 @@ static int pcnet_config(struct pcmcia_de } if ((link->conf.ConfigBase == 0x03c0) - && (link->manf_id == 0x149) && (link->card_id = ...

From: Roel Kluin <roel.kluin@gmail.com> Also applied, thanks. --

[Empty message]

On Tue, 3 Feb 2009 13:10:00 -0800 --

This is the "interesting bits" of what I am testing. What it does is swap in new counters, sum, then put counter values back onto the current cpu. The replace case is easier since the counters are "old" at that point. --- a/net/ipv4/netfilter/ip_tables.c 2009-02-02 15:06:29.684249364 -0800 +++ b/net/ipv4/netfilter/ip_tables.c 2009-02-03 15:08:30.230188116 -0800 @@ -347,10 +347,12 @@ ipt_do_table(struct sk_buff *skb, mtpar.family = tgpar.family = NFPROTO_IPV4; tgpar.hooknum = hook; ...

The usual approach would be to have three sets of counters, one currently being incremented, one just removed from service, and the last one holding the cumulative value. After a synchronize_net() following removing a set from service, you add in the values in the previous set removed It should be easier to maintain a third set of counters that hold the Good point, the for_each_possible_cpu() was cut out -- I should have gone back and looked at the original patch. Seems like it ...

Hum... reading my mail, this one can be done once only, at the beginning Why then I suggested two different seqlocks, I am wondering :) I need to think a litle bit more, we might do something to allow several "iptables -L" in // maybe an atomic_t to protect counters would be ok : Ie : One atomic_t (counters_readers) to protect counter updates One seqlock (seqlock_rules) to protect rules changes ipt_do_table() doing : { begin: read_seqbegin(&table->seqlock_rules); // it ...

So, is this patch stream at a point where I should try running the 32-core netperf tests against it? And if so, against which tree should I try applying patches? rick jones --

Are these quad core systems? Or dual core w/ hyperthreading? I ask because in your working setup you have 1/2 the number of cpus' and was not sure if you removed an entire package of if you just disabled hyperthreading. Neil --

Good. Can you also test this one instead and tell me if it still works? Rafael --- drivers/pci/pcie/portdrv_pci.c | 16 +--------------- 1 file changed, 1 insertion(+), 15 deletions(-) Index: linux-2.6/drivers/pci/pcie/portdrv_pci.c =================================================================== --- linux-2.6.orig/drivers/pci/pcie/portdrv_pci.c +++ linux-2.6/drivers/pci/pcie/portdrv_pci.c @@ -55,25 +55,13 @@ static int pcie_portdrv_suspend(struct p } -static int ...

Hi Parag, Did you have a chance to check if the patch from Linus (reproduced below) on top of current -git fixed the problem for you too? Thanks, Rafael --- drivers/pci/pcie/portdrv_pci.c | 14 -------------- 1 files changed, 0 insertions(+), 14 deletions(-) diff --git a/drivers/pci/pcie/portdrv_pci.c b/drivers/pci/pcie/portdrv_pci.c index 99a914a..08a8e3c 100644 --- a/drivers/pci/pcie/portdrv_pci.c +++ b/drivers/pci/pcie/portdrv_pci.c @@ -55,16 +55,6 @@ static int ...

From: Sam Ravnborg <sam@ravnborg.org> Thanks for the info but that's how I commited and pushed out the fix already, and it doesn't hurt either :-) --

From: Jarek Poplawski <jarkao2@gmail.com> This is a very interesting idea, but it has some drawbacks: 1) Just like any other allocator we'll need to find a way to handle > PAGE_SIZE allocations, and thus add handling for compound pages etc. And exactly the drivers that want such huge SKB data areas on receive should be converted to use scatter gather page vectors in order to avoid multi-order pages and thus strains on the page allocator. 2) Space wastage and poor ...

1. define 'fragmented enough' 2. the packet size was already negotiated on your existing connections, how are you going to change all those on the fly? 3. what do you do when a remote system sends you a large packet? drop it on the floor? having some pool of large buffers to receive into (and copy out of those buffers as quickly as possible) would cause a performance hit when things get bad, but isn't that better than dropping packets? as for the number of buffers to use. make a ...

How many such preallocated frames is enough? Does it enough to have all sockets recv buffer sizes divided by the MTU size? Or just some of them, Maybe just do not allow jumbo frames when memory is fragmented enough and fallback to the smaller MTU in this case? With LRO/GRO stuff there should be not that much of the overhead compared to multiple-page copies. -- Evgeniy Polyakov --

Comparing performance is pointless because the only time you need to do the copy is when the allocator has failed. So there is *no* alternative to copying, regardless of how slow it is. You can always improve the allocator whether we do this copying fallback or not. 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 --

NTA steals pages from the SLAB so we can maintain any reference counter logic in them, so linear part of the skb may be not really freed/reused until reference counter hits zero. -- Evgeniy Polyakov --

Not to mention that Ethernet isn't just IP, so the protocol that is being used might not have a concept of path MTU discovery at all. 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 --

I guess compound pages are handled by put_page() enough, but I don't think they should be main argument here, and I agree: scatter gather I'm a bit lost here: could you "remind" the way page space would be Yes, this looks reasonable. On the other hand, I think it would be nice to get some opinions of slab folks (incl. Evgeniy) on the expected efficiency of such a solution. (It seems releasing with put_page() will always have some cost with delayed reusing and/or waste of space.) Jarek ...

Not necessarily. Even if the hardware can only DMA into contiguous memory, we can always allocate a sufficient number of contiguous buffers initially, and then always copy them into fragmented skbs at receive time. This way the contiguous buffers are never depleted. Granted copying sucks, but this is really because the underlying hardware is badly designed. Also copying is way better than not receiving at all due to memory fragmentation. Cheers, -- Visit Openswan at ...

It is a solution, but I think it will behave noticebly worse than That's the main point: how to deal with broken hardware? I think (but have no strong numbers though) that having 6 packets with 1500 MTU combined into GRO/LRO frame will be processed way faster than copying 9k MTU into 3 pages and process single skb. -- Evgeniy Polyakov --

Not necessarily. Remember GSO/GRO in essence are just hacks to get around the fact that we can't increase the MTU to where we want it to be. MTU reduces the cost over the entire path while GRO/GSO only do so for the sender and the receiver. In other words when given the choice between a larger MTU with copying or GRO, the larger MTU will probably win anyway as it's Please note that with my scheme, you'd only start copying if you can't allocate a linear skb. So if memory fragmentation ...

Well, we both do not have the data and very likely will not change the opinions :) But we can proceed the discussion in case something interesting will appear. For example I can hack up e1000e driver to do a dumb copy of 9k each time it has received a jumbo frame and compare it with usual 1.5k MTU performance. But getting that modern CPUs are loafing with noticebly big IO chunks, this may only show that CPU was increased with the copy. Yes, absolutely. -- Evgeniy Polyakov --