Bill Fink wrote:
On Thu, 01 Mar 2007, Ben Greear wrote:
Ben Greear wrote:
I am sending udp packets through ppp400, and I see them appear on ppp401
as expected.
The thing that is bothering me is that all I see on rddVR4 (172.1.2.1)
is arps for 172.1.2.2, but the 'tell' IP is that of the
David Miller wrote:
From: Andi Kleen <[EMAIL PROTECTED]>
Date: 03 Mar 2007 03:14:29 +0100
That's pretty common with many x86 server boards because
they come with two NICs by default but must people only
plug the cable into one. However the distro installers
run DHCP on all.
Nope, tha
On Fri, Mar 02, 2007 at 09:59:05PM -0800, David Miller wrote:
>
> So it's still a mystery why dhcp is causing bridge devices
> to trigger the network tap paths on Stephen's machine.
If this is the ISC DHCP daemon then perhaps it's because Stephen
didn't specify an interface for it to listen on? B
From: Baruch Even <[EMAIL PROTECTED]>
Date: Thu, 1 Mar 2007 20:13:40 +0200
> If you take this approach it makes sense to also remove the sorting of
> SACKs, the traversal of the SACK blocks will not start from the
> beginning anyway which was the reason for this sorting in the first
> place.
>
>
On Thu, 01 Mar 2007, Ben Greear wrote:
> Ben Greear wrote:
>
> I am sending udp packets through ppp400, and I see them appear on ppp401
> as expected.
>
> The thing that is bothering me is that all I see on rddVR4 (172.1.2.1)
> is arps for 172.1.2.2, but the 'tell' IP is that of the
> originat
> This sounds like something that will always be wrong -- or in other
> words, always be right for only the latest CPUs. Can this be made
> dynamic, based on some timing factor?
In fact I think this has been tweaked twice in the vanilla tree
already.
This is actually just the same tweak you re
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Sat, 03 Mar 2007 16:38:45 +1100
> This is using packet_bind_spkt which uses a name instead of ifindex.
So it should be just fine, it should be binding to a specific
device (by name instead of ifindex) and therefore it should
only trigger the pt_all hook
David Miller <[EMAIL PROTECTED]> wrote:
>
> I'm tempted to say I must be missing something here, since I can't see
> how this could possible work at all. The string passed in should
> be interpreted as the ifindex value, and thus trigger a -ENODEV
> return from AF_PACKET's bind() implementation.
From: Jeff Garzik <[EMAIL PROTECTED]>
Date: Fri, 02 Mar 2007 22:14:39 -0500
> Chris Leech wrote:
> > Every 20 descriptors turns out to be to few append commands with
> > newer/faster CPUs. Pushing every 4 still cuts down on MMIO writes to an
> > acceptable level without letting the DMA engine run
From: Andi Kleen <[EMAIL PROTECTED]>
Date: 03 Mar 2007 03:14:29 +0100
> That's pretty common with many x86 server boards because
> they come with two NICs by default but must people only
> plug the cable into one. However the distro installers
> run DHCP on all.
Nope, that's not what I've seen t
Chris Leech wrote:
Every 20 descriptors turns out to be to few append commands with
newer/faster CPUs. Pushing every 4 still cuts down on MMIO writes to an
acceptable level without letting the DMA engine run out of work.
Signed-off-by: Chris Leech <[EMAIL PROTECTED]>
---
drivers/dma/ioatdma.c
On Fri, Mar 02, 2007 at 08:33:55PM -0500, Jeff Garzik wrote:
> YOSHIFUJI Hideaki / wrote:
> >Signed-off-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
> >---
> > drivers/usb/net/dm9601.c |4
> > 1 files changed, 4 insertions(+), 0 deletions(-)
> >
> >diff --git a/drivers/usb/net/dm9
net/ipv4/tcp.c: In function 'tcp_recvmsg':
net/ipv4/tcp.c:: warning: unused variable 'available'
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Chris Leech <[EMAIL PROTECTED]>
---
net/ipv4/tcp.c | 26 --
1 files changed, 16 insertions(+), 10 deletio
Signed-off-by: Chris Leech <[EMAIL PROTECTED]>
---
Documentation/networking/ip-sysctl.txt |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/Documentation/networking/ip-sysctl.txt
b/Documentation/networking/ip-sysctl.txt
index d3aae1f..9541691 100644
--- a/Documentatio
Signed-off-by: Chris Leech <[EMAIL PROTECTED]>
---
MAINTAINERS | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 1dfba85..2dd5d23 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1156,6 +1156,12 @@ M: [EMAIL PROTECTED]
L:
The performance wins come with having the DMA copy engine doing the copies
in parallel with the context switch. If there is enough data ready on the
socket at recv time just use a regular copy.
Signed-off-by: Chris Leech <[EMAIL PROTECTED]>
---
net/ipv4/tcp.c | 10 +++---
1 files changed,
Every 20 descriptors turns out to be to few append commands with
newer/faster CPUs. Pushing every 4 still cuts down on MMIO writes to an
acceptable level without letting the DMA engine run out of work.
Signed-off-by: Chris Leech <[EMAIL PROTECTED]>
---
drivers/dma/ioatdma.c |4 ++--
1 files
Signed-off-by: Chris Leech <[EMAIL PROTECTED]>
---
drivers/dma/ioatdma.c| 60 +++
drivers/dma/ioatdma_io.h | 118 --
2 files changed, 28 insertions(+), 150 deletions(-)
diff --git a/drivers/dma/ioatdma.c b/drivers/dma/ioatdma
From: Jeff Garzik <[EMAIL PROTECTED]>
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
Signed-off-by: Chris Leech <[EMAIL PROTECTED]>
---
drivers/dma/dmaengine.c | 22 --
1 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dma
Under kexec, I/OAT initialization breaks over busy resources because the
previous kernel did not release them.
I'm not sure this fix can be considered a complete one but it works for me.
I guess something similar to the *_remove method should occur there..
Signed-off-by: Dan Aloni <[EMAIL PROTEC
There's only one now anyway, and it's not in a performance path,
so make it behave the same on 32-bit and 64-bit CPUs.
Signed-off-by: Chris Leech <[EMAIL PROTECTED]>
---
drivers/dma/ioatdma.c | 10 --
1 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/dma/ioatdma.c
Andrew Morton (1):
I/OAT: warning fix
Chris Leech (6):
ioatdma: Push pending transactions to hardware more frequently
ioatdma: Remove the wrappers around read(bwl)/write(bwl) in ioatdma
ioatdma: Remove the use of writeq from the ioatdma driver
I/OAT: Add documentation for
Jan-Bernd Themann <[EMAIL PROTECTED]> writes:
>
> Are there any concerns about this approach?
Yes. You should fix the NAPI code instead of trying to work
around it.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majord
Jay Vosburgh wrote:
Jeff Garzik <[EMAIL PROTECTED]> wrote:
Jay Vosburgh wrote:
The ARP validation code only needs ARPs for the bonding device.
Signed-off-by: Jay Vosburgh <[EMAIL PROTECTED]>
I seem to have lost the context of this. Did this get discussed, and
need further revision?
Jeff Garzik <[EMAIL PROTECTED]> wrote:
>Jay Vosburgh wrote:
>> The ARP validation code only needs ARPs for the bonding device.
>>
>> Signed-off-by: Jay Vosburgh <[EMAIL PROTECTED]>
>
>I seem to have lost the context of this. Did this get discussed, and
>need further revision?
The
Fixes du jour.
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-linus
to receive the following updates:
arch/mips/jmr3927/rbhma3100/setup.c |4 -
arch/mips/momentum/jaguar_atx/platform.c| 20 +---
arch/mi
YOSHIFUJI Hideaki / 吉藤英明 wrote:
Signed-off-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
---
drivers/usb/net/dm9601.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/net/dm9601.c b/drivers/usb/net/dm9601.c
index 4a932e1..c0bc52b 100644
--- a/drivers/usb/net/dm
Stephen Hemminger <[EMAIL PROTECTED]> writes:
> Here is another way to handle the 64 bit divide case.
> It allows full 64 bit divide by adding the support routine
> GCC needs.
Not supplying that was intentional by Linus so that people
think twice (or more often) before they using such expensive
o
Here is the current version of the 64 bit divide common code.
Since it is used by three times by networking code, can we put it net-2.6.22
tree?
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
include/asm-arm/div64.h |2 ++
include/asm-generic/div64.h |7 +++
include/
Jay Vosburgh wrote:
The ARP validation code only needs ARPs for the bonding device.
Signed-off-by: Jay Vosburgh <[EMAIL PROTECTED]>
I seem to have lost the context of this. Did this get discussed, and
need further revision?
The three patches from 2/28/2007 look OK to me, and I just
John W. Linville wrote:
From: Johannes Berg <[EMAIL PROTECTED]>
Since wext is being replaced as fast as we can (it'll probably stick
around for legacy drivers though) and the wext/netlink stuff was never
really used, this schedules it for removal.
The removal schedule is tight but there are no
Shan Lu wrote:
Changelog:
Function `phy_mii_ioctl' returns physical device's information based on
user requests. When requested to return the basic mode control register
information (BMCR), the original implementation only returns the
physical device's duplex information and forgets to return spe
Florian Fainelli <[EMAIL PROTECTED]> writes:
> Hi All,
>
> I have been talking a bit with Richard, who is the LED API maintainer, and a
> LED trigger based on network activity would be something great.
You should be aware that normally the kernel doesn't see all packets
on a ethernet unless pro
Dale Farnsworth wrote:
We were using the platform_device.id field to identify which ethernet
port is used for mv643xx_eth device. This is not generally correct.
It will be incorrect, for example, if a hardware platform uses a single
port but not the first port. Here, we add an explicit port_num
Ron Mercer wrote:
From 01751a39d7327acc28dabf4f68930b7e20b279d1 Mon Sep 17 00:00:00 2001
From: Ron Mercer <[EMAIL PROTECTED]>
Date: Wed, 28 Feb 2007 16:42:17 -0800
Subject: [PATCH] [PATCH] qla3xxx: bugfix for line omitted in previous patch.
This missing line caused transmit errors on the Qlogic
Dale Farnsworth wrote:
The information contained within platform_data should be self-contained.
Replace the pointer to a MAC address with the actual MAC address in
struct mv643xx_eth_platform_data.
Signed-off-by: Dale Farnsworth <[EMAIL PROTECTED]>
---
Replaced explicit mac address comparison
David Miller <[EMAIL PROTECTED]> writes:
>
> And in fact that effectively makes the new socket option
> pointless, since it doesn't buy us anything since we have
> to support the old stuff fully anyways.
I don't think it's pointless because it would still allow
newer DHCP clients to have less imp
Atsushi Nemoto wrote:
Current tc35815 driver is very obsolete and less maintained for a long
time. Replace it with a new driver based on one from CELF patch
archive. It was for 2.6.10 kernel so some adjustment and cleanup are
added. (remove config.h, SA_ to IRQF_ conversion, etc.)
Major advant
Ralf Baechle wrote:
From: Ladislav Michl <[EMAIL PROTECTED]>
Thanks to Jö Fahlke for donating hardware.
Signed-off-by: Ladislav Michl <[EMAIL PROTECTED]>
Forward porting of Ladis' 2.4 patch.
Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]>
applied to #upstream (2.6.22)
-
To unsubscribe fro
Jan-Bernd Themann wrote:
This patch introduces functionality to dynamically add / remove
ehea ports via an userspace DLPAR tool. It creates a subnode for
each logical port in the sysfs.
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
applied 1-2 to #upstream (2.6.22)
your patches adde
Linsys Contractor Mithlesh Thukral wrote:
NetXen: Make driver use multi PCI functions.
Signed-off by: Mithlesh Thukral <[EMAIL PROTECTED]>
---
netxen_nic.h | 126 +---
netxen_nic_ethtool.c | 80 +++
netxen_nic_hdr.h |8
netxen_nic_hw.c | 213 +
Linsys Contractor Mithlesh Thukral wrote:
NetXen: Updates, removal of unsupported features and minor bug fixes.
Signed-off-by: Mithlesh Thukral <[EMAIL PROTECTED]>
---
netxen_nic.h |4 +
netxen_nic_ethtool.c | 144 +-
netxen_nic_ma
On Fri, 02 Mar 2007 19:43:34 -0500
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Gary Zambrano wrote:
> > Added dma_sync_single_range_for_cpu/device to dma-mapping.h in asm-arm &
> > asm-avr32 to call dma_sync_single_for_cpu/device. This patch enables b44
> > to compile on systems with these cpus.
> >
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Fri, 2 Mar 2007 16:47:19 -0800
> Resend with less garbage...
>
> The udp code is full of bad indenting, extra whitespace and other
> style confusion. It makes no sense to declare functions that are used
> outside the current file (extern) as inli
Resend with less garbage...
The udp code is full of bad indenting, extra whitespace and other
style confusion. It makes no sense to declare functions that are used
outside the current file (extern) as inline.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
net/ipv4/udp.c | 312 +++
Gary Zambrano wrote:
Added dma_sync_single_range_for_cpu/device to dma-mapping.h in asm-arm &
asm-avr32 to call dma_sync_single_for_cpu/device. This patch enables b44
to compile on systems with these cpus.
This patch was created with the assumption that another method of
dma_sync_single_range_for
On 3/2/07, Stephen Hemminger <[EMAIL PROTECTED]> wrote:
On Fri, 2 Mar 2007 15:56:54 -0500
"Ritesh Kumar" <[EMAIL PROTECTED]> wrote:
> On 3/2/07, Patrick McHardy <[EMAIL PROTECTED]> wrote:
> > Ritesh Kumar wrote:
> > > Hi,
> > >I recently saw the qdisc "tfifo" in the netem module
> > > (net/s
From: Robert Olsson <[EMAIL PROTECTED]>
Date: Wed, 28 Feb 2007 18:07:09 +0100
> Yes it seems be handle dev name change. So configuration scripts should
> use ifindex now :)
>
> Signed-off-by: Robert Olsson <[EMAIL PROTECTED]>
I will apply all 4 of these patches to net-2.6.22, thanks everyone.
-
From: James Morris <[EMAIL PROTECTED]>
Date: Tue, 27 Feb 2007 16:24:49 -0500 (EST)
> Where appropriate, convert references to xtime.tv_sec to the
> get_seconds() helper function.
>
> Signed-off-by: James Morris <[EMAIL PROTECTED]>
This looks great James, I'll apply it to net-2.6.2 once I set
tha
I plan to cut a net-2.6.22 tree after I finish pushing the
current round of 2.6.21 networking bug fixes to Linus.
I'll load the tcp-2.6 tree changes into net-2.6.22, and then
we'll do all non-bug-fix development in the net-2.6.22 tree.
It may take some time for me to push out the bug fixes for t
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Fri, 2 Mar 2007 14:04:49 -0800
>
> The udp code is full of bad indenting, extra whitespace and other
> style confusion. It makes no sense to declare functions that are used
> outside the current file (extern) as inline.
>
> Signed-off-by: Stephe
From: Krzysztof Halasa <[EMAIL PROTECTED]>
Date: Sat, 03 Mar 2007 00:38:05 +0100
> Switching HDLC devices from Ethernet-framing mode caused stale ethernet
> function assignments within net_device.
>
> Signed-off-by: Krzysztof Halasa <[EMAIL PROTECTED]>
This looks good to me, I think I'll apply i
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Fri, 2 Mar 2007 15:34:14 -0800
> Can you get FC fixed?
I am not the DHCP package maintainer. :-)
I'm up to my earfulls already dealing with people trying
to slug broken patches into the kernel networking that paper
around application bugs. ;)
>
David Miller <[EMAIL PROTECTED]> writes:
> I disagree, you can't leave dangling references to functions
> which are potentially inside of unloaded modules, as this code
> does.
All such pointers were thought to be initialized by all HDLC protocol
handlers before device activation, but they were a
Switching HDLC devices from Ethernet-framing mode caused stale ethernet
function assignments within net_device.
Signed-off-by: Krzysztof Halasa <[EMAIL PROTECTED]>
diff --git a/drivers/net/wan/hdlc.c b/drivers/net/wan/hdlc.c
index db354e0..f6e6b63 100644
--- a/drivers/net/wan/hdlc.c
+++ b/drivers
On Fri, 02 Mar 2007 15:18:03 -0800 (PST)
David Miller <[EMAIL PROTECTED]> wrote:
> From: David Miller <[EMAIL PROTECTED]>
> Date: Fri, 02 Mar 2007 14:48:18 -0800 (PST)
>
> > Back to a workable solution, why doesn't DHCP specify a specific
> > device? It would fix this performance problem complet
From: David Miller <[EMAIL PROTECTED]>
Date: Fri, 02 Mar 2007 14:48:18 -0800 (PST)
> Back to a workable solution, why doesn't DHCP specify a specific
> device? It would fix this performance problem completely, at the
> application level.
Since nobody seems to be able to be bothered to actually l
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Fri, 2 Mar 2007 14:09:29 -0800
> On Fri, 02 Mar 2007 13:26:38 -0800 (PST)
> David Miller <[EMAIL PROTECTED]> wrote:
>
> > From: Stephen Hemminger <[EMAIL PROTECTED]>
> > Date: Wed, 28 Feb 2007 17:18:46 -0800
> >
> > > I was measuring bridging/rou
Stephen Hemminger a écrit :
On Fri, 2 Mar 2007 15:38:41 +0100
Eric Dumazet <[EMAIL PROTECTED]> wrote:
We currently use a special structure (struct skb_timeval) and plain 'struct
timeval' to store packet timestamps in sk_buffs and struct sock.
This has some drawbacks :
- Fixed resolution of mi
On Fri, 02 Mar 2007 13:26:38 -0800 (PST)
David Miller <[EMAIL PROTECTED]> wrote:
> From: Stephen Hemminger <[EMAIL PROTECTED]>
> Date: Wed, 28 Feb 2007 17:18:46 -0800
>
> > I was measuring bridging/routing performance and noticed this.
> >
> > The current code runs the "all packet" type handlers
On Fri, 02 Mar 2007 13:26:38 -0800 (PST)
David Miller <[EMAIL PROTECTED]> wrote:
> From: Stephen Hemminger <[EMAIL PROTECTED]>
> Date: Wed, 28 Feb 2007 17:18:46 -0800
>
> > I was measuring bridging/routing performance and noticed this.
> >
> > The current code runs the "all packet" type handlers
Part of the next set of bridge patches includes this.
It allows packet capture by interface on a bridge:
tcpdump -i eth0
will work as expected.
@@ -128,34 +125,45 @@ static inline int is_link_local(const un
int br_handle_frame(struct net_bridge_port *p, struct sk_buff **pskb)
{
Don't use mm after its freed in iwch_mmap().
Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/cxgb3/iwch_provider.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/iwch_provider.c
b/drivers/infiniband/hw/cxgb3
The udp code is full of bad indenting, extra whitespace and other
style confusion. It makes no sense to declare functions that are used
outside the current file (extern) as inline.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
net/ipv4/udp.c | 402 ---
From: Dan Aloni <[EMAIL PROTECTED]>
Date: Thu, 1 Mar 2007 12:02:17 +0200
> This patch splits the vlan_group struct into a multi-allocated struct. On
> x86_64, the size of the original struct is a little more than 32KB, causing
> a 4-order allocation, which is prune to problems caused by buddy-syst
From: John Heffner <[EMAIL PROTECTED]>
Date: Fri, 02 Mar 2007 16:16:39 -0500
> Please don't apply the patch I sent. I've been thinking about this a
> bit harder, and it may not fix this particular problem. (Hard to say
> without knowing exactly what it is.) As the comment above
> __tcp_selec
From: "Ilpo_Järvinen" <[EMAIL PROTECTED]>
Date: Fri, 2 Mar 2007 14:34:36 +0200 (EET)
> Undoing ssthresh is disabled in fastretrans_alert whenever
> FLAG_ECE is set by clearing prior_ssthresh. The clearing does
> not protect FRTO because FRTO operates before fastretrans_alert.
> Moving the clearing
From: "Ilpo_Järvinen" <[EMAIL PROTECTED]>
Date: Thu, 1 Mar 2007 22:26:57 +0200 (EET)
> I think that doing it in the response is better that this approach,
> since it knows that the ssthresh has been halved already within that
> round-trip, so there is no need to do that again... I'll submit the
>
From: "Ilpo_Järvinen" <[EMAIL PROTECTED]>
Date: Thu, 1 Mar 2007 13:30:20 +0200 (EET)
> [PATCH] [TCP]: Complete icsk-to-local-variable change (in tcp_enter_cwr)
>
> A local variable for icsk was created but this change was
> missing. Spotted by Jarek Poplawski.
>
> Signed-off-by: Ilpo Järvinen <[
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Wed, 28 Feb 2007 17:18:46 -0800
> I was measuring bridging/routing performance and noticed this.
>
> The current code runs the "all packet" type handlers before calling the
> bridge hook. If an application (like some DHCP clients) is using AF_PAC
From: Ben Greear <[EMAIL PROTECTED]>
Date: Wed, 28 Feb 2007 15:25:59 -0800
> Hopefully, by attaching it as a file it will not screw up the tabs & spaces.
>
> Signed-off-by: Ben Greear <[EMAIL PROTECTED]>
Nope still doesn't apply.
I can guess that you didn't try emailing the patch to yourself a
From: James Morris <[EMAIL PROTECTED]>
Date: Wed, 28 Feb 2007 15:45:07 -0500 (EST)
> On Wed, 28 Feb 2007, Paul Moore wrote:
>
> > The current CIPSO engine has a problem where it does not verify that the
> > given
> > sensitivity level has a valid CIPSO mapping when the "std" CIPSO DOI type is
>
From: Florian Zumbiehl <[EMAIL PROTECTED]>
Date: Wed, 28 Feb 2007 13:38:44 +0100
> As noone seems to have an opinion on this: Here is a patch that does
> work for me and that should solve the problem as far as that is easily
> possible. It is based on the assumption that an interface's ifindex is
David Miller wrote:
From: Alex Sidorenko <[EMAIL PROTECTED]>
Date: Fri, 2 Mar 2007 15:21:58 -0500
they told us that they use small rcvbuf to throttle bandwidth for this
application. I explained it would be better to use TC for this purpose. They
agreed and will probably redesign their applicat
On Fri, 2 Mar 2007 15:56:54 -0500
"Ritesh Kumar" <[EMAIL PROTECTED]> wrote:
> On 3/2/07, Patrick McHardy <[EMAIL PROTECTED]> wrote:
> > Ritesh Kumar wrote:
> > > Hi,
> > >I recently saw the qdisc "tfifo" in the netem module
> > > (net/sched/sch_netem.c) when I migrated some of my patches from
On Fri, 2 Mar 2007 15:38:41 +0100
Eric Dumazet <[EMAIL PROTECTED]> wrote:
> We currently use a special structure (struct skb_timeval) and plain 'struct
> timeval' to store packet timestamps in sk_buffs and struct sock.
>
> This has some drawbacks :
> - Fixed resolution of micro second.
> - Waste
On 3/2/07, Patrick McHardy <[EMAIL PROTECTED]> wrote:
Ritesh Kumar wrote:
> Hi,
>I recently saw the qdisc "tfifo" in the netem module
> (net/sched/sch_netem.c) when I migrated some of my patches from 2.6.14
> to 2.6.20. As I understand, tfifo helps in keeping the queue of
> packets sorted acc
"Andy Gospodarek" <[EMAIL PROTECTED]> writes:
>
> Any chance you can boot back to the old kernel (the one where is was
> working) and run and ethtool -i eth0 on that one to see what version of
> the driver was used there? It's hard to know what may have changed
> between the 2 versions of the dri
From: weidong <[EMAIL PROTECTED]>
Date: Wed, 14 Feb 2007 11:30:57 -0500
> diff -ruN old/include/net/sock.h new/include/net/sock.h
> --- old/include/net/sock.h2007-02-03 08:38:21.0 -0500
> +++ new/include/net/sock.h2007-02-03 08:38:30.0 -0500
> @@ -426,7 +426,7 @@
>
> sta
On 3/2/07, Eric Dumazet <[EMAIL PROTECTED]> wrote:
Thank you for this report. (Still avoiding cache misses studies, while they
obviously are the limiting factor)
1) The entire point of going to a tree-like structure would be to
allow the leaves to age out of cache (or even forcibly evict them)
From: Alex Sidorenko <[EMAIL PROTECTED]>
Date: Fri, 2 Mar 2007 15:21:58 -0500
> they told us that they use small rcvbuf to throttle bandwidth for this
> application. I explained it would be better to use TC for this purpose. They
> agreed and will probably redesign their application in the futur
On March 2, 2007 01:54:45 pm John Heffner wrote:
> Alex Sidorenko wrote:
> [snip]
>
> > --- net/ipv4/tcp_output.c.orig Wed May 3 20:40:43 2006
> > +++ net/ipv4/tcp_output.c Tue Jan 30 14:24:56 2007
> > @@ -641,6 +641,7 @@
> > * Note, we don't "adjust" for TIMESTAMP or SACK option bytes.
>
On Thu, Mar 01, 2007 at 06:27:18PM -0500, Marc D Ronell wrote:
> Thats correct. Its the wired interface, eth0 which is having the
> problem. I have turned the wireless interface, eth2 off with both
> ifconfig and ifdown, and still, the connection to the outside only
> works when tcpdump is running
On March 2, 2007 02:25:42 pm David Miller wrote:
> From: Alex Sidorenko <[EMAIL PROTECTED]>
> Date: Fri, 2 Mar 2007 11:28:28 -0500
>
> > Customer has confirmed that this resolves the problem and decreases
> > CPU usage by his custom application - even when there is no SWS.
>
> There is rarely ever
Inside pfkey_delete and xfrm_del_sa the audit hooks were not called if
there was any permission/security failures in attempting to do the del
operation (such as permission denied from security_xfrm_state_delete).
This patch moves the audit hook to the exit path such that all failures
(and successes
On Fri, 02 Mar 2007 10:29:53 -0800
Ben Greear <[EMAIL PROTECTED]> wrote:
> Pekka Savola wrote:
> > On Thu, 1 Mar 2007, Stephen Hemminger wrote:
> >> What about implementing the unused arp_announce flag on the inetdevice?
> >> Something like the following. Totally untested...
> >>
> >> Looks like
Ritesh Kumar wrote:
> Hi,
>I recently saw the qdisc "tfifo" in the netem module
> (net/sched/sch_netem.c) when I migrated some of my patches from 2.6.14
> to 2.6.20. As I understand, tfifo helps in keeping the queue of
> packets sorted according to their "time_to_send". [tfifo was not
> present
From: Alex Sidorenko <[EMAIL PROTECTED]>
Date: Fri, 2 Mar 2007 11:28:28 -0500
> Customer has confirmed that this resolves the problem and decreases
> CPU usage by his custom application - even when there is no SWS.
There is rarely ever a reason to set explicit socket receive
buffer sizes, since t
From: Paul Moore <[EMAIL PROTECTED]>
Date: Fri, 2 Mar 2007 11:12:12 -0500
> On Wednesday, February 28 2007 3:01:31 pm Paul Moore wrote:
> > The current CIPSO engine has a problem where it does not verify that the
> > given sensitivity level has a valid CIPSO mapping when the "std" CIPSO DOI
> > ty
From: Krzysztof Halasa <[EMAIL PROTECTED]>
Date: Fri, 02 Mar 2007 16:29:06 +0100
> Andrew Morton <[EMAIL PROTECTED]> writes:
>
> >> However, in
> >> drivers/net/wan/hdlc_cisco.c, in function static int cisco_ioctl(struct
> >> net_device *dev, struct ifreq *ifr), where dev->hard_header is assign
Hi,
I recently saw the qdisc "tfifo" in the netem module
(net/sched/sch_netem.c) when I migrated some of my patches from 2.6.14
to 2.6.20. As I understand, tfifo helps in keeping the queue of
packets sorted according to their "time_to_send". [tfifo was not
present in 2.6.14 perhaps because arri
Alex Sidorenko wrote:
[snip]
--- net/ipv4/tcp_output.c.orig Wed May 3 20:40:43 2006
+++ net/ipv4/tcp_output.c Tue Jan 30 14:24:56 2007
@@ -641,6 +641,7 @@
* Note, we don't "adjust" for TIMESTAMP or SACK option bytes.
* Regular options like TIMESTAMP are taken into account.
*/
+stati
pfkey_spdget neither had an LSM security hook nor auditing for the
removal of xfrm_policy structs. The security hook was added when it was
moved into xfrm_policy_byid instead of the callers to that function by
my earlier patch and this patch adds the auditing hooks as well.
Signed-off-by: Eric Pa
The security hooks to check permissions to remove an xfrm_policy were
actually done after the policy was removed. Since the unlinking and
deletion are done in xfrm_policy_by* functions this moves the hooks
inside those 2 functions. There we have all the information needed to
do the security check
Pekka Savola wrote:
On Thu, 1 Mar 2007, Stephen Hemminger wrote:
What about implementing the unused arp_announce flag on the inetdevice?
Something like the following. Totally untested...
Looks like it either was there (and got removed) or was planned but
never implemented.
IN_DEV_ARP_ANNOUNCE
Changelog:
Function `phy_mii_ioctl' returns physical device's information based on
user requests. When requested to return the basic mode control register
information (BMCR), the original implementation only returns the
physical device's duplex information and forgets to return speed
information, w
On Fri, 2007-03-02 at 12:11 +0100, Johannes Berg wrote:
> On Fri, 2007-03-02 at 03:06 -0800, Andrew Morton wrote:
> > s390 is weird ;) There's no way it'll support any of the hardware which
> > you're
> > working on (until they release the s390 laptop). So all we really want to
> > do here is t
On Fri 2.3.2007 00:34, Linas Vepstas wrote:
> On Thu, Mar 01, 2007 at 04:52:54PM -0600, Chris Engel wrote:
> > I tried to apply this patch to 2.6.21-rc2 and CHECKSUM_HW appears
> > to be changed to CHECKSUM_COMPLETE
Oops. I did not test this on the actual 2.6.21-rc2 before sending it.
It worked fi
Hello,
this is a rare corner case met by one of HP partners on 2.4.20 on IA64.
Inspecting the sources of the latest 2.6.20.1 (net/ipv4/tcp_output.c) we can
see that the bug is still there.
Here is a description of the bug and the suggested fix.
The problem occurs when the remote host (not nece
On Fri, 2 Mar 2007 15:38:41 +0100
Eric Dumazet <[EMAIL PROTECTED]> wrote:
> We currently use a special structure (struct skb_timeval) and plain 'struct
> timeval' to store packet timestamps in sk_buffs and struct sock.
>
> This has some drawbacks :
> - Fixed resolution of micro second.
> - Waste
1 - 100 of 135 matches
Mail list logo
