From: Bruce Allan <bruce.w.allan@intel.com> Add device ID for a new variant of the 82574 adapter. Signed-off-by: Bruce Allan <bruce.w.allan@intel.com> Acked-by: John Ronciak <john.ronciak@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> --- drivers/net/e1000e/hw.h | 1 + drivers/net/e1000e/netdev.c | 1 + 2 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/net/e1000e/hw.h b/drivers/net/e1000e/hw.h index 11a2f20..d8b8229 100644 --- ...

"default" is what's inherited by future devices, "all" is supposed to be the My patch wouldn't address getting a static address via a module parameter, that can still be done in, for example, /etc/network/interfaces. So no, this isn't I fixed the autoconf one, but this would still need to be addressed in a future patch, trying to sneak-in before the deadline. Might be too late... I sent the actual patch to netdev a few minutes ago for review. -Brian --

Your email ID has been awarded 750,000,00 GBP in our recent Siemens draw,Contact this office via: Name:.................... Country:................. Sex:..................... Age: ..................... Address:................... --

Your email ID has been awarded 750,000,00 GBP in our recent Siemens draw,Contact this office via: Name:.................... Country:................. Sex:..................... Age: ..................... Address:................... --

From: Vlad Yasevich <vladislav.yasevich@hp.com> Please send them sooner rather than later. --

This is an updated patch series to fix up bind() conflicts between v4-mapped and IPv6 addresses. These patches correct the following problems: 1) Disallow binding of a v4-mapped address on a IPV6_V6ONLY socket. 2) Allow IPv4 wildcards to bind at the same time as a native IPv6 address. 3) Make v4-mapped bind()s consitant with IPv4 native binds. 4) Fix conflict resolutions between v4-mapped addresses, v4 addresses, and v6 addresses Thanks -vlad --

The IPv4 wildcard (0.0.0.0) address does not intersect in any way with explicit IPv6 addresses. These two should be permitted, but the IPv4 conflict code checks the ipv6only bit as part of the test. Since binding to an explicit IPv6 address restricts the socket to only that IPv6 address, the side-effect is that the socket behaves as v6-only. By explicitely setting ipv6only in this case, allows the 2 binds to succeed. Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com> --- ...

The ipv6 version of bind_conflict code calls ipv6_rcv_saddr_equal() which at times wrongly identified intersections between addresses. It particularly broke down under a few instances and caused erroneouse bind conflicts. Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com> --- include/net/addrconf.h | 4 ++-- include/net/udp.h | 2 ++ net/ipv4/udp.c | 3 ++- net/ipv6/addrconf.c | 34 ---------------------------------- net/ipv6/udp.c | 28 ...

net: remove two duplicated include Signed-off-by: Jianjun Kong <jianjun@zeuux.org> --- drivers/net/atl1c/atl1c.h | 1 - drivers/net/dnet.c | 1 - 2 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/net/atl1c/atl1c.h b/drivers/net/atl1c/atl1c.h index ac11b84..e1658ef 100644 --- a/drivers/net/atl1c/atl1c.h +++ b/drivers/net/atl1c/atl1c.h @@ -45,7 +45,6 @@ #include <linux/vmalloc.h> #include <linux/pagemap.h> #include <linux/tcp.h> -#include ...

bus_id is going away, much more rational isn't really needed :) thanks, greg k-h --

From: Jianjun Kong <jianjun@zeuux.org> This one is already in the net-next-2.6 tree --

From: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Applied, thanks. --

From: Daniel Mack <daniel@caiaq.de> Applied. --

This breaks the build: drivers/net/igbvf/ethtool.c: In function 'igbvf_set_ringparam': drivers/net/igbvf/ethtool.c:299: error: implicit declaration of function 'vmalloc' drivers/net/igbvf/ethtool.c:299: warning: assignment makes pointer from integer without a cast drivers/net/igbvf/ethtool.c:346: error: implicit declaration of function 'vfree' --

From: Eric Dumazet <dada1@cosmosbay.com> This will break various packet schedulers and classifiers. Heck sch_sfq.c even uses skb->dst as part of it's flow hash function :-) --

