On Mon, 04 Jun 2007 14:00:56 -0400 [EMAIL PROTECTED] wrote:
On Wed, 30 May 2007 23:58:23 PDT, Andrew Morton said:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc3/2.6.22-rc3-mm1/
Under 22-rc2-mm1, if my VPN connection got reset, ppp0 just quietly went away.
Under
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
+++
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
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 in
common.
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 to) 100%
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 forbid
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 this is
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 called. So
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 for write in
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
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;
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
This
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
CAN_BCM. The
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 anything that
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 devices
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 interesting
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
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,
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/net/acenic.c +++
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
The usage is
# ip link add [name] type veth [peer name] [mac mac] [peer_mac 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
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);
- if
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 fields to be
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.
Eric
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 enough to get
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
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 cannot
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 a single
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 everything is
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 suggested to
Pavel
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 network
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 will have
+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];
+ struct
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 validate method
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 second end is supposed
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:
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
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 [EMAIL PROTECTED]
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]
Signed-off by:
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 to USER_START
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
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
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
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 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 Thukral [EMAIL
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.
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 PROTECTED]
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
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 line
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
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
If
[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,
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 know
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
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 broken,
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) so I
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 fixes
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;
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 TX
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 problem with
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
design
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 don't want
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
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 of
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) port
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
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 a lot
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 value in
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: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 cachelines bouncing
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.
And if there's some
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]
---
diff -Nurp -X
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 the data they
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_ARRAY_SIZE(x)
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 came
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
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. So I'm
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
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 feature or can
79 matches
Mail list logo
