On 05/12/2016 02:19 PM, Cong Wang wrote:
On Thu, May 12, 2016 at 1:05 PM, Chris Friesen wrote:
I hope this is a simple question...with legacy naming ethernet devices are
named ethX. Where is that X determined? I've been looking in
alloc_netdev_mqs() and friends, but haven't fo
Hi,
I hope this is a simple question...with legacy naming ethernet devices are named
ethX. Where is that X determined? I've been looking in alloc_netdev_mqs() and
friends, but haven't found it yet.
Thanks,
Chris
t the CMSG info is correct.
Sample dhcp_release command line:
dhcp_release eth1 192.168.204.222 02:11:33:22:44:66
Signed-off-by: Allain Legacy
Signed off-by: Chris Friesen
---
net/ipv4/route.c | 12
1 file changed, 12 insertions(+)
diff --git a/net/ipv4/route.c b/net/ipv
On 04/08/2016 01:14 PM, Julian Anastasov wrote:
Your patch is corrupted. I was in the same trap
some time ago but with different client:
From Documentation/email-clients.txt:
Don't send patches with "format=flowed". This can cause unexpected
and unwanted line breaks.
Anyways
t the CMSG info is correct.
Sample dhcp_release command line:
dhcp_release eth1 192.168.204.222 02:11:33:22:44:66
Signed-off-by: Allain Legacy
Signed off-by: Chris Friesen
---
net/ipv4/route.c | 12
1 file changed, 12 insertions(+)
diff --git a/net/ipv4/route.c b/net/ipv
s that the CMSG info is correct.
Sample dhcp_release command line:
dhcp_release eth1 192.168.204.222 02:11:33:22:44:66
Signed-off-by: Allain Legacy
Signed off-by: Chris Friesen
---
net/ipv4/route.c | 12
1 file changed, 12 insertions(+)
diff --git a/net/ipv4/route.c b/net/ipv
On 04/07/2016 03:20 PM, Julian Anastasov wrote:
On Thu, 7 Apr 2016, Chris Friesen wrote:
Hi,
We think we may have found a bug in the handling of ipv4 route caching,
and are curious what you think.
For local routes that require a particular output interface we do not
want to cache the result
rface (e.g., lo). The packet
will still appear on the loopback interface in tcpdump but the important
aspect is that the CMSG info is correct.
For what it's worth, here's a patch that we've applied locally to deal
with the issue.
Chris
Signed-off-by: Allain Legacy
Signed-off-by: Ch
Eric Dumazet wrote:
Chris Friesen a écrit :
I've done some further digging, and it appears that one of the
problems we may be facing is very high instantaneous traffic rates.
Instrumentation showed up to 222K packets/sec for short periods (at
least 1.1 ms, possibly longer), althoug
Ben Greear wrote:
Chris Friesen wrote:
Is there anything else we can do to minimize the latency of network
packet processing and avoid having to crank the rx ring size up so high?
Why is it such a big deal to crank up the rx queue length? Seems like
a perfectly normal way to handle bursts
I've done some further digging, and it appears that one of the problems
we may be facing is very high instantaneous traffic rates.
Instrumentation showed up to 222K packets/sec for short periods (at
least 1.1 ms, possibly longer), although the long-term average is down
around 14-16K packets/se
Radoslaw Szkodzinski (AstralStorm) wrote:
On Tue, 15 Jan 2008 08:47:07 -0600
"Chris Friesen" <[EMAIL PROTECTED]> wrote:
Some of our hardware is not supported on mainline, so we need per-kernel
version patches to even bring up the blade. The blades netboot via a
jumbo-f
Jarek Poplawski wrote:
IMHO, checking this with a current stable, which probably you are going
to do some day, anyway, should be 100% acceptable: giving some input to
netdev, while still working for yourself.
While I would love to do this, it's not that simple.
Some of our hardware is not sup
Eric Dumazet wrote:
Chris Friesen a écrit :
Based on the profiling information we're spending time in
sctp_endpoint_lookup_assoc() which doesn't actually use hashes, so I
can't see how the hash would be related. I'm pretty new to SCTP
though, so I may be missing someth
Eric Dumazet wrote:
Chris Friesen a écrit :
Based on profiling and instrumentation it seems like the cost of
sctp_endpoint_lookup_assoc() more than triples, which means that the
amount of time that bottom halves are disabled in that function also
triples.
Any idea of the size of sctp hash
David Miller wrote:
From: "Chris Friesen" <[EMAIL PROTECTED]>
Date: Fri, 11 Jan 2008 08:59:26 -0600
I'd love to work on newer kernels, but we have a commitment to our
customers to support multiple releases for a significant amount of time.
And by asking here for peop
Ray Lee wrote:
On Jan 10, 2008 9:24 AM, Chris Friesen <[EMAIL PROTECTED]> wrote:
After a recent userspace app change, we've started seeing packets being
dropped by the ethernet hardware (e1000, NAPI is enabled). The
error/dropped/fifo counts are going up in ethtool:
Can you r
David Miller wrote:
You have to be kidding, coming here for help with a nearly
4 year old kernel.
I figured it couldn't hurt to ask...if I can't ask the original authors,
who else is there?
I'd love to work on newer kernels, but we have a commitment to our
customers to support multiple rel
James Chapman wrote:
What's changed in your application? Any real-time threads in there?
From the top output below, looks like SigtranServices is consuming all
your CPU...
There are two cpus, and SigtranServices is multithreaded with many
threads. Most of these threads are affined to cpu0
Kok, Auke wrote:
You're using 2.6.10... you can always replace the e1000 module with the
out-of-tree version from e1000.sf.net, this might help a bit - the version in
the
2.6.10 kernel is very very old.
Do you have any reason to believe this would improve things? It seems
like the problem l
Hi all,
I've got an issue that's popped up with a deployed system running
2.6.10. I'm looking for some help figuring out why incoming network
packets aren't being processed fast enough.
After a recent userspace app change, we've started seeing packets being
dropped by the ethernet hardware
Herbert Xu wrote:
Chris Friesen <[EMAIL PROTECTED]> wrote:
However, if I specifically try to print out one of the missing entries,
it shows up:
[EMAIL PROTECTED]:/root> /tmp/ip neigh show 192.168.24.81
192.168.24.81 dev bond2 lladdr 00:01:af:14:e9:8a REACHABLE
What about
Patrick McHardy wrote:
From a kernel perspective there are only complete dumps, the
filtering is done by iproute. So the fact that it shows them
when querying specifically implies there is a bug in the
iproute neighbour filter. Does it work if you omit "all"
from the ip neigh show command?
Om
YOSHIFUJI Hideaki / 吉藤英明 wrote:
In article <[EMAIL PROTECTED]> (at Wed, 12 Dec 2007
15:57:08 -0600), "Chris Friesen" <[EMAIL PROTECTED]> says:
You may try other versions of this command
http://devresources.linux-foundation.org/dev/iproute2/download/
They appear to
Eric Dumazet wrote:
And what is the version of "ip" command you have on this machine ?
ip -V
iproute2-ss051107
You may try other versions of this command
http://devresources.linux-foundation.org/dev/iproute2/download/
They appear to be numbered by kernel version, and the above version is
Eric Dumazet wrote:
Chris Friesen a écrit :
Is this expected behaviour?
Probably not... Still a 2.6.14 kernel ?
Yep. Embedded hardware, so I'm unable to test with a more recent kernel.
Could you send the result of :
strace ip neigh show
I've attached two strace runs, one of
I retested it on an x86 machine and am seeing similar problems.
First, "arp" gives the arp table as expected:
[EMAIL PROTECTED]:/tftpboot/cnp/0-0-5-0/0-0-5-0> arp -n
Address HWtype HWaddress Flags Mask
Iface
172.24.0.9 ether 00:03:CC:51:06:5E C
Chris Friesen wrote:
I'm seeing some strange behaviour on a 2.6.14 ppc64 system. If I run
"ip neigh show" it prints out nothing, but if I run "arp" then I see the
other nodes on the local network.
[EMAIL PROTECTED]:/root> ip neigh show
[EMAIL PROT
I'm seeing some strange behaviour on a 2.6.14 ppc64 system. If I run
"ip neigh show" it prints out nothing, but if I run "arp" then I see the
other nodes on the local network.
[EMAIL PROTECTED]:/root> ip neigh show
[EMAIL PROTECTED]:/root> arp -n
Address HWtype HWaddress
We have a network with a number of nodes using bonding with arp
monitoring. The arp interval is set to 100ms.
Unfortunately, the bonding code sends the arp packets to the hardware
broadcast address, which means that the number of these arp packets seen
by each node goes up with the number o
David Miller wrote:
When you select VLAN, you by definition are asking for non-VLAN
traffic to be elided. It is like plugging the ethernet cable
into one switch or another.
For max functionality it seems like the raw eth device should show
everything on the wire in promiscuous mode.
If we
Stephen Hemminger wrote:
Maybe TIPC can't handle fragmented receive buffers. The sky2 driver
generates skb's with header and multiple pages if MTU is big enough.
For 9K MTU that would be 1K of data + 2 4K pages. The protocols are
supposed to be smart enough to handle this, but TIPC is rarely u
Hi,
We're using Yukon-XL (0xb3) rev 3 hardware with a vendor-supplied
2.6.14. BAsed on suggestions here, I backported the sky2 driver (v1.10
from 2.6.20.6) to 2.6.14.
Unfortunately, when I booted this I got the following:
skb_over_panic: text:d00d4e14 len:60 put:60
head:c0026
Jeff Garzik wrote:
The sk98lin driver is going away, please don't use it.
It's unmaintained and full of known bugs.
Okay...so it looks like the proper driver for the Marvell Yukon 88E8062
is the sky2 driver, and this one does avoid order>0 allocations. Am I
on track?
Chris
-
To unsubscri
Stephen Hemminger wrote:
Adding fragmentation support to skge driver is on my list of
possible extensions. sky2 driver already supports it (yet one
more feature that the vendor sk98lin driver doesn't do).
Thanks for speaking up. As I mentioned in my email to Jeff it looks
like the sky2 drive
Hi all,
We're considering some hardware that uses the sk98lin network hardware,
and we'll be using jumbo frames. Looking at the driver, when using a
9KB MTU it seems like it would end up trying to atomically allocate a
16KB buffer.
Has anyone heard of this been a problem? It would seem li
Linus Torvalds wrote:
- in other words, the *only* possible meaning for "volatile" is a purely
single-CPU meaning. And if you only have a single CPU involved in the
process, the "volatile" is by definition pointless (because even
without a volatile, the compiler is required to make t
Herbert Xu wrote:
But I have to say that I still don't know of a single place
where one would actually use the volatile variant.
Given that many of the existing users do currently have "volatile", are
you comfortable simply removing that behaviour from them? Are you sure
that you will not i
Segher Boessenkool wrote:
Anyway, what's the supposed advantage of *(volatile *) vs. using
a real volatile object? That you can access that same object in
a non-volatile way?
That's my understanding. That way accesses where you don't care about
volatility may be optimised.
For instance, i
David Miller wrote:
It used unsigned long ages ago, and ifconfig gets the bits
exported from /proc/net/dev output whereas we have to used
fixed data types in whatever we use over netlink so u32
was choosen.
It's rather ironic that the "new-and-improved" way of doing things is
subject to rollo
Vlad Yasevich wrote:
If by arp spoofing you mean receiving arp replies from multiple sources and
trusting all of them, then I haven't seen anything.
I don't know the history as to why nothing has has been done.
This concept is a valuable tool to allow for fast publishing of IP
address takeov
Chris Leech wrote:
Just to give you an idea of our motivation around this, we're looking
at layer 2 configuration protocols implemented from user space.
I'd like to second the intent of this patch. We've been maintaining a
patch against 2.6.10 for a while now that exports the original ingres
Chris Friesen wrote:
It behaved fairly well with standard networking, but its behaving
strangely with bonding added to the mix.
Thanks to everyone for the suggestions and help.
It turns out it was actually a driver problem that was more easily
manifested by the timing of the way bonding
Chris Friesen wrote:
No joy on the 2.6.14 backport, so I guess I'll try the RHEL4 route.
Bonding driver from 2.6.9-42.0.8.EL doesn't help at all, at least with
the module parms I was using before.
Switching to miimon doesn't help either.
Chris
-
To unsubscribe from this
Chris Friesen wrote:
Andy Gospodarek wrote:
If you are looking for a decent source for patches you could consider
downloading the latest source-rpm from RHEL4/CentOS4. The bonding
driver in those releases have been updated to much later code and I can
tell you from personal experience they
Andy Gospodarek wrote:
If you are looking for a decent source for patches you could consider
downloading the latest source-rpm from RHEL4/CentOS4. The bonding
driver in those releases have been updated to much later code and I can
tell you from personal experience they work pretty well. You ma
Jay Vosburgh wrote:
2.6.10 is pretty old, and there have been a number of fixes to
the bonding ARP monitor since then, so it may be that it is simply
misbehaving (presuming that you're running the 2.6.10 bonding driver).
Are you in a position to test against a more recent kernel (and/or
Andy Gospodarek wrote:
Can you elaborate on what isn't going well with this driver/hardware?
I have a ppc64 blade running a customized 2.6.10. At init time, two of
our gigE links (eth4 and eth5) are bonded together to form bond0. This
link has an MTU of 9000, and uses arp monitoring. We'
o the mix.
Could someone either point me to the bonding high level design document
(couldn't find one at the sourceforge project page) or else give me a
quick overview of the code path followed by an incoming packet when
bonding is involved?
Thanks,
Chris Friesen
-
To unsubscribe from
Stephen Hemminger wrote:
+arp_notify - BOOLEAN
+ Define mode for notification of address and device changes.
+ 0 - (default): do nothing
+ 1 - Generate gratuitous arp replies when device is brought up
+ or hardware address changes.
Did you consider using gratuitous
Herbert Xu wrote:
Chris Friesen <[EMAIL PROTECTED]> wrote:
Looking at the page-splitting code, it says "82571 and greater support
packet-split...". We're running the 82546GB device. Looks like it
won't help me.
Well, time to fork out for a new card then :)
I
Evgeniy Polyakov wrote:
It definitely will.
Packet split in hardware means separating data and headers into
different pages in different reads, while software page split means that
skb has a list of fragments where part of the packet will be DMAed, so
jumbo frame will be converted into several
Herbert Xu wrote:
Either upgrade your kernel or backport the page-splitting code in the
current tree. That's really the only sane solution for jumbo packets.
Looking at the page-splitting code, it says "82571 and greater support
packet-split...". We're running the 82546GB device. Looks lik
I'm running a system with multiple e1000 devices, using 9KB jumbo
frames. I'm running a modified 2.6.10 with e1000 driver 5.5.4-k2.
I'm a bit concerned about the behaviour of this driver with jumbo
frames. We ask for 9KB. The driver then bumps that up to a
power-of-two, so it calls dev_al
Andi Kleen wrote:
Incoming packets are only time stamped
when someone asks for the timestamps.
Doesn't that add scheduling latency to the timestamps? Or is is a flag
that gets set to trigger timestamping at packet arrival?
Chris
-
To unsubscribe from this list: send the line "unsubscribe n
Hi guys,
I've got a few questions about NAPI.
The help text in the kernel suggests enabling NAPI if incoming packet
rate is over 10Kpps.
If we're under that rate currently, but could grow above that rate, what
would be the impact of enabling NAPI? Why would we not enable it always
if avail
56 matches
Mail list logo