From: Kay Sievers <kay.sievers@vrfy.org> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com> --- drivers/s390/net/qeth_l3_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -urpN linux-2.6/drivers/s390/net/qeth_l3_main.c ...

From: Frank Blaschka <frank.blaschka@de.ibm.com> Performance measurements showed EDDP does not lower CPU costs but increase them. So we dump out EDDP code from qeth driver. Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com> --- drivers/s390/net/Makefile | 2 drivers/s390/net/qeth_core.h | 7 drivers/s390/net/qeth_core_main.c | 99 +---- drivers/s390/net/qeth_core_offl.c | 699 -------------------------------------- drivers/s390/net/qeth_core_offl.h | 76 ...

From: Ursula Braun <ursula.braun@de.ibm.com> When a recovery is started for a qeth device, additional invocations to change a mac address, to configure a VLAN interface on top, or to add multicast addresses should wait till recovery is finished, otherwise recovery might fail. Signed-off-by: Ursula Braun <ursula.braun@de.ibm.com> Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com> --- drivers/s390/net/qeth_l2_main.c | 15 +++++++++++++++ drivers/s390/net/qeth_l3_main.c | 7 ...

From: David Miller <davem@davemloft.net> Here is how I ended up fixing this: rndis_wlan: Fix build with netdev_ops compat disabled. Instead of storing a private ->set_multicast_list, just have a private netdev ops. Signed-off-by: David S. Miller <davem@davemloft.net> --- drivers/net/wireless/rndis_wlan.c | 14 +++++++++++++- 1 files changed, 13 insertions(+), 1 deletions(-) diff --git a/drivers/net/wireless/rndis_wlan.c b/drivers/net/wireless/rndis_wlan.c index 82af21e..db91db7 ...

From: Li Yang <leoli@freescale.com> Because as Stephen showed it didn't handle all cases. Look at the patch I posted, that's the way to go. --

Hello Dave, Herbert! Agreed. It never was the goal to somehow force this into the kernel unless you are happy with it - not that this would have worked anyway ;-) I'd be happy to discuss better ways of solving these issues; the current patches work, but they have their shortcomings. There's no point in including them when you don't deem them sufficient. As I said in my initial email in this thread, I don't know a better solution and depend on some guidance by experts in this area. When ...

From: Eric Dumazet <dada1@cosmosbay.com> Usually it should be OK because the packet schedulers have a sort-of one-behind state that allows them to reinsert the SKB into their queue datastructures without reclassifying. But I'm not %100 sure there isn't some case that might still need skb->dst there. --

no, it doesn't fix the problem. This morning I got the same problem (I was reading the kernel mailing list on lkml.indiana.edu with firefox) --

From: Ramkrishna Vepa <ram.vepa@neterion.com> This driver won't build on 32-bit platforms, not even x86. You didn't build test on i386? You have to provide a readq/writeq implementation on 32-bit machines so that you can choose in what order it is safe to read/write the upper and lower 32-bit halfs of a 64-bit register. See the following from drivers/net/niu.c: #ifndef readq static u64 readq(void __iomem *reg) { return ((u64) readl(reg)) | (((u64) readl(reg + 4UL)) << ...

- vxge driver help text file. - Changes from previous submission - - Incorporated following fixes based on comments from Ben Hutchings Removed references to earlier kernel versions. Removed sections that are similar for all drivers - Load/Unload Identifying the adapter/interface Boot time configuration Removed loadable parameter - NAPI - Napi is always enabled. rx_steering_type & ring_blocks - The driver default settings work well in most if not all cases. Another patch to ...

- Update device ID of X3100 Series 10GbE PCIe I/O Virtualized Server Adapter. Signed-off-by: Sivakumar Subramani <sivakumar.subramani@neterion.com> Signed-off-by: Rastapur Santosh <santosh.rastapur@neterion.com> Signed-off-by: Ramkrishna Vepa <ram.vepa@neterion.com> --- diff -Nurp patch_2/include/linux/pci_ids.h patch_3/include/linux/pci_ids.h --- patch_2/include/linux/pci_ids.h 2009-03-23 09:17:41.000000000 -0700 +++ patch_3/include/linux/pci_ids.h 2009-03-23 09:17:41.000000000 -0700 @@ ...

