[PATCH net-2.6.23 take 2] Per-datagram TTL and TOS via sendmsg()

[This time with automatic carriage return off :-$] This patch adds support for specifying IPv4 Time-To-Live (IP_TTL) and/or Type-Of-Service (IP_TOS) values on a per datagram basis through sendmsg() ancilliary data. Until then, it only worked for IPv6 sockets (using IPV6_HOPLIMIT and IPV6_TCLASS

[PATCH net-2.6.23 take 3] Per-datagram TTL and TOS via sendmsg()

[Hmm, stupid me. Right this time. Sorry for the line noise.] This patch adds support for specifying IPv4 Time-To-Live (IP_TTL) and/or Type-Of-Service (IP_TOS) values on a per datagram basis through sendmsg() ancilliary data. Until then, it only worked for IPv6 sockets (using IPV6_HOPLIMIT and I

[PATCH] CXGB3: Replace kcalloc(1,...) with kmalloc() in cxgb3_offload.c.

Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]> --- diff --git a/drivers/net/cxgb3/cxgb3_offload.c b/drivers/net/cxgb3/cxgb3_offload.c index ebcf35e..999bc41 100644 --- a/drivers/net/cxgb3/cxgb3_offload.c +++ b/drivers/net/cxgb3/cxgb3_offload.c @@ -1105,7 +1105,7 @@ int cxgb3_offload_activa

Re: Splitting e1000 (Was: Re: e1000: backport ich9 support from 7.5.5 ?)

Stephen Hemminger wrote: I think rather than having a meta-discussion, which always seems to degenerate into finger pointing. Let's look at the code. The problem with popular drivers (as I too well know) is that user's seem to find every wart. There are lots of old drivers that never seem to get

Re: [PATCH] CXGB3: Replace kcalloc(1,...) with kmalloc() in cxgb3_offload.c.

On Sun, 2007-07-08 at 05:39 -0400, Robert P. J. Day wrote: > - t = kcalloc(1, sizeof(*t), GFP_KERNEL); > + t = kcalloc(sizeof(*t), GFP_KERNEL); ^ I don't think that's going to work, and shouldn't it probably use kzalloc instead of kmalloc (as you wrote in subject) johannes

[PATCH] ieee1394: first minimal NUMA awareness

Association of a host device with a node on NUMA machines optimizes allocations of skbs given from the networking stack to eth1394. Signed-off-by: Stefan Richter <[EMAIL PROTECTED]> --- Note, in Linux 2.6.20 and earlier and 2.6.23 and later, eth1394 calls or will call SET_NETDEV_DEV(eth1394_netde

[PATCH] [NET]: Another unnecessary net/tcp.h inclusion in net/dn.h

No longer needed. Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]> --- include/net/dn.h |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/include/net/dn.h b/include/net/dn.h index ac4ce90..6277783 100644 --- a/include/net/dn.h +++ b/include/net/dn.h @@ -3,7 +3,6 @@ #inc

Re: [RFC 2/2] shrink size of scatterlist on common i386/x86-64

On Fri, Jul 06, 2007 at 10:14:56AM -0700, Williams, Mitch A wrote: > David Miller wrote: > >> Okay, but then using SG lists makes skbuff's much bigger. > >> > >>fraglistscatterlistper skbuff > >> 32 bit 8 20 +12 * 18 = +216! > >> 64 bi

Re: [RFC 2/2] shrink size of scatterlist on common i386/x86-64

On Fri, Jul 06, 2007 at 12:20:19PM -0700, David Miller wrote: > From: "Williams, Mitch A" <[EMAIL PROTECTED]> > Date: Fri, 6 Jul 2007 10:14:56 -0700 > > > In my opinion, IOMMU table locking is the major issue with this > > type of architecture. Since both Intel and AMD are touting IOMMUs > > for

Re: Splitting e1000 (Was: Re: e1000: backport ich9 support from 7.5.5 ?)

Stephen Hemminger wrote: I would really like to continue with my original plan that I posted that follows Christoph's idea. I hope you can all agree with that so we can get on with this. I think rather than having a meta-discussion, which always seems to degenerate into finger pointing. Let's l

Re: Splitting e1000 (Was: Re: e1000: backport ich9 support from 7.5.5 ?)

Kok, Auke wrote: This is not acceptable and hardly fair to expect from us. It also exposes users to endless delays and uncertainties as to a final resolution. Not to mention that writing a driver from scratch for (just) ich9 will take significant time, is silly since it's almost identical to

Re: Splitting e1000 (Was: Re: e1000: backport ich9 support from 7.5.5 ?)

Arjan van de Ven wrote: I'd second this; also lets be honest and fair about things and use a similar standard for all drivers; are we going to ask all driver submitters to remove NAPI, TSO and other stuff? I would hope not. Are That was merely a suggestion. My general meaning was "small driv

Re: Splitting e1000 (Was: Re: e1000: backport ich9 support from 7.5.5 ?)

Stephen Hemminger wrote: I think rather than having a meta-discussion, which always seems to degenerate into finger pointing. Let's look at the code. The problem with popular drivers (as I too well know) is that user's seem to find every wart. There are lots of old drivers that never seem to get

Re: RFR: New e1000 driver (e1000new), was: Re: e1000: backport ich9 support from 7.5.5 ?

Arjan van de Ven wrote: Kok, Auke wrote: Jeff Garzik wrote: Andrew Morton wrote: On Fri, 29 Jun 2007 14:39:20 -0700 "Kok, Auke" <[EMAIL PROTECTED]> wrote: That's why we want to introduce a second e1000 driver (named differently, pick any name) that contains the new code base, side-by-side i

Re: RFR: New e1000 driver (e1000new), was: Re: e1000: backport ich9 support from 7.5.5 ?

Roland Dreier wrote: one possibility would be to merge e1000new with support only for chips not supported by e1000, and semi-freeze e1000 (fixes only, new device support goes into e1000new). indeed. Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body

Re: RFR: New e1000 driver (e1000new), was: Re: e1000: backport ich9 support from 7.5.5 ?

James Chapman wrote: I envisage something like this:- e1000_core.c- common code used by all drivers of the e1000 family. Exports functions used by actual drivers. Loadable as a separate module when built as a module. e1000_82541.c- driver for 82541 e1000_82542.c-

Re: Splitting e1000 (Was: Re: e1000: backport ich9 support from 7.5.5 ?)

On 7/8/07, Jeff Garzik <[EMAIL PROTECTED]> wrote: * e1000 gets feedback * Intel disappears for months * Intel reappears with e1000 rewrite * you ask them for another complete (simpler) rewrite * Intel fights tooth and nail when the driver is not accepted verboten I don't think it must be as

Re: Splitting e1000 (Was: Re: e1000: backport ich9 support from 7.5.5 ?)

Jeff Garzik wrote: Arjan van de Ven wrote: I'd second this; also lets be honest and fair about things and use a similar standard for all drivers; are we going to ask all driver submitters to remove NAPI, TSO and other stuff? I would hope not. Are That was merely a suggestion. My general mea

Re: RFR: New e1000 driver (e1000new), was: Re: e1000: backport ich9 support from 7.5.5 ?

I reject the notion that a "flag day" switchover for a huge mass of e1000 users is the correct path. I do not think that best serves Linux users. so the options we have is do it one pci id a time; and the suggestion by others like Christoph has been to make the split at the PCI Express swi

Re: [E1000-devel] RFR: New e1000 driver (e1000new), was: Re: e1000: backport ich9 support from 7.5.5 ?

On Jul 8, 2007, at 1:14 PM, Arjan van de Ven wrote: I reject the notion that a "flag day" switchover for a huge mass of e1000 users is the correct path. I do not think that best serves Linux users. so the options we have is do it one pci id a time; and the suggestion by others like Christo

Re: [Bugme-new] [Bug 8724] New: Unaligned acess in udp_recvmsg() on EV56

On Sun, 8 Jul 2007 14:30:17 -0700 (PDT) [EMAIL PROTECTED] wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=8724 > >Summary: Unaligned acess in udp_recvmsg() on EV56 >Product: Platform Specific/Hardware >Version: 2.5 > KernelVersion: 2.6.22-rc7-git7 >

Re: [Cbe-oss-dev] [PATCH] ps3: gigabit ethernet driver for PS3, take3

Hi, On Fri, 6 Jul 2007 13:02:41 -0500, [EMAIL PROTECTED] (Linas Vepstas) mentioned: > of the spidernet device driver. Please note that the old > spidernet had absolutely disasterous performance for transmit; > it also had a variety of crazy hangs and lockups under > high-stress conditions; or N

Re: [PATCH] [2.6.22] Fix a potential NULL pointer dereference in free_shared_mem() in drivers/net/s2io.c

Micah Gruber wrote: This patch fixes a potential null dereference bug where we dereference nic before a null check. This patch simply moves the dereferencing after the null check. Signed-off-by: Micah Gruber < [EMAIL PROTECTED] > any chance you can resend in an ema

[PATCH] [2.6.22] Fix a potential NULL pointer dereference in free_shared_mem() in drivers/net/s2io.c

This patch fixes a potential null dereference bug where we dereference nic before a null check. This patch simply moves the dereferencing after the null check. Signed-off-by: Micah Gruber < [EMAIL PROTECTED]> --- a/drivers/net/s2io.c +++ b/drivers/net/s2io.c @@ -789,12 +789,14 @@ struct m

[PATCH] [2.6.22] Remove unneeded pointer idev from addrconf_cleanup() in net/ipv6/addrconf.c

This trivial patch removes the unneeded pointer idev returned from __in6_dev_get(), which is never used. The check for NULL can be simply done by if (__in6_dev_get(dev) == NULL). Signed-off-by: Micah Gruber < [EMAIL PROTECTED]> --- a/net/ipv6/addrconf.c +++ b/net/ipv6/addrconf.c @@ -4240,7 +4240

[RFC] Allow LSM to use IP address/port number. (was Re: [PATCH 1/1] Add post accept()/recvmsg() hooks.)

Hello. This thread is from http://marc.info/?t=11834645705&r=1&w=2 . I want to use tcp_wrapper-like filtering using LSM. But it seems that there are cases (recvmsg() and read()?) where __sock_recvmsg() is called with msg->name == NULL and msg->msg_namelen == 0 that makes what I want to do imp

[no subject]

Hi after some email exchange with Stephen Hemminger i decide to forward the question to netdev ml. I'm using vmware 6 and bridged networking with interface eth1 (sky2 driver). The brigde works only when eth1 has the physical connection enabled (another pc plugged in), so i always need to have