My somewhat confusing netperf script (to run on client) is attached below.
Server just requires
to run netserver. Client is not completely accurate since I am not using
netperf4 (moving to
that after some initial hiccups).
thanks,
- KK
(See attached file: netperf.scp)
J Hadi Salim <[EMAIL PROT
On Thu, 7 Jun 2007 10:10:44 +0530
"Tej Parkash" <[EMAIL PROTECTED]> wrote:
> hi
>
> i just want to have something like tcp layer sitting below inet layer.
> so that i can directly offload everything to NIC
> and i want it to be placed dynamically. so depending on the nic i can
> offload the featu
hi
i just want to have something like tcp layer sitting below inet layer.
so that i can directly offload everything to NIC
and i want it to be placed dynamically. so depending on the nic i can
offload the feature or can make it normal flow.
i.e. both layer should exist and normal functionality sh
Hi Andi,
I thank you for your comments.
Andi Kleen <[EMAIL PROTECTED]> writes:
> > Your suggestion, to utilize NET_XMIT_* code returned from an
> > underlying layer, is done in tcp_transmit_skb.
> >
> > But my problem is that tcp_transmit_skb is not called during a
> > certain period of time. S
On Wed, Jun 06, 2007 at 06:04:21PM -0700, Andrew Morton wrote:
> There _should_ be some #ifdeffable thing which is being passed to cpp when
> we run sparse (but I'm not sure what it is).
#ifdef __CHECKER__
(See include/linux/compiler.h, this is how we implement __user & friends)
Dave
On Wed, 2007-06-06 at 16:53 -0700, David Miller wrote:
> There are of course other uses for multiple TX queues, and in
> particular my finer-grained locking example.
>
> I'm still amazed the TX locking issue wasn't clear to you,
> too nervous about tonight's game? :)
It's too depressing - so i ca
On Wed, 06 Jun 2007 15:33:46 -0700 James Ketrenos <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > On Wed, 06 Jun 2007 13:51:41 -0700 James Ketrenos <[EMAIL PROTECTED]> wrote:
> >
> * make C=2 CF=-Wall will complain if you use ARRAY_SIZE on global data
> */
> #define GLOBAL_
On Wed, Jun 06, 2007 at 04:52:15PM -0700, David Miller wrote:
> For the locking is makes a ton of sense.
>
> If you have sendmsg() calls going on N cpus, would you rather
> they:
>
> 1) All queue up to the single netdev->tx_lock
>
> or
>
> 2) All take local per-hw-queue locks
>
> to transmit t
On Wed, 2007-06-06 at 20:53 +0200, Thomas Klein wrote:
> This patch fixes a possible kernel panic due to not checking the vlan group
> when processing received VLAN packets and a malfunction in VLAN/hypervisor
> registration.
>
>
> Signed-off-by: Thomas Klein <[EMAIL PROTECTED]>
> ---
>
>
> dif
Andrew Morton wrote:
> On Wed, 06 Jun 2007 13:51:41 -0700 James Ketrenos <[EMAIL PROTECTED]> wrote:
>
* make C=2 CF=-Wall will complain if you use ARRAY_SIZE on global data
*/
#define GLOBAL_ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
>>> This is identical to ARRAY_SIZE.
>>>
>>> An
On Wed, 6 Jun 2007 16:35:34 -0700 Andrew Morton wrote:
> On Wed, 06 Jun 2007 13:51:41 -0700 James Ketrenos <[EMAIL PROTECTED]> wrote:
>
> >
> > >> * make C=2 CF=-Wall will complain if you use ARRAY_SIZE on global data
> > >> */
> > >> #define GLOBAL_ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
>
From: jamal <[EMAIL PROTECTED]>
Date: Wed, 06 Jun 2007 19:54:47 -0400
> On Wed, 2007-06-06 at 16:48 -0700, Rick Jones wrote:
> > > RX queues - yes, I can see; TX queues, it doesnt make sense to put
> > > different rings on different CPUs.
> >
> > To what extent might that preclude some cacheli
From: Rick Jones <[EMAIL PROTECTED]>
Date: Wed, 06 Jun 2007 16:48:59 -0700
> > RX queues - yes, I can see; TX queues, it doesnt make sense to put
> > different rings on different CPUs.
>
> To what extent might that preclude some cachelines bouncing hither and
> yon between the CPUs?
I think
From: jamal <[EMAIL PROTECTED]>
Date: Wed, 06 Jun 2007 19:35:46 -0400
> There is no potential for parallelizing on transmit that i can think of.
> Dave, please explain it slowly so i can understand it.
>
> There is huge potential for parallelizing on receive. But i am certainly
> missing the valu
On Wed, 2007-06-06 at 16:48 -0700, Rick Jones wrote:
> > RX queues - yes, I can see; TX queues, it doesnt make sense to put
> > different rings on different CPUs.
>
> To what extent might that preclude some cachelines bouncing hither and
> yon between the CPUs?
I think the bouncing will exist
From: jamal <[EMAIL PROTECTED]>
Date: Wed, 06 Jun 2007 19:32:46 -0400
> So use a different scheduler. Dont use strict prio. Strict prio will
> guarantee starvation of low prio packets as long as there are high prio
> packets. Thats the intent.
Ok, point taken.
There are of course other uses for
From: jamal <[EMAIL PROTECTED]>
Date: Wed, 06 Jun 2007 19:32:46 -0400
> On Wed, 2007-06-06 at 15:35 -0700, David Miller wrote:
> > With the above for transmit, and having N "struct napi_struct"
> > instances for MSI-X directed RX queues, we'll have no problem keeping
> > a 10gbit (or even faster)
> RX queues - yes, I can see; TX queues, it doesnt make sense to put
different rings on different CPUs.
To what extent might that preclude some cachelines bouncing hither and
yon between the CPUs?
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body o
Hi, Michael. We have some IBM blades with a BCM5708-based dual-port
NIC that the bnx2 driver reports as not supporting wake-on-LAN.
(Ethtool says "Supports Wake-on: d".) However, IBM says that WoL is
supported by these NICs, and in fact when I tried putting the blade
into soft-off and sending a m
On Wed, 2007-06-06 at 15:40 -0700, David Miller wrote:
> There are two core issues in my mind:
>
> 1) multi-queue on both RX and TX is going to be very pervasive very
>soon, everyone is putting this into silicon.
>
>The parallelization gain potential is enormous, and we have to
>des
On Wed, Jun 06, 2007 at 04:14:12PM -0700, Waskiewicz Jr, Peter P wrote:
> > While I am growing in support of your changes, there are two things:
> >
> > 1) I want to study them more and hear more about what Patrick has to
> >say about them when he returns from his trip on Sunday
> >
> > 2) I
On Wed, 06 Jun 2007 13:51:41 -0700 James Ketrenos <[EMAIL PROTECTED]> wrote:
>
> >> * make C=2 CF=-Wall will complain if you use ARRAY_SIZE on global data
> >> */
> >> #define GLOBAL_ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
> >
> > This is identical to ARRAY_SIZE.
> >
> > And if there's some
On Wed, 2007-06-06 at 15:35 -0700, David Miller wrote:
> From: jamal <[EMAIL PROTECTED]>
> Date: Wed, 06 Jun 2007 18:13:40 -0400
> There are other reasons to do interesting things in this area,
> purely for parallelization reasons.
>
> For example, consider a chip that has N totally independant T
Jeff,
You've already appled patch 1/3 in Stephen's series. I tested this one
(2/3) and it looks good. I can resubmit this if you want.
Regards, Ron Mercer
> -Original Message-
> From: Stephen Hemminger [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, May 30, 2007 2:23 PM
> To: Jeff Garzik;
> While I am growing in support of your changes, there are two things:
>
> 1) I want to study them more and hear more about what Patrick has to
>say about them when he returns from his trip on Sunday
>
> 2) I don't want to open up a net-2.6.23 tree yet so that people
>concentrate on bug f
From: "Waskiewicz Jr, Peter P" <[EMAIL PROTECTED]>
Date: Wed, 6 Jun 2007 15:57:35 -0700
> Can we move forward on this please? If you are comfortable
> that my patches give the kernel the ability to manage hardware
> queues sufficiently, I'd like to request that 2.6.23 be opened (wink
> wink
> However, I have to disagree with your analysis of the
> multi-qdisc situation, and I tend to agree with Patrick.
>
> If you only have one qdisc to indicate status on, when is the
> queue full? That is the core issue. Indicating full status
> when any of the hardware queues are full is broke
Andrew Morton wrote:
> i386 allmodconfig isn't that hard, guys.
>
...
> drivers/net/wireless/mac80211/iwlwifi/iwl-4965.c:2050: warning: left shift
> count >= width of type
My mistake. I ran that and even fixed the warning at one point... anyway,
I've committed a patch to our tree to fix the
From: "Waskiewicz Jr, Peter P" <[EMAIL PROTECTED]>
Date: Wed, 6 Jun 2007 15:30:39 -0700
> > [Which of course leads to the complexity (and not optimizing
> > for the common - which is single ring NICs)].
>
> The common for 100 Mbit and older 1Gbit is single ring NICs. Newer
> PCI-X and PCIe NICs
From: jamal <[EMAIL PROTECTED]>
Date: Wed, 06 Jun 2007 18:13:40 -0400
> From the above you can see they are simple. I am working on a couple of
> things (batching and recovering pktgen ipsec patches)- I will work on
> those patches soon after.
>
> Iam actually not against the subqueue control - i
> [Which of course leads to the complexity (and not optimizing
> for the common - which is single ring NICs)].
The common for 100 Mbit and older 1Gbit is single ring NICs. Newer
PCI-X and PCIe NICs from 1Gbit to 10Gbit support multiple rings in the
hardware, and it's all headed in that direction
On Wed, 2007-06-06 at 17:11 +0200, Patrick McHardy wrote:
> I haven't followed the entire discussion, but I still don't see a
> alternative to touching the qdisc layer - multiple hardware queues
> need multiple queue states if you want to avoid a busy hardware
> queue stopping the qdisc entirely
> I don't think we need +1, if you need to fire immediately
> (on the next tick). The timer core will always fire
> timers that are in the past immediately.
Thanks, but is it worth bothering to change it again?
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a m
From: Daniel Lezcano <[EMAIL PROTECTED]>
Date: Wed, 06 Jun 2007 22:38:11 +0200
> Perhaps, a name like "epipe" or "npipe", which reflects what does the
> device, is more appropriate ?
'npipe' (Network PIPE) or 'epipe' (Ethernet PIPE) are fine with me.
-
To unsubscribe from this list: send the lin
David Miller wrote:
From: Pavel Emelianov <[EMAIL PROTECTED]>
Date: Wed, 06 Jun 2007 19:11:38 +0400
Veth stands for Virtual ETHernet. It is a simple tunnel driver
that works at the link layer and looks like a pair of ethernet
devices interconnected with each other.
I would suggest cho
Emmanuel Fusté <[EMAIL PROTECTED]> :
[...]
> Did you plan to submit the "spin_lock_irqsave" patch to mainline ?
No. I will not have enough time to figure why/if it fixes things.
--
Ueimor
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTE
From: Pavel Emelianov <[EMAIL PROTECTED]>
Date: Wed, 06 Jun 2007 19:11:38 +0400
> Veth stands for Virtual ETHernet. It is a simple tunnel driver
> that works at the link layer and looks like a pair of ethernet
> devices interconnected with each other.
I would suggest choosing a different name.
'
On Sun, 2007-06-03 at 11:51 -0400, Jeff Garzik wrote:
> Mithlesh Thukral wrote:
> > NetXen: Correct link status messages.
> > This patch will fix the problem of wrong link status messages
> > that were reported.
> >
> > Signed-off by: Wen Xiong <[EMAIL PROTECTED]>
> > Signed-off by: Mithlesh Thuk
Hello!
> Good point, I didn't think of that. Is there a version of this patch
> that already uses different namespaces so I can look at it?
Pavel does not like the idea. It looks "not exactly pretty", like you said. :-)
The alternative is to create pair in main namespace and then move
one end to
On Monday 04 June 2007 22:25:37 Stephen Hemminger wrote:
> Make the PHY and statistic timer run on one second boundary
> for powersaving.
>
> On resume, the driver should check for link up immediately, to
> get online faster (rather than waiting for the next second).
>
> Signed-off-by: Stephen He
You'll need to resend the patch...
-
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
This patch fixes a possible kernel panic due to not checking the vlan group
when processing received VLAN packets and a malfunction in VLAN/hypervisor
registration.
Signed-off-by: Thomas Klein <[EMAIL PROTECTED]>
---
diff -Nurp -X dontdiff linux-2.6.22-rc4/drivers/net/ehea/ehea.h
patched_kerne
On Wed, 2007-06-06 at 14:05 -0400, Jeff Garzik wrote:
> On Wed, Jun 06, 2007 at 12:52:44PM -0500, wendy xiong wrote:
> > On Sun, 2007-06-03 at 11:50 -0400, Jeff Garzik wrote:
> > > Mithlesh Thukral wrote:
> > > > NetXen: Add NETXEN prefix to a macro
> > > > This patch will add the "NETXEN" prefix t
On Sun, 2007-06-03 at 11:51 -0400, Jeff Garzik wrote:
> Mithlesh Thukral wrote:
> > NetXen: Fix initialization and subsequent ping issue
> > This patch will fix the initialization and ping issues seen on
> > certain PPC architecture blades.
> >
> > Signed-off by: Wen Xiong <[EMAIL PROTECTED]>
> >
On Wed, Jun 06, 2007 at 12:52:44PM -0500, wendy xiong wrote:
> On Sun, 2007-06-03 at 11:50 -0400, Jeff Garzik wrote:
> > Mithlesh Thukral wrote:
> > > NetXen: Add NETXEN prefix to a macro
> > > This patch will add the "NETXEN" prefix to "USER_START" macro.
> > >
> > > Signed-off by: Wen Xiong <[EM
Patrick McHardy <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>>>+if (linkinfo[IFLA_INFO_NAME]) {
>>>+nla_strlcpy(name, linkinfo[IFLA_INFO_NAME], sizeof(name));
>>>+ops = rtnl_link_ops_get(name);
>>
>>
>> Ugh. Shouldn't we have the request_module logic here?
On Sun, 2007-06-03 at 11:50 -0400, Jeff Garzik wrote:
> Mithlesh Thukral wrote:
> > NetXen: Add NETXEN prefix to a macro
> > This patch will add the "NETXEN" prefix to "USER_START" macro.
> >
> > Signed-off by: Wen Xiong <[EMAIL PROTECTED]>
> > Signed-off by: Mithlesh Thukral <[EMAIL PROTECTED]>
>
Patrick McHardy <[EMAIL PROTECTED]> writes:
> Alexey Kuznetsov wrote:
>>> I just suggested to
>>>Pavel to create only a single device per newlink operation and binding
>>>them later,
>>
>>
>> I see some logical inconsistency here.
>>
>> Look, the sec
Eric W. Biederman wrote:
>>+ if (linkinfo[IFLA_INFO_NAME]) {
>>+ nla_strlcpy(name, linkinfo[IFLA_INFO_NAME], sizeof(name));
>>+ ops = rtnl_link_ops_get(name);
>
>
> Ugh. Shouldn't we have the request_module logic here?
> Otherwise it looks like we can skip the validat
> +static int rtnl_newlink(struct sk_buff *skb, struct nlmsghdr *nlh, void *arg)
> +{
> + struct rtnl_link_ops *ops;
> + struct net_device *dev;
> + struct ifinfomsg *ifm;
> + char name[MODULE_NAME_LEN];
> + char ifname[IFNAMSIZ];
> + struct nlattr *tb[IFLA_MAX+1];
> +
Alexey Kuznetsov wrote:
>> I just suggested to
>>Pavel to create only a single device per newlink operation and binding
>>them later,
>
>
> I see some logical inconsistency here.
>
> Look, the second end is supposed to be in another namespace.
> It w
On Wed, 06 Jun 2007 19:11:38 +0400
Pavel Emelianov <[EMAIL PROTECTED]> wrote:
> Veth stands for Virtual ETHernet. It is a simple tunnel driver
> that works at the link layer and looks like a pair of ethernet
> devices interconnected with each other.
>
> Mainly it allows to communicate between net
Eric W. Biederman wrote:
> Patrick McHardy <[EMAIL PROTECTED]> writes:
>
>
>>>I still think adding a IFLA_PARTNER or a custom attribute is cleaner
>>>in this case. Slight semantic mismatches are the worst design bugs
>>>to correct.
>>
>>
>>Indeed, IFLA_PARTNER sounds like a better idea. I just s
Patrick McHardy <[EMAIL PROTECTED]> writes:
>> I still think adding a IFLA_PARTNER or a custom attribute is cleaner
>> in this case. Slight semantic mismatches are the worst design bugs
>> to correct.
>
>
> Indeed, IFLA_PARTNER sounds like a better idea. I just suggested to
> Pavel to create only
Christoph Hellwig wrote:
> On Tue, Jun 05, 2007 at 01:12:03PM -0700, James Ketrenos wrote:
>> Yes, we certainly don't want a driver to be "near mainline" that does
>> things that the rest of the kernel and other drivers are doing. We should
>> force them to stay out-of-tree until any and everyth
Hello!
>I just suggested to
> Pavel to create only a single device per newlink operation and binding
> them later,
I see some logical inconsistency here.
Look, the second end is supposed to be in another namespace.
It will have identity, which cann
Pavel Emelianov wrote:
> +MODULE_DESCRIPTION("Virtual Ethernet Tunnel");
> +MODULE_LICENSE("GPL v2");
This seems to be missing MODULE_ALIAS_RTNL_LINK("veth");
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Eric W. Biederman wrote:
> Patrick McHardy <[EMAIL PROTECTED]> writes:
>
>>You don't really need to patch it, installing a new iplink_XXX.so
>>file is enough. Generalizing driver specific options more than
>>what we currently have doesn't look very promising. I think your
>>driver was simple enoug
Pavel Emelianov wrote:
> Veth stands for Virtual ETHernet. It is a simple tunnel driver
> that works at the link layer and looks like a pair of ethernet
> devices interconnected with each other.
>
> Mainly it allows to communicate between network namespaces but
> it can be used as is as well.
>
>
Patrick McHardy <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>> Reading through the patches they look usable to me.
>>
>> Having to patch iproute to create the more interesting network
>> devices sucks, but that problem seems fundamental. We might
>> be able to avoid it if we allowed f
Pavel Emelianov wrote:
> diff --git a/ip/iplink.c b/ip/iplink.c
> index 5170419..6975990 100644
> --- a/ip/iplink.c
> +++ b/ip/iplink.c
> @@ -287,7 +287,7 @@ static int iplink_modify(int cmd, unsign
>strlen(type));
>
> lu = get_link_type(type);
> -
The usage is
# ip link add [name] type veth [peer ] [mac ] [peer_mac ]
The Makefile is maybe not as beautiful as it could be. It
is to be discussed.
One thing I noticed during testing is the following. When launching
this with link_veth.so module and not specifying any module specific
parameters,
jamal wrote:
> There will be no issue if a) multiple APIs would be allowed for driver
> multi-rings[1] and b) you didnt touch the qdiscs.
>
> Given that #a is not a sensible thing to do since there can only be one
> API and for #b you are not compromising, what do you want me to do?
I haven't f
Veth stands for Virtual ETHernet. It is a simple tunnel driver
that works at the link layer and looks like a pair of ethernet
devices interconnected with each other.
Mainly it allows to communicate between network namespaces but
it can be used as is as well.
Eric recently sent a similar driver ca
> "Geert" == Geert Uytterhoeven <[EMAIL PROTECTED]> writes:
Geert> acenic: SET_NETDEV_DEV is always there these days
Geert> Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
Signed-off-by: Jes Sorensen <[EMAIL PROTECTED]>
Geert> --- Disclaimer: not tested at all
Geert> --- a/drivers/ne
acenic: SET_NETDEV_DEV is always there these days
Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
---
Disclaimer: not tested at all
--- a/drivers/net/acenic.c
+++ b/drivers/net/acenic.c
@@ -159,10 +159,6 @@ static struct pci_device_id acenic_pci_t
};
MODULE_DEVICE_TABLE(pci, acenic_pci_t
Folks,
While Krishna and I have been attempting this on the side, progress has
been rather slow - so this is to solicit for more participation so we
can get this over with faster. Success (myself being conservative when
it comes to performance) requires testing on a wide variety of hardware.
The
Patrick McHardy wrote:
> The following patches contain the rtnetlink link creation API I promised,
> as well as two simple driver conversion to use the API as an example.
> I've also converted VLAN as a more complex example, but these patches
> need some more work and are most likely not interestin
>> This may be ok on a major interface like eth0 but it is a problem when
>> using a ppp interface via GSM data or GPRS connection.
>> Killing the pppd while the socket waits in read() produces the same
>> behaviour. Also a broken connection looks the same.
>> It is reproducable on several 2.6 kern
Eric W. Biederman wrote:
> Reading through the patches they look usable to me.
>
> Having to patch iproute to create the more interesting network
> devices sucks, but that problem seems fundamental. We might
> be able to avoid it if we allowed fields to be reused between
> different types of devi
Stephen Hemminger wrote:
> On Wed, 06 Jun 2007 01:17:11 +0200
> Patrick McHardy <[EMAIL PROTECTED]> wrote:
>
>>>If you want I'll extend existing bridge netlink to use these.
>>
>>
>>Are you talking about brige-port information or bridge device
>>configuration? So far the API is not suitable for an
Urs Thuermann wrote:
> Patrick McHardy <[EMAIL PROTECTED]> writes:
>
>>I don't get why you can't directly check the socket option on the
>>TX path.
>
>
> We have several types of sockets in the PF_CAN family, two of which
> are GPL'ed and which are in the patch series. These are CAN_RAW and
> C
He seems to be the same guy who has dropped the patches from RHEL5 bugzilla
for now.
--
Mithlesh Thukral
On Tuesday 05 June 2007 00:28, Andy Gospodarek wrote:
> On Sun, Jun 03, 2007 at 11:50:29AM -0400, Jeff Garzik wrote:
> > Mithlesh Thukral wrote:
> > >NetXen: Add NETXEN prefix to a macro
> >
Hi,
I have a user space program which "connects" to different kernel
modules with generic netlink. Each module provides its own generic
netlink family.
For each module to "connect" to I create a socket and bind it:
fd = socket(AF_NETLINK, SOCK_RAW, NETLINK_GENERIC);
struct sockaddr_nl addr;
m
On Jun 5, 2007, at 9:26 PM, Kok, Auke wrote:
Kok, Auke wrote:
Hmm git-revert seems to do the job right. I checked it with git-show
| patch -p1 -R and the results look OK. The two patches on top of the
one we want to revert are unrelated enough to apply (manually it
shows some fuzz, but oth
From: Miklos Szeredi <[EMAIL PROTECTED]>
Date: Wed, 06 Jun 2007 10:08:29 +0200
> > > > Holding a global mutex over recvmsg() calls under AF_UNIX is pretty
> > > > much a non-starter, this will kill performance for multi-threaded
> > > > apps.
> > >
> > > That's an rwsem held for read. It's held
> > > Holding a global mutex over recvmsg() calls under AF_UNIX is pretty
> > > much a non-starter, this will kill performance for multi-threaded
> > > apps.
> >
> > That's an rwsem held for read. It's held for write in unix_gc() only
> > for a short duration, and unix_gc() should only rarely be
Anton wrote:
> Hi,
>
> Following on from a previous (now lost :-)) posting, I have been trying
> to send out IPv6 packets from a kernel module using the kern_sendmsg()
> function. Since in theory I need this function to be started in
> interrupt context (actually, softirq context), but since th
On Tue, Jun 05 2007, Evgeniy Polyakov wrote:
> On Tue, Jun 05, 2007 at 10:05:43AM +0200, Jens Axboe ([EMAIL PROTECTED])
> wrote:
> > Here's an implementation of tcp network splice receive support. It's
> > originally based on the patch set that Intel posted some time ago, but
> > has been (close t
On Tue, Jun 05, 2007 at 01:12:03PM -0700, James Ketrenos wrote:
> Yes, we certainly don't want a driver to be "near mainline" that does
> things that the rest of the kernel and other drivers are doing. We should
> force them to stay out-of-tree until any and everything is resolved.
> Heaven fo
On Tue, Jun 05 2007, jamal wrote:
> On Tue, 2007-05-06 at 14:20 +0200, Jens Axboe wrote:
>
> > >
> > > 1800 4ff3 937f e000 6381 7275 0008
> > >
> > > Perhaps that hex pattern rings a bell with someone intimate with the
> > > networking. The remaining wrong bytes don't seem to have anything
http://bugzilla.kernel.org/show_bug.cgi?id=8160
Signed-off-by: Dave Jones <[EMAIL PROTECTED]>
diff --git a/drivers/net/via-velocity.c b/drivers/net/via-velocity.c
index 25b75b6..b670b97 100644
--- a/drivers/net/via-velocity.c
+++ b/drivers/net/via-velocity.c
@@ -1562,7 +1562,7 @@ static void velo
scc_rxint doesn't call this function at all.
http://bugzilla.kernel.org/show_bug.cgi?id=8146
Signed-off-by: Dave Jones <[EMAIL PROTECTED]>
diff --git a/drivers/net/hamradio/scc.c b/drivers/net/hamradio/scc.c
index 6fdaad5..30bed2a 100644
--- a/drivers/net/hamradio/scc.c
+++ b/drivers/net/hamradio
83 matches
Mail list logo