This patch takes care of Initialization and configuration steps of Neterion Inc's X3100 Series 10GbE PCIe I/O Virtualized Server Adapter. - Device Initialization. - Verification and setting of device config parameters. - Allocation of Tx FIFO and Rx Ring descriptors (DTR). - APIs to get various type of hw stats - APIs to configure RTS (Receive Traffic Steering) - Changes from previous submission - - Incorporated following comments from Ben Hutchings - Start a comment with "/**" to make ...

This patch implements all the driver entry point functions. - Definition of all module loadable paramters. - Implementation of all driver entry point functions. - Changes from previous submission - - Incorporated following review comments from Ben Hutchings - NAPI is always enabled (no option to turn it OFF). - Loadable parameters rx_steering_type: This loadable option is removed. ring_blocks: This loadable option is removed. The driver default settings work well in most if not all ...

- Driver version - Changes from previous submission - - Updated driver version. Signed-off-by: Sivakumar Subramani <sivakumar.subramani@neterion.com> Signed-off-by: Rastapur Santosh <santosh.rastapur@neterion.com> Signed-off-by: Ramkrishna Vepa <ram.vepa@neterion.com> --- diff -Nurp patch_8/drivers/net/vxge/vxge-version.h patch_9/drivers/net/vxge/vxge-version.h --- patch_8/drivers/net/vxge/vxge-version.h 1969-12-31 16:00:00.000000000 -0800 +++ ...

Sorry, this was by accident. Next time I will send the patches I did not wrote the EDDP code but this was my impression too. Thanks for confirming my study. Also the filling of the hardware buffers was not efficient and passing more buffers to the hw was expensive too. --

Patch coming right away. However I have some comment about your way. The choice is yours. - Leo --

Sorry Dave, I thought this was called out earlier, but I see it was not. The igbvf driver requires the following patches applied to your tree to have them compile. Last I heard, these SR-IOV patches were accepted for 2.6.30, in the PCI tree. Yu, can you confirm that these patches have been accepted for ...

Gianfar uses a hardware header FCB for offloading. However when used with bridging or IP forwarding, TX skb might not have enough headroom for the FCB. Reallocate skb for such cases. Signed-off-by: Li Yang <leoli@freescale.com> --- drivers/net/gianfar.c | 31 +++++++++++++++++++++---------- 1 files changed, 21 insertions(+), 10 deletions(-) diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c index 9831b3f..29dc4ee 100644 --- a/drivers/net/gianfar.c +++ ...

This patch bumps the driver release date to March 25th 2009 and release version to 0.22. Signed-off-by: Florian Fainelli <florian@openwrt.org> --- diff --git a/drivers/net/r6040.c b/drivers/net/r6040.c index d3458ef..0a37f99 100644 --- a/drivers/net/r6040.c +++ b/drivers/net/r6040.c @@ -49,8 +49,8 @@ #include <asm/processor.h> #define DRV_NAME "r6040" -#define DRV_VERSION "0.21" -#define DRV_RELDATE "09Jan2009" +#define DRV_VERSION "0.22" +#define DRV_RELDATE "25Mar2009" /* PHY ...

Yes, it's in Jesse's linux-next branch: http://git.kernel.org/?p=linux/kernel/git/jbarnes/pci-2.6.git;a=shortlog;h=linux-next Thanks, Yu --

Here is a patch to factorize these functions, as suggested by Jan Thank you [PATCH] netfilter: factorize ifname_compare() We use same not trivial helper function in four places. We can factorize it. Signed-off-by: Eric Dumazet <dada1@cosmosbay.com> --- include/linux/netfilter/x_tables.h | 23 +++++++++++++++++++++++ net/ipv4/netfilter/arp_tables.c | 14 +------------- net/ipv4/netfilter/ip_tables.c | 23 ++--------------------- net/ipv6/netfilter/ip6_tables.c | 23 ...

When the interface first comes up, it sends a Router Solicitation that triggers Ah, but the IPv6 portions of the interface are created by the ipv6 module when it loads. At the addrconf_init_net() time, no interface are created yet. -vlad --

