On Fri, Jun 08 2007, Evgeniy Polyakov wrote:
> On Fri, Jun 08, 2007 at 06:57:25PM +0400, Evgeniy Polyakov ([EMAIL
> PROTECTED]) wrote:
> > I will try some things for the nearest 30-60 minutes, and then will move to
> > canoe trip until thuesday, so will not be able to work on this idea.
>
> Ok, r
Stephen Hemminger wrote:
On Fri, 08 Jun 2007 16:42:31 -0700
"Kok, Auke" <[EMAIL PROTECTED]> wrote:
Stephen Hemminger wrote:
+#define ndev_printk(kern_level, netif_level, netdev, format, arg...) \
+ do { if ((netdev)->msg_enable & NETIF_MSG_##netif_level) { \
+ printk(kern
Stephen Hemminger wrote:
On Fri, 08 Jun 2007 16:42:31 -0700
"Kok, Auke" <[EMAIL PROTECTED]> wrote:
Stephen Hemminger wrote:
+#define ndev_printk(kern_level, netif_level, netdev, format, arg...) \
+ do { if ((netdev)->msg_enable & NETIF_MSG_##netif_level) { \
+ printk(kern
From: [EMAIL PROTECTED]
Date: Sat, 09 Jun 2007 04:08:15 +0300
> These 2 patches are bug fixes and should thus be considered for net-2.6
> inclusion.
Both patches applied, thanks Sam.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
From: Trond Myklebust <[EMAIL PROTECTED]>
Date: Fri, 08 Jun 2007 17:43:27 -0400
> It is not dhcp. I'm seeing the same bug with bog-standard ifup with a
> static address on an FC-6 machine.
>
> It appears to be something in the latest dump from davem to Linus, but I
> haven't yet had time to ident
Please cc networking patches to [EMAIL PROTECTED]
Jeff Layton <[EMAIL PROTECTED]> wrote:
>
> The following patch is a first stab at removing this need. It makes it
> so that in tcp_recvmsg() we also check kthread_should_stop() at any
> point where we currently check to see if the task was signall
On Sat, Jun 09, 2007 at 11:20:43AM +1000, Herbert Xu wrote:
> Chris Wright <[EMAIL PROTECTED]> wrote:
> >
> > --- linux-2.6.20.13.orig/net/ipv4/Kconfig
> > +++ linux-2.6.20.13/net/ipv4/Kconfig
> > @@ -43,11 +43,11 @@ config IP_ADVANCED_ROUTER
> > asymmetric routing (packets from you to a
Chris Wright <[EMAIL PROTECTED]> wrote:
>
> --- linux-2.6.20.13.orig/net/ipv4/Kconfig
> +++ linux-2.6.20.13/net/ipv4/Kconfig
> @@ -43,11 +43,11 @@ config IP_ADVANCED_ROUTER
> asymmetric routing (packets from you to a host take a different path
> than packets from that host to you
Hi, Stephen
We are doing pure IPv4 forwarding between two Ethernet
interfaces:
IXIA port A<--->System Under Test<--->IXIA Port B
Traffic has two IP destinations for each direction and
L4 protocol is UDP. There are two static ARP entries
and only interface routes. Two tests are identical
except
Trond Myklebust <[EMAIL PROTECTED]> wrote:
>
> It appears to be something in the latest dump from davem to Linus, but I
> haven't yet had time to identify what.
You want this patch which should hit the tree soon.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~}
Jean II was right: you have to re-charge the final timer when resending
rejected frames. Otherwise it triggers at a wrong time and can break the
currently running communication. Reproducible under rt-preempt.
Signed-off-by: G. Liakhovetski <[EMAIL PROTECTED]>
Signed-off-by: Samuel Ortiz <[EMAIL
Hi Dave,
These 2 patches are bug fixes and should thus be considered for net-2.6
inclusion.
Cheers,
Samuel.
-
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
From: G. Liakhovetski <[EMAIL PROTECTED]>
We need to switch to NRM _before_ sending the final packet otherwise we might
hit a race condition where we get the first packet from the peer while we're
still in LAP_XMIT_P.
Cc: G. Liakhovetski <[EMAIL PROTECTED]>
Signed-off-by: Samuel Ortiz <[EMAIL P
Peter,
Where is your git tree located?
Ram
> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
> On Behalf Of Waskiewicz Jr, Peter P
> Sent: Thursday, June 07, 2007 3:56 PM
> To: David Miller; [EMAIL PROTECTED]
> Cc: Kok, Auke-jan H; [EMAIL PROTECTED]; [EMAIL PROTECT
jamal wrote:
On Fri, 2007-08-06 at 10:27 -0700, Rick Jones wrote:
[..]
you cannot take the netperf service demand directly - each netperf is
calculating assuming that it is the only thing running on the system.
It then ass-u-me-s that the CPU util it measured was all for its work.
This mean
On Fri, 2007-08-06 at 12:55 -0700, Waskiewicz Jr, Peter P wrote:
> > I thought the correct use is to get this lock on clean_tx
> > side which can get called on a different cpu on rx (which
> > also cleans up slots for skbs that have finished xmit). Both
> > TX and clean_tx uses the same tx_ring'
On Fri, 2007-08-06 at 10:27 -0700, Rick Jones wrote:
[..]
> you cannot take the netperf service demand directly - each netperf is
> calculating assuming that it is the only thing running on the system.
> It then ass-u-me-s that the CPU util it measured was all for its work.
> This means the se
On Fri, 08 Jun 2007 16:42:31 -0700
"Kok, Auke" <[EMAIL PROTECTED]> wrote:
> Stephen Hemminger wrote:
> >>
> >> +#define ndev_printk(kern_level, netif_level, netdev, format, arg...) \
> >> + do { if ((netdev)->msg_enable & NETIF_MSG_##netif_level) { \
> >> + printk(kern_level "%s: " for
This should also be useful with the pending 'veth' driver, as it
emulates two ethernet ports connected with a cross-over cable.
To make this work, you have to enable the sysctl (look Dave,
no IOCTLS, there might be hope for me yet!! :)), and in your
application you will need to use SO_BINDTODEVIC
Carl-Daniel Hailfinger wrote:
On 08.06.2007 19:00, Ben Greear wrote:
I have another sysfs patch that allows setting a default skb->mark for
an interface so that you can set the skb->mark
before it hits the connection tracking logic, but I'm been told this one
has very little chance
of getting in
Stephen Hemminger wrote:
+#define ndev_printk(kern_level, netif_level, netdev, format, arg...) \
+ do { if ((netdev)->msg_enable & NETIF_MSG_##netif_level) { \
+ printk(kern_level "%s: " format, \
+ (netdev)->name, ## arg); } } while (0)
Could you make a vers
On Fri, 8 Jun 2007 13:41:55 -0700 (PDT)
Philip Romanov <[EMAIL PROTECTED]> wrote:
> Hello!
>
> We are observing severe IPv4 forwarding degradation
> when switching from sk98lin to sky2 driver. Setup:
> plain 2.6.21.3 kernel, 88E8053 Marvell Yukon2 MAC,
> sk98lin is @revision 8.41.2.3 coming fr
>
> +#define ndev_printk(kern_level, netif_level, netdev, format, arg...) \
> + do { if ((netdev)->msg_enable & NETIF_MSG_##netif_level) { \
> + printk(kern_level "%s: " format, \
> + (netdev)->name, ## arg); } } while (0)
Could you make a version that doesn't evalua
A lot of netdevices implement their own variant of printk and use
use variations of dev_printk, printk or others that use msg_enable,
which has been an eyesore with countless variations across drivers.
This patch implements a standard ndev_printk and derivatives
such as ndev_err, ndev_info, ndev_w
With the generic ndev_printk macros, we can now convert network
drivers to use this generic printk family for netdevices.
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
drivers/net/e100.c| 121 +++--
drivers/net/e1000/e1000.h | 15 -
On Fri, 2007-06-08 at 23:07 +0200, Arkadiusz Miskiewicz wrote:
> On Friday 08 of June 2007, you wrote:
> > Hello,
> >
> > I am using the current git tree: 85f6038f2170e3335dda09c3dfb0f83110e87019 .
> > Git tree from two days ago (with the same config) works fine.
> >
> > Attempting to acquire an IP
On Fri, Jun 08, 2007 at 09:07:47AM -0400, jamal ([EMAIL PROTECTED]) wrote:
> > Something, that anyone can understand :)
> > For example /proc stats, although it is not very accurate, but it is
> > really usable parameter from userspace point ov view.
>
> which /proc stats?
/proc/$pid/stat, for pk
Hello!
We are observing severe IPv4 forwarding degradation
when switching from sk98lin to sky2 driver. Setup:
plain 2.6.21.3 kernel, 88E8053 Marvell Yukon2 MAC,
sk98lin is @revision 8.41.2.3 coming from FC6, SKY2
driver from 2.6.21.3 kernel, both drivers are in NAPI
mode.
Benchmarks are done
> I thought the correct use is to get this lock on clean_tx
> side which can get called on a different cpu on rx (which
> also cleans up slots for skbs that have finished xmit). Both
> TX and clean_tx uses the same tx_ring's head/tail ptrs and
> should be exclusive. But I don't find clean tx us
Hey all-
ip_vs currently fails to reset its ip_vs_sync_state variable if the sync
thread fails to start properly. The result is that the kernel will report a
running daemon when their actuall is none. If you issue the following commands:
1. ipvsadm --start-daemon master --mcast-interface
On 08.06.2007 19:00, Ben Greear wrote:
> I have another sysfs patch that allows setting a default skb->mark for
> an interface so that you can set the skb->mark
> before it hits the connection tracking logic, but I'm been told this one
> has very little chance
> of getting into the kernel. The skb
On Fri, 8 Jun 2007 10:30:53 -0400
"Ed L. Cashin" <[EMAIL PROTECTED]> wrote:
> Here is a patch against the netdev-2.6 git tree that makes the net DMA
> feature usable for drivers like the ATA over Ethernet block driver,
> which can use dma_skb_copy_datagram_iovec when receiving data from the
> netw
Currently, ibmveth maintains several rx buffer pools, which can
be modified through sysfs. By default, pools are not allocated by
default such that jumbo frames cannot be supported without first
activating larger rx buffer pools. This results in failures when attempting
to change the mtu. This pat
When attempting to activate additional rx buffer pools on an ibmveth interface
that
was not yet up, the error below was seen. The patch fixes this by only closing
and opening the interface to activate the resize if the interface is already
opened.
(drivers/net/ibmveth.c:597 ua:3004) ERROR: h
Also note something else strange that it is kind of strange that
something like UDP which doesnt backoff will send out less
packets/second ;->
Cannot explain that either :)
Perhaps delays in restarting after the intra-stack flow control is
asserted. One possible thing to do to try to deal w
On Thu, 2007-06-07 at 04:28 -0700, Mithlesh Thukral wrote:
> Hi All,
>
> I will be sending bug fixes related to initialization, link status and
> some compile issues of NetXen's 1/10G Ethernet driver in subsequent
> mails.
> These patches are wrt netdev#upstream-fixes.
>
> Regards,
> Mithlesh T
These results are based on the test script that I sent earlier today. I
removed the results for UDP 32 procs 512 and 4096 buffer cases since
the BW was coming >line speed (infact it was showing 1500Mb/s and
4900Mb/s respectively for both the ORG and these bits).
I expect UDP to overwhelm the r
On Fri, Jun 08, 2007 at 12:06:08PM -0500, Linas Vepstas wrote:
> On Fri, Jun 08, 2007 at 11:12:31AM +1000, Michael Ellerman wrote:
> > On Thu, 2007-06-07 at 14:17 -0500, Linas Vepstas wrote:
> > > Jeff, please apply for the 2.6.23 kernel tree. The pach series
> > > consists of two major bugfixes,
On Fri, Jun 08, 2007 at 11:12:31AM +1000, Michael Ellerman wrote:
> On Thu, 2007-06-07 at 14:17 -0500, Linas Vepstas wrote:
> > Jeff, please apply for the 2.6.23 kernel tree. The pach series
> > consists of two major bugfixes, and several bits of cleanup.
> >
> > The major bug fixes are:
> >
>
Already sent this to several lists, but forgot netdev ;-)...
This one's sort of outside my normal area of expertise so sending this
as an RFC to gather feedback on the idea.
Some background:
The cifs_mount() and cifs_umount() functions currently send a signal to
the cifsd kthread prior to callin
Pavel Emelianov wrote:
Ben Greear wrote:
[snip]
I would also like some way to identify veth from other device types,
preferably
something like a value in sysfs. However, that should not hold up
We can do this with ethtool. It can get and print the driver name of
the device.
Ben Greear wrote:
[snip]
>>> I would also like some way to identify veth from other device types,
>>> preferably
>>> something like a value in sysfs. However, that should not hold up
>>>
>>
>> We can do this with ethtool. It can get and print the driver name of
>> the device.
>>
> I thi
On Fri, Jun 08, 2007 at 06:57:25PM +0400, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
> I will try some things for the nearest 30-60 minutes, and then will move to
> canoe trip until thuesday, so will not be able to work on this idea.
Ok, replacing in fs/splice.c every page_cache_release() with
s
On Fri, Jun 08 2007, Evgeniy Polyakov wrote:
> On Fri, Jun 08, 2007 at 04:14:52PM +0200, Jens Axboe ([EMAIL PROTECTED])
> wrote:
> > Here's a start, for the splice side at least of storing a buf-private
> > entity with the ops.
>
> :) I tested the same implementation, but I put skb pointer into
>
On Fri, Jun 08, 2007 at 04:14:52PM +0200, Jens Axboe ([EMAIL PROTECTED]) wrote:
> Here's a start, for the splice side at least of storing a buf-private
> entity with the ops.
:) I tested the same implementation, but I put skb pointer into
page->private. My approach is not correct, since the same p
Here is a patch against the netdev-2.6 git tree that makes the net DMA
feature usable for drivers like the ATA over Ethernet block driver,
which can use dma_skb_copy_datagram_iovec when receiving data from the
network.
The change was suggested on kernelnewbies.
http://article.gmane.org/gmane.li
On Fri, Jun 08 2007, Evgeniy Polyakov wrote:
> On Fri, Jun 08, 2007 at 11:04:40AM +0200, Jens Axboe ([EMAIL PROTECTED])
> wrote:
> > OK, so a delayed empty of the pipe could end up causing packet drops
> > elsewhere due to allocation exhaustion?
>
> Yes.
>
> > > > We can grow the pipe, should we
On Fri, Jun 08, 2007 at 11:04:40AM +0200, Jens Axboe ([EMAIL PROTECTED]) wrote:
> OK, so a delayed empty of the pipe could end up causing packet drops
> elsewhere due to allocation exhaustion?
Yes.
> > > We can grow the pipe, should we have to. So instead of blocking waiting
> > > on reader consu
On Fri, 2007-08-06 at 22:37 +1000, Herbert Xu wrote:
> Hmm I wasn't describing how it works now. I'm talking about how it
> would work if we removed LLTX and replaced the private tx_lock with
> netif_tx_lock.
I got that - it is what tg3 does for example.
To mimick that behavior in LLTX, a driver
On Fri, 2007-08-06 at 16:09 +0400, Evgeniy Polyakov wrote:
> On Fri, Jun 08, 2007 at 07:31:07AM -0400, jamal ([EMAIL PROTECTED]) wrote:
> But lock is still being hold - or there was no intention to reduce lock
> usage? As far as I read Krishna's mail, lock usage was not an issue, so
> that hunk p
On Fri, Jun 08, 2007 at 07:34:57AM -0400, jamal wrote:
> On Fri, 2007-08-06 at 20:39 +1000, Herbert Xu wrote:
>
> > It would guard against the poll routine which would acquire this lock
> > when cleaning the TX ring.
>
> Ok, then i suppose we can conclude it is a bug on e1000 (holds tx_lock
> on
On Fri, Jun 08, 2007 at 07:31:07AM -0400, jamal ([EMAIL PROTECTED]) wrote:
> On Fri, 2007-08-06 at 12:38 +0400, Evgeniy Polyakov wrote:
> > On Thu, Jun 07, 2007 at 06:23:16PM -0400, jamal ([EMAIL PROTECTED]) wrote:
>
> > > I believe both are called with no lock. The idea is to avoid the lock
> > >
KK,
On Fri, 2007-08-06 at 17:01 +0530, Krishna Kumar2 wrote:
> I thought it comes to 1.147Mpps, or did I calculate wrong
> (70*1024*1024/8/8) ?
I assumed 8B to mean data that is on top of TCP/UDP?
If so then in the case of UDP we have 8B UDP header, 20B IP and 14B
ethernet < 64B minimal allowed
On Fri, 2007-08-06 at 20:39 +1000, Herbert Xu wrote:
> It would guard against the poll routine which would acquire this lock
> when cleaning the TX ring.
Ok, then i suppose we can conclude it is a bug on e1000 (holds tx_lock
on tx side and adapter queue lock on rx). Adding that lock will
certainl
Baruch Even wrote:
Herbert Xu wrote:
On Fri, Jun 08, 2007 at 02:02:27PM +0300, Baruch Even wrote:
As far as IGMP and multicast handling everything works, the packets
are even forwarded over the ppp links but they arrive to the client
with a bad checksum. I don't have the trace in front of me b
Hi Jamal,
J Hadi Salim <[EMAIL PROTECTED]> wrote on 06/08/2007 04:44:06 PM:
> That should be fine as long as the sender is running the patched
> 2.6.22-rc4
Definitely :)
> Thats interesting - it is possible there is transient burstiness which
> fills up the ring.
> My observation of your result
On Fri, 2007-08-06 at 12:38 +0400, Evgeniy Polyakov wrote:
> On Thu, Jun 07, 2007 at 06:23:16PM -0400, jamal ([EMAIL PROTECTED]) wrote:
> > I believe both are called with no lock. The idea is to avoid the lock
> > entirely when unneeded. That code may end up finding that the packet
[..]
> + ne
Herbert Xu wrote:
On Fri, Jun 08, 2007 at 02:02:27PM +0300, Baruch Even wrote:
As far as IGMP and multicast handling everything works, the packets are
even forwarded over the ppp links but they arrive to the client with a
bad checksum. I don't have the trace in front of me but I believe it was
KK,
On Fri, 2007-08-06 at 10:36 +0530, Krishna Kumar2 wrote:
> I will try that. Also on the receiver, I am using unmodified 2.6.21 bits.
That should be fine as long as the sender is running the patched
2.6.22-rc4
> My earlier experiments showed that even small buffers were filling the
> E1000
>
On Fri, Jun 08, 2007 at 02:02:27PM +0300, Baruch Even wrote:
>
> As far as IGMP and multicast handling everything works, the packets are
> even forwarded over the ppp links but they arrive to the client with a
> bad checksum. I don't have the trace in front of me but I believe it was
> the UDP
Herbert Xu wrote:
Baruch Even <[EMAIL PROTECTED]> wrote:
I have a machine on which I have an applications that sends multicast
through eth interface with hardware tx checksum enabled. On the same
machine I have mrouted running that routes the multicast traffic to a
set of ppp interfaces. The p
On Thu, Jun 07, 2007 at 09:35:36PM -0400, jamal wrote:
> On Thu, 2007-07-06 at 17:31 -0700, Sridhar Samudrala wrote:
>
> > If the QDISC_RUNNING flag guarantees that only one CPU can call
> > dev->hard_start_xmit(), then why do we need to hold netif_tx_lock
> > for non-LLTX drivers?
>
> I havent s
On Thu, Jun 07, 2007 at 06:23:16PM -0400, jamal ([EMAIL PROTECTED]) wrote:
> On Thu, 2007-07-06 at 20:13 +0400, Evgeniy Polyakov wrote:
>
> > Actually I wonder where the devil lives, but I do not see how that
> > patchset can improve sending situation.
> > Let me clarify: there are two possibiliti
On Fri, Jun 08 2007, Evgeniy Polyakov wrote:
> On Fri, Jun 08, 2007 at 10:38:53AM +0200, Jens Axboe ([EMAIL PROTECTED])
> wrote:
> > On Fri, Jun 08 2007, David Miller wrote:
> > > From: Jens Axboe <[EMAIL PROTECTED]>
> > > Date: Fri, 8 Jun 2007 09:48:24 +0200
> > >
> > > > Perhaps it's possible t
On Fri, Jun 08, 2007 at 10:38:53AM +0200, Jens Axboe ([EMAIL PROTECTED]) wrote:
> On Fri, Jun 08 2007, David Miller wrote:
> > From: Jens Axboe <[EMAIL PROTECTED]>
> > Date: Fri, 8 Jun 2007 09:48:24 +0200
> >
> > > Perhaps it's possible to solve this at a different level - can we hang
> > > on to
On Fri, Jun 08 2007, David Miller wrote:
> From: Jens Axboe <[EMAIL PROTECTED]>
> Date: Fri, 8 Jun 2007 09:48:24 +0200
>
> > Perhaps it's possible to solve this at a different level - can we hang
> > on to the skb until the pipe buffer has been consumed, and prevent reuse
> > that way? Then we don
From: Jens Axboe <[EMAIL PROTECTED]>
Date: Fri, 8 Jun 2007 09:48:24 +0200
> Perhaps it's possible to solve this at a different level - can we hang
> on to the skb until the pipe buffer has been consumed, and prevent reuse
> that way? Then we don't have to care what backing the skb has, as long
> a
On Thu, Jun 07 2007, Evgeniy Polyakov wrote:
> On Thu, Jun 07, 2007 at 12:51:59PM +0200, Jens Axboe ([EMAIL PROTECTED])
> wrote:
> > > What bout checking if page belongs to kmalloc cache (or any other cache
> > > via priviate pointers) and do not perform any kind of reference counting
> > > on the
68 matches
Mail list logo