Oh, and another issue I just figured out this morning... You are letting link-locals to autoconfigure, but did not correctly finish DAD, because once you set disable_ipv6, ip6_output and ipv6_rcv will drop all IPv6 packets. Then later, when you re-enable IPv6, you will not run DAD because the interface will think that it's already finished. So there is a possibility of duplicates not being detected. --

You have just been awarded,the sum of £950.000.00 GBP in the Global Online Promotion, Anniversary Bonanza. held March. For Claims email your details to: glo.pro_alert@btinternet.com Names:...... Address:....... Country:........ Age:....... Sex:......... Phone/cellphone........ regard Mrs Joan Thoms --

>From 1c2f23b1f37f4818c0fd0217b93eb38ab6564840 Mon Sep 17 00:00:00 2001 From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se> Date: Tue, 24 Mar 2009 10:19:27 +0100 Subject: [PATCH] ucc_geth: Move freeing of TX packets to NAPI context. Also increase NAPI weight somewhat. This will make the system alot more responsive while ping flooding the ucc_geth ethernet interaface. Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se> --- drivers/net/ucc_geth.c | 30 ...

--

The following patch will solve the build problem reported by Sachin. But would leave the following warnings. I hope we can ignore them: net/netfilter/xt_LED.c: In function ‘led_timeout_callback’: net/netfilter/xt_LED.c:78: warning: unused variable ‘ledinternal’ net/netfilter/xt_LED.c: In function ‘led_tg_check’: net/netfilter/xt_LED.c:87: warning: unused variable ‘err’ Signed-Off-By: Subrata Modak<subrata@linux.vnet.ibm.com> --- --- a/linux-2.6.29/include/linux/leds.h 2009-03-25 ...

Cant you test (ucce & UCCE_TX_EVENTS) or something here to avoid Why tx completions dont change "howmany" ? --

Some time ago I've tried a similar thing for this driver, but during tcp (or udp I don't quite remember) netperf tests I was getting tx watchdog timeouts after ~2-5 minutes of work. I was testing with a gigabit and 100 Mbit link, with 100 Mbit link the issue was not reproducible. Though, I recalling I was doing a bit more than your patch: I was also clearing the TX events in the ucce register before calling ucc_geth_tx, that way I was trying to avoid stale interrupts. That helped to increase ...

Thanks for testing. --

I did look at the uClinux driver at some point, but decided to rewrite it- from scratch. But to be honest it's been quite some time since I started work on this and I'm not a 100% certain that one part or another may not be borrowed from it. I think this is a good idea, but I'm not quite sure about how this should be implemented. The total number of buffers is dependent on the total buffer size as defined by the second IORESOURCE_MEM resource. That really only leaves the option for ...

[snip] Yes, ether_crc() does the trick. See follow-up patch. Thanks. Cheers, Thierry --

Probably, but I want this patch as simple as possible. There account tx event above... This is unclear and last I checked not very common amongst other drivers in the tree. UCC_GETH_DEV_WEIGHT needs to be a bit bigger than the number of RX HW buffers avaliable, otherwise one won't be able to drain the whole queue in one go. Changing weight to something bigger made a big difference. Jocke --

Ran this on my host against my target board: netperf -t UDP_RR -H 192.168.1.16 netperf -t UDP_STREAM -H 192.168.1.16 netperf -t TCP_STREAM -H 192.168.1.16 netperf -t TCP_SENDFILE -H 192.168.1.16 netperf -t TCP_MAERTS -H 192.168.1.16 netperf -t TCP_RR -H 192.168.1.16 netperf -t TCP_CRR -H 192.168.1.16 Didn't notice any timeouts, but I only have 100Mbit interfaces. --

No, the module parameter disabled it, but we need to re-enable the .all.disable_ipv6 knob in order for lo to be able to configure itself. If I follow Vlad's advice of only setting the .default knob then you I'll see about putting in a callback to send a router solicitation. But on the flip side if someone changes eth0.disable_ipv6=0 to 1, we won't be removing the address either. An ifdown/ifup cycle would remove the need for us to do anything here. -Brian --

Hi. I've hit an issue on my system when I've been using RealTek RTL8139D cards in bonding interface in mode balancing-alb. When I enslave a card, the current active slave (bond->curr_active_slave) is not set and the link is therefore not functional. ---- # cat /proc/net/bonding/bond0 Ethernet Channel Bonding Driver: v3.5.0 (November 4, 2008) Bonding Mode: adaptive load balancing Primary Slave: None Currently Active Slave: None MII Status: up MII Polling Interval (ms): 100 Up Delay ...

If you just set autoconf=0 and don't set disable_ipv6=1, then DAD will complete for the link-locals just fine. If you "disable" them both you won't get any addresses at all. So I guess your point is that if you then enable IPv6 on an interface and it gets a prefix in an RA, you'll add a global without having link-local? It almost looked like the code in addrconf_prefix_rcv() prevented that from happening (ipv6_inherit_eui64()), but it doesn't. -Brian --

The problem isn't the SR-IOV patches it is a difference in architectures. The x86/x86_64 architecture lets you be a bit more sloppy when it comes to including vmalloc. I've seen it in the past with igb, and I suspect that is why we didn't catch this in testing. We just need to add a #include of vmalloc.h in ethtool.c and the issue should be fixed. Thanks, Alex --

Thanks. The discussions seems to be over already, so I'll just collect the resulting patches :) --

Hi Stephen, the CAN stuff i mailed to you is still missing. Sigh. Oliver --

Just to clarify: does the problem happens when you have the MARK rule above in a user-defined chain that has more then one jump leading to it or does it also happen in other cases? --

Applied, thanks. --

=> I triggered the bug with a real world example: - first add a rule with a MARK target using a set mark with the first/sign bit set to one. This target is coded with this mark put at the same place than the verdict field of standard targets. (note this should be triggered by a lot of targets but I got it with MARK) - try to add another rule (with -A or -I but this works too with restore, the idea is to get a replace ioctl with an illegal value in a verdict position). - if you are ...

Yes this fail_over_mac is en exception. In fact I was playing with fail_over_mac bonding interface in bridge and I have no luck to force a problem with two NICs. However with 3 NICs I've managed it to the state of 100% packet loss. I'm going --

This one clashes with Florian's changes to get rid of nf_ct_l4proto_find_get(). I've pushed out the patches I've already applied, please rediff the remaining ones against my current tree. Thanks. --

Hi Patrick Here is the patch I had the time to test this time... No problem so far on my machine. I did a UDP flood stress. Thank you [PATCH] conntrack: use SLAB_DESTROY_BY_RCU and get rid of call_rcu() Use "hlist_nulls" infrastructure we added in 2.6.29 for RCUification of UDP & TCP. This permits an easy conversion from call_rcu() based hash lists to a SLAB_DESTROY_BY_RCU one. Avoiding call_rcu() delay at nf_conn freeing time has numerous gains. First, it doesnt fill RCU queues ...

OK I just realized my mistake, please ignore :) --

Ah yes, I forgot that for UDP/TCP I had to change locking on this part. Because messing with reference count was crazy... But in UDP/TCP we have different spinlock for each chain, so hold time was small enough. So I guess that with central conntrack lock, we need to take references on entries while dumping them. --

Yes, I think so too. --

Yes indeed, this is what I thought too, thanks Jarek. I tested following patch today on my machine, but obviously could not try all possible quirks :) [PATCH] net: release dst entry in dev_hard_start_xmit() One point of contention in high network loads is the dst_release() performed when a transmited skb is freed. This is because NIC tx completion calls skb free long after original call to dev_queue_xmit(skb). CPU cache is cold and the atomic op in dst_release() stalls. On SMP, this ...

Can we assume the next pointer still points to the next entry in the same chain after the refcount dropped to zero? --

Alas I'm a bit concerned with virtual devs, e.g. now I'm looking at xmits in macvlan and pppoe. Maybe this patch should exclude them? --

I think double entries are not a problem, as you say, there are already other cases where this can happen. But I think we should try our best that every entry present at the start and still present at the end of a dump is also contained in the dump, otherwise the guantees seem to weak to still be useful. Thats true. But its a very rare operation, so I think its mainly a documentation issue. --

If your concern is to not forget entries, and we are allowed to print some entries several times, then we can just check the final "nulls" value, and if we find a different value than expected for chain N, go back to begining of chain N. No need to check hash value (this could help not print several time same entry, we dont care that much) + while (is_a_nulls(head)) { + if (likely(get_nulls_value(head) == st->bucket)) { + if (++st->bucket >= ...

What about things like USB network adapters where the topology is not fixed? Presumably we would want to use some sort of unique identifier, and the MAC comes to mind. Of course, then you run into the problem of how to deal with duplicate MACs. Chris --

Hi Patrick, this is a resend of the last three patches send last week, which are now rebased against commit af9d32ad6718b9a of nf-net-next-2.6. I have changed the first patch of this series to use RCU, which you complained about after my initial post. Other than that this series is unchanged. I'll send another patch shortly which adresses the points Pablo made last week. Many thanks! /holger --

Usefull for all protocols which do not add additional data, such as GRE or UDPlite. Signed-off-by: Holger Eitzenberger <holger@eitzenberger.org> Index: nf-next-2.6/include/net/netfilter/nf_conntrack_l4proto.h =================================================================== --- nf-next-2.6.orig/include/net/netfilter/nf_conntrack_l4proto.h +++ nf-next-2.6/include/net/netfilter/nf_conntrack_l4proto.h @@ -113,6 +113,7 @@ extern int nf_ct_port_tuple_to_nlattr(st const struct ...

Applied, thanks. --

Holger Eitzenberger wrote: Also applied, thanks Holger. --

Hmm.. isn't this test for dst == NULL in ip_rcv_finish expected to be negative for loopback source? Jarek P. --

Hi Patrick, the following patch against latest nf-net-next-2.6 tries to address the concerns raised by Pablo about the inacurate computation of the ctnetlink skb. I simply try to properly #ifdef the NLAs where possible. Please check. Thanks. /holger Ah, I still owe you a performance comparison! ;) --

From: Alexander Duyck <alexander.h.duyck@intel.com> Yes, that was the problem. I thought it was dead obvious from the build failure message. What else could a lack of visible vmalloc() declaration mean? :-/ --

From: Joakim Tjernlund <joakim.tjernlund@transmode.se> The weight is not for the sake of your device, it's for the sake of fairness with others. Please just use 64, like every other driver does. I'm not applying this. --

From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se> You're not supposed to "drain the whole queue in one go", that is not the goal of the weight value. The goal of the weight value is that it is low enough such that other devices also scheduled for NAPI on the current processor can get some fair time to process packets too. --

From: Alexander Duyck <alexander.h.duyck@intel.com> This adds an igbvf driver to handle virtual functions provided by the igb driver when SR-IOV has been enabled. A virtual function is a lightweight pci-e function that supports a single queue and shares resources with the 82576 physical function contained within the igb driver. To spawn virtual functions from the igb driver all that is needed is to issue a echo X > /sys/class/ethY/num_vfs. X can be a value between 0 and 7, 0 will disable ...

On Wed, Mar 25, 2009 at 2:52 PM, Jeff Kirsher into drivers/net/igbvf/ethtool.c. We verified that this fixes the compilation issues on PPC. -- Cheers, Jeff --

The sysfs part of this is already in net-next as it isn't part of the igbvf driver it is part of igb. It was added in over a month ago: http://patchwork.ozlabs.org/patch/23471/ I will see what we can do to make use of a netlink interface. I'm honestly not even sure if it will work well for this kind of setup since the VF driver won't even be running on the same OS in most cases. For now the sysfs code in igb is actually quite minimal, and the main goal was to keep the interface as ...

Stephen, [Ram] Agreed. The reason we have some of these options is due to customer feedback who want the interface to come up on a boot with a configuration that is different from the driver default. This may be a feature that we could add to ethtool, by giving an option to change [Ram] We have an ethtool option already for this parameter but needed the configuration to persist over a boot as noted above. Do you have a [Ram] Here's a proposal/wish list. Please let me know what you feel ...

From: Frank Blaschka <blaschka@linux.vnet.ibm.com> I keep meaning to get back to a project I was working on that would make generic the by-hand TSO that drivers such as drivers/net/sfc/ are doing. Just like this EDDP code seems to have been doing, they claim to be TSO capable as a device but it is all done in software. The hope is to write a generic framework, and skb_dma_map() and skb_dma_unmap() were created as initial infrastructure for that. Anyways, if I ever complete that project, ...