* Re: big picture UDP/IP performance question re 2.6.18 -> 2.6.32
From: starlight @ 2011-10-01 21:13 UTC (permalink / raw)
To: Willy Tarreau; +Cc: linux-kernel, netdev, Eric Dumazet, Peter Zijlstra
[resend, accidently pasted HTML that VGER bounced]
At Sat 14:41:06 EST 10/1/2011 -0400, Willy Tarreau wrote:
>Just a suggestion, instead of measuring CPU usage
>at a given load, could you check what maximal load
>you can achieve?
Did do that and mentioned it in one of my replies.
Essentially the same result, see comment below.
>It is very possible that CPU
>usage report is not accurate. We observed this in
>a number of situations, especially in high packet
>rate environments where the usage is a sum of many
>micro-measurements.
Thanks for the suggestion Willy.
I'm completely on top of the CPU accounting
aliasing problem. The playback server sends
data in pulses on one-millisecond boundaries
due to the behavior of nsleep() when used to
pace a log playback. The receiving system
clock drifts at a rate that is about 60 PPM
different than the transmitting server clock
(according to 'ntpd' synced to within 20 micro-
seconds of a local CDMA time server), and so the
histogram accounting on clock tick intervals
gradually drifts such that CPU displayed by 'top'
and 'vmstat' is actually a varying slice of the
millisecond interval pulse profile. Takes
about 60 seconds for the alias sample
window to drift through the entire pulse.
Turns out if one understands the effect it
adds some value to the recorded CPU statistics.
One can see that the kernel CPU peak arrives
immediately and decays while the user CPU
peak follow somewhere between 150 and 250
microseconds after the kernel peak.
Makes perfect sense as at the start of the
pulse the packets are being processed in the
kernel and are then handed off to the application.
Anyway the test run is 20 minutes long so the
values reported here are accurate due to
the averaging-out of the aliasing effect.
As mentioned in one of my posts, do also run
at close to 100% utilization where the
aliasing effect does not distort results.
Outcome is the same as the 50% load runs
except that the code runs 20% more efficiently
at full due to batching of packets with
fewer interrupts and context switches.
>Also, I did not notice any indication on the load
>level you were reaching (packets per second and
>bandwidth).
20% bandwidth and 50k pps on four links for
half-load test, 200k pps total
40% bandwidth and 100k pps on four links for
full-load test, 400k pps total
>Have you compared the interrupt rate?
>It is possible that they differ between the two
>kernels, for instance because the NIC auto-adapts
>instead of being throttled to a given rate. This
>can have a significant impact on measurements and
>performance.
The interrupt rates are about the same. Ran
the test with the exact same 'e1000e' driver
compiled from the Intel SourceForge version.
Native 'e1000e' runs something like 0.5%
better.
-----
Willy, Sorry your e-mail was blocked. Forgot
to turn off the non-US country block I use
to limit spam. It's off now and I'll keep
it off for a couple of days.
^ permalink raw reply
* Re: Hang with "runaway loop modprobe net-pf-1" on Linux 3.0.4
From: Shea Levy @ 2011-10-01 20:37 UTC (permalink / raw)
To: linux-kernel
Cc: David S. Miller, Eric Dumazet, Alban Crequy, Andrew Morton,
Davide Libenzi, netdev
In-Reply-To: <7ca3debde28dcc206c1f6f787df5c619.squirrel@webmail.shealevy.com>
On 09/29/2011 08:38 AM, shea@shealevy.com wrote:
> Hello,
>
> My initrd mounts /proc and /sys, puts a tmpfs at /dev, then loads ext4. On
> 2.6.39 (and earlier), this works fine and the initrd init continues
> happily. On 3.0.4, however, the kernel spits out
>
>> request_module: runaway loop modprobe net-pf-1
> a few times then hangs. If I drop into a shell before loading ext4 and run
> modprobe unix, the same problem occurs. The modprobe used is dynamically
> linked with glibc (which is included in the initrd), and it is the same
> modprobe on the working and non-working systems. From my searches, it
> appears that CONFIG_UNIX=y instead of =m would probably solve this
> problem, but I'd rather keep it as a module if it's possible to get it
> working. What's going wrong here? Why does it work on 2.6.39 but not
> 3.0.4?
>
> Regards,
> Shea Levy
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
CC'ing af_unix.c maintainers. Also, I had the same problem with 3.0.
^ permalink raw reply
* Re: big picture UDP/IP performance question re 2.6.18 -> 2.6.32
From: starlight @ 2011-10-01 19:43 UTC (permalink / raw)
To: Eric Dumazet; +Cc: linux-kernel, netdev, Peter Zijlstra
In-Reply-To: <1317496303.3802.25.camel@edumazet-laptop>
At 09:11 PM 10/1/2011 +0200, Eric Dumazet wrote:
>Le samedi 01 octobre 2011 Ã 14:16 -0400, starlight@binnacle.cx
>a écrit :
>
>2.6.32 has a perf tool, that can really help to
>spot in a few minutes hot spots. That would
>definitely help to further diagnose what could be
>the problem in your workload.
Ok.
First I'm really interested in turning off all the
container stuff, so I'm building a 2.6.32.27
kernel that way to see the effect.
If that doesn't fix it, I'll dig in with 'perf'
in the RHEL-like build I've tried and found
performs the same as RH.
If it does fix it, I doubt much can be done
except compile kernels without it.
Haven't been paying attention to containers
but now that I've read up on them, it sure
sounds like the kind of feature that can
double the length of an efficient code-path.
Sometimes performance is traded for new features
and that's just the way it is. As long as
some way to maintain efficiency by shedding
them is available, I'll be happy. Our workload
is essentially a HPC one, and like most in the
HPC realm, we need to be as close to the metal
as possible.
^ permalink raw reply
* Re: big picture UDP/IP performance question re 2.6.18 -> 2.6.32
From: Eric Dumazet @ 2011-10-01 19:11 UTC (permalink / raw)
To: starlight; +Cc: linux-kernel, netdev, Peter Zijlstra
In-Reply-To: <6.2.5.6.2.20111001141002.05af4b20@binnacle.cx>
Le samedi 01 octobre 2011 à 14:16 -0400, starlight@binnacle.cx a écrit :
> At 08:44 AM 10/1/2011 +0200, Eric Dumazet wrote:
> >In my experience, I have the exact opposite :
> >performance greatly improved in recent
> >kernels. Unless you compile your kernel to include
> >new features that might reduce performance
> >(namespaces, cgroup, ...)
>
> RH has both of the above turned on in the
> 2.6.32-71.29.1.el6.x86_64 kernel tested.
>
> If these are big negatives to network
> performance, could you list what should
> specifically turned off to maximize
> results? Also a recommendation for
> the best recent kernel for another
> benchmark would be helpful.
>
> Probably can't convince anyone to deploy a
> kernel without commercial support, but if
> an alternate compile fixes performance it
> might be possible to convince RH to support
> the alternative build.
>
2.6.32 has a perf tool, that can really help to spot in a few minutes
hot spots. That would definitely help to further diagnose what could be
the problem in your workload.
A single patch can have huge performance impact, sometime not noticed.
For example, in 2.6.36, AF_UNIX support for pid namespaces dropped
performance a lot [commit 7361c36c5224 (af_unix: Allow credentials to
work across user and pid namespaces)], because of a single atomic
operation, but done on each send() and receive() on a central location.
^ permalink raw reply
* Re: big picture UDP/IP performance question re 2.6.18 -> 2.6.32
From: Willy Tarreau @ 2011-10-01 18:40 UTC (permalink / raw)
To: starlight; +Cc: Eric Dumazet, linux-kernel, netdev, Peter Zijlstra
In-Reply-To: <6.2.5.6.2.20111001141002.05af4b20@binnacle.cx>
On Sat, Oct 01, 2011 at 02:16:05PM -0400, starlight@binnacle.cx wrote:
> At 08:44 AM 10/1/2011 +0200, Eric Dumazet wrote:
> >In my experience, I have the exact opposite :
> >performance greatly improved in recent
> >kernels. Unless you compile your kernel to include
> >new features that might reduce performance
> >(namespaces, cgroup, ...)
>
> RH has both of the above turned on in the
> 2.6.32-71.29.1.el6.x86_64 kernel tested.
>
> If these are big negatives to network
> performance, could you list what should
> specifically turned off to maximize
> results? Also a recommendation for
> the best recent kernel for another
> benchmark would be helpful.
>
> Probably can't convince anyone to deploy a
> kernel without commercial support, but if
> an alternate compile fixes performance it
> might be possible to convince RH to support
> the alternative build.
Just a suggestion, instead of measuring CPU usage at a
given load, could you check what maximal load you can
achieve ? It is very possible that CPU usage report is
not accurate. We observed this in a number of situations,
especially in high packet rate environments where the
usage is a sum of many micro-measurements.
Also, I did not notice any indication on the load level
you were reaching (packets per second and bandwidth).
Have you compared the interrupt rate ? It is possible
that they differ between the two kernels, for instance
because the NIC auto-adapts instead of being throttled
to a given rate. This can have a significant impact on
measurements and performance.
Regards,
Willy
^ permalink raw reply
* Re: big picture UDP/IP performance question re 2.6.18 -> 2.6.32
From: starlight @ 2011-10-01 18:16 UTC (permalink / raw)
To: Eric Dumazet; +Cc: linux-kernel, netdev, Peter Zijlstra
At 08:44 AM 10/1/2011 +0200, Eric Dumazet wrote:
>In my experience, I have the exact opposite :
>performance greatly improved in recent
>kernels. Unless you compile your kernel to include
>new features that might reduce performance
>(namespaces, cgroup, ...)
RH has both of the above turned on in the
2.6.32-71.29.1.el6.x86_64 kernel tested.
If these are big negatives to network
performance, could you list what should
specifically turned off to maximize
results? Also a recommendation for
the best recent kernel for another
benchmark would be helpful.
Probably can't convince anyone to deploy a
kernel without commercial support, but if
an alternate compile fixes performance it
might be possible to convince RH to support
the alternative build.
^ permalink raw reply
* Re: [RFC patch net-next-2.6] net: introduce ethernet teaming device
From: Jesse Gross @ 2011-10-01 18:15 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, eric.dumazet, bhutchings, shemminger, fubar, andy,
tgraf, ebiederm, mirqus, kaber, greearb
In-Reply-To: <1317386643-3041-1-git-send-email-jpirko@redhat.com>
On Fri, Sep 30, 2011 at 5:44 AM, Jiri Pirko <jpirko@redhat.com> wrote:
> This patch introduces new network device called team. It supposes to be
> very fast, simple, userspace-driven parallel to existing bonding device.
> Userspace library called libteam with couple of demo apps is available
> here:
> https://github.com/jpirko/libteam
> Note it's still in its dipers atm.
>
> team<->libteam use generic netlink for communication. That and rtnl
> suppose to be the only way to configure team device, no sysfs etc.
>
> In near future python binding for libteam will be introduced. Also
> daemon providing arpmon/miimon active-backup functionality will
> be introduced. All what's necessary is already implemented in kernel team
> driver.
>
> Plan is to support 8023ad in near future with it's logic mainly in
> userspace daemon as well.
>
> Please review, try, comment. All feedback would be much appreciated.
>
> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
Not to push my own agenda too much but you might want to take a look
at Open vSwitch. It uses the same strategy of userspace directed
bonding and already supports active-backup, 802.3ad, and quite a few
other networking tools all controlled by userspace.
I know there's been a lot of talk and not a lot of action when it
comes to upstreaming but that's changing. We're fixing up a few loose
ends in the userspace/kernel interface and then intend to propose a
patch fairly soon.
^ permalink raw reply
* Re: [PATCH 01/15] add Documentation/namespaces/user_namespace.txt (v3)
From: Serge E. Hallyn @ 2011-10-01 17:00 UTC (permalink / raw)
To: Vasiliy Kulikov
Cc: Serge Hallyn, akpm, linux-kernel, netdev, containers, dhowells,
ebiederm, rdunlap, kernel-hardening
In-Reply-To: <20110927155659.GA22532@albatros>
Quoting Vasiliy Kulikov (segoon@openwall.com):
> On Tue, Sep 27, 2011 at 08:21 -0500, Serge E. Hallyn wrote:
> > > First, the patches by design expose much kernel code to unprivileged
> > > userspace processes. This code doesn't expect malformed data (e.g. VFS,
> > > specific filesystems, block layer, char drivers, sysadmin part of LSMs,
> > > etc. etc.). By relaxing permission rules you greatly increase attack
> > > surface of the kernel from unprivileged users. Are you (or somebody
> > > else) planning to audit this code?
> >
> > I had wanted to (but didn't) propose a discussion at ksummit about how
> > best to approach the filesystem code. That's not even just for user
> > namespaces - patches have been floated in the past to make mount an
> > unprivileged operation depending on the FS and the user's permission
> > over the device and target.
>
> This is a dangerous operation by itself.
Of course it is :) And it's been a while since it has been brought up,
but it *was* quite well thought through and throrougly discussed - see
i.e. https://lkml.org/lkml/2008/1/8/131
Oh, that's right. In the end the reason it didn't go in had to do with
the ability for an unprivileged user to prevent a privileged user from
unmounting trees by leaving a busy mount in a hidden namespace.
Eric, in the past we didn't know what to do about that, but I wonder
if setns could be used in some clever way to solve it from userspace.
> AFAICS, this is the reason why
> e.g. FUSE doesn't pass user mount points to other users and even root.
> Beginning from violating some rules like existance of single "." and
> ".." in each directory and ending with filename charsets with /, \000
> and things like `, ", ', \ inside.
>
>
> > So I don't know if a combination of auditing
> > and fuzzing is the way to go,
>
> Maybe the combination of both. There are no generic recommendations,
> it's always limited to the subsystem, checked property, and the
> auditor.
Ok, let me keep focusing on the tightening down right now, and then
before proceeding with relaxing, I'll start some analysis and discussion
of the code which is already under targeted (ns_capable) capability checks.
> > > Also, will it be possible to somehow restrict what specific kernel
> > > facilities are accessible from users (IOW, what root emulation
> > > limitations are in action)? It is userful from both points of sysadmin,
> > > who might not want to allow users to do such things, and from the
> > > security POV in sense of attack surface reduction.
> >
> > You're probably thinking along different lines, but this is why I've
> > been wanting seccomp2 to get pushed through. So that we can deny a
> > container the syscalls we know it won't need, especially newer ones,
> > to reduce the attack surface available to it.
>
> This dependency greatly complicates the things.
IMO this is not a dependency for user namespaces though - it's only a
dependency for unprivileged user namespaces. And we haven't seriously
discussed doing that yet precisely because we're nowhere near ready
(and frankly I don't know that it'll ever be sane).
> First, there is a big misunderstanding between Will and Ingo in what
> needs seccompv2 should serve. Will wants to reduce kernel attack
I know I know :)
> surface by limiting syscalls and syscall arguments available to a user
> (a single task, btw). Ingo wants to see a full featured filtering
> engine, which needs code changes all over the kernel. Given the needed
> changes amounts, it will unlikely reduce attack surface.
>
> You probably don't want Will's version as syscalls filtering is a very
It seems to me per-syscall filtering is a great start. I'm not looking
to seccomp2 as an assurance against formerly privileged (and now only
privileged per-namespace) code which may have had previously overlooked
bugs. I'm looking to seccomp2 as an assurance against bugs in newly
written syscalls or the compatibility layer.
> bad abstraction in your case. user_namespaces likely need Ingo's
> version of seccomp as it will be possible to filter e.g. fs-specific
> events, but even if it is implemented, it will take a looong time for
> your needs IMHO.
Yes, I think that would just lead to exploits through bad policy.
> Also, I'm afraid for _good_ user_namespace filtering the policy
> definition will be too complicated (like SELinux policy definition for
> non-trivial applications) if it is implemented in events filtering
> terms.
>
>
> > The way we're approaching it right now is that by default everything
> > stays 'capable(X)', so that a non-init user namespace doesn't get the
> > privileges.
>
> Great. I was not sure about it.
>
>
> > While some of my patchsets this summer didn't follow this,
> > Eric reminded me that we should first clamp down on the user namespaces
> > as much as possible, and relax permissions in child namespaces later.
>
> I think it is the only sane way.
Yup. I trust you and Eric will keep me in check if I get over-zealous :)
-serge
^ permalink raw reply
* winner
From: Microsoft @ 2011-10-01 5:49 UTC (permalink / raw)
You have won 500.000 GBP
send your phone number
and address
^ permalink raw reply
* Re: big picture UDP/IP performance question re 2.6.18 -> 2.6.32
From: starlight @ 2011-10-01 15:56 UTC (permalink / raw)
To: Eric Dumazet; +Cc: linux-kernel, netdev, Peter Zijlstra
In-Reply-To: <1317451442.3802.18.camel@edumazet-laptop>
At 08:44 AM 10/1/2011 +0200, Eric Dumazet wrote:
>Le samedi 01 octobre 2011 Ã 01:30 -0400, starlight@binnacle.cx
>a écrit :
>> Hello,
>>
>> I'm hoping someone can provide a brief big-picture
>> perspective on the dramatic UDP/IP multicast
>> receive performance reduction from 2.6.18 to
>> 2.6.32 that I just benchmarked.
>>
>> Have helped out in the past, mainly by identifying
>> a bug in hugepage handling and providing a solid
>> testcase that helped in quickly identifying and
>> correcting the problem.
>>
>> Have a very-high-volume UDP multicast receiver
>> application. Just finished benchmarking latest RH
>> variant of 2.6.18 against latest RH 2.6.32 and
>> vanilla 2.6.32.27 on the same 12 core Opteron
>> 6174 processor system, one CPU.
>>
>> Application reads on 250 sockets with large socket
>> buffer maximums. Zero data loss. Four Intel
>> 'e1000e' 82571 gigabit NICs, or two Intel 'igb'
>> 82571 gigabit NICs or two Intel 82599 10 gigabit
>> NICs. Results similar on all.
>>
>> With 2.6.18, system CPU is reported in
>> /proc/<pid>/stat as 25% of total. With 2.6.32,
>> system consumption is 45% with the same exact data
>> playback test. Jiffy count for user CPU is same
>> for both kernels, but .32 system CPU is double
>> .18 system CPU.
>>
>> Overall maximum performance capacity is reduced in
>> proportion to the increased system overhead.
>>
>> ------
>>
>> My question is why is the performance significantly
>> worse in the more recent kernels? Apparently
>> network performance is worse for TCP by about the
>> same amount--double the system overhead for the
>> same amount of work.
>>
>>
>http://www.phoronix.com/scan.php?page=article&item=linux_2612_2637&num=6
>>
>> Is there any chance that network performance will
>> improve in future kernels? Or is the situation
>> a permanent trade-off for security, reliability
>> or scalability reasons?
>>
>
>CC netdev
>
>Since you have 2.6.32, you could use perf tool and
>provide us a performance report.
>
>In my experience, I have the exact opposite :
>performance greatly improved in recent
>kernels. Unless you compile your kernel to include
>new features that might reduce performance
>(namespaces, cgroup, ...)
>
>It can vary a lot depending on many parameters,
>like cpu affinities, device parameters
>(coalescing, interrupt mitigation...).
>
>You cant expect switching from 2.6.18 to 2.6.32
>and have exactly same system behavior.
>
>If your app is performance sensitive, you'll have
>to make some analysis to find out what needs to be
>tuned.
The application and kernel were both substantially
tuned in the test that was just run. Socket
buffers are set to 64MB and NIC IRQs are hand-mapped
to specific cores. Both Intel and korg drivers
were tested. Default Intel coalescing is applied
since that generally works the best. Maximum receive
ring queues of 4096 are set. Data arrives on four
NICs with the workload balanced evenly across twelve
cores. For multi-queue NICs the number of queues
is set to match the number of cores and the IRQs
hand-mapped. Tests were run at 50% CPU utilization
and at maximum zero-data-loss utilization of
about 95% (on all cores).
>One known problem of old kernels and UDP is that
>they was no memory accouting, so an application
>could easily consume all kernel memory and crash
>the machine.
>
>So in 2.6.25, Hideo Aoki added memory limiting to
>UDP, slowing down a lot of UDP operations because
>of added socket locking, both on transmit and
>receive path.
In this case RH has backported the memory accounting
logic to the older kernel tested, 2.6.18-194.8.1.el5
which comes from their RHEL 5.5 release. I recently
reported that the defaults were incorrect in both
vanilla and RH and that without adjustment to
'net.ipv4.udp_mem' the system can hang or crash.
The test system has this value tuned and
was enforcing the limit during the test,
though the limit was never hit or packet
loss would have resulted. There was none.
Also have tested 2.6.18-274.3.1.el5 from
RHEL 5.7 with identical results.
>If your application is multithreaded and use a
>single socket, you can hit lock contention since
>2.6.25.
Each multicast has a dedicated socket and a
thread that reads each packet and performs some
computational work in a forever loop. Two
very-low-contention mutexs (there are large
arrays for each) are taken briefly and then
released by the application. No other work
is performed in the benchmarked scenario.
>Step by step, we tried to remove part of the
>scalability problems introduced in 2.6.25
>
>In 2.6.35, we speedup receive path a bit (avoiding
>backlog processing)
>
>In 2.6.39, transmit path became lockless again,
>thanks to Herbert Xu.
>
>I advise you to try a recent kernel if you need
>UDP performance, 2.6.32 is quite old
I can run this test, but the problem is the
application must run on a commercially supported
kernel. 2.6.32 was chosen by RH for their
RHEL 6 release. The motivation for the
benchmark was to test RHEL 6 against RHEL 5.
>Multicast is quite a stress for process scheduler,
>so we experimented a way to group all wakeups at
>the end of softirq handler.
If this is present in 2.6.32, I am concerned it
could have had an unintended negative impact on
performance. This sort of adjustment is tricky
in my experience. Seemingly great tuning ideas
are a bust more often than a success. L2 and
L3 cache dynamics introduce all kinds of
non-intuitive effects.
>Work is in progress in this area : Peter Zijlstra
>named this "delayed wakeup". A further idea would
>be to be able to delegate the wakeups to another
>cpu, since I suspect you have one CPU busy in
>softirq processing, and other cpus are idle.
Actually no. 'top' shows a perfectly even CPU/core
load distribution. To minimize latency and maximize
performance we map IRQs carefully to as many cores
as possible. User-space threads are allowed to
float and the Linux scheduler usually wakes a
worker thread up on the same core that the
bottom-half processing is completed on, which
usually is the core the interrupt arrived on. In
the case of the single-queue 82571 'e1000e', four
cores (one for each NIC) do all the bottom half
processing (as seen in top), and userspace work is
completed on the same or nearby cores. It should
be said that the 'e1000e' driver is substantially
more efficient that the newer 'igb' and 'ixgbe'
multi-queue drivers and the the benchmarks runs
the best with 'e1000e'. So the cost of moving
work from one core to another during the
transition from kernel to user-space is apparently
very low when present.
-----
Thanks for all the info. I'll keep an eye on
upcoming kernels and benchmark them on occasion.
RH often backports significant improvements.
Or perhaps they'll break with tradition and
advance to a newer kernel at some point for
RHEL 6.
Fortunately RHEL 5 will be supported for some
time so the older kernel can continue to be
used.
Should mention in closing that the tests were
also run using PACKET sockets, one per interface.
The results with PACKET sockets and with UDP
sockets are quite close. System overhead is
exactly the same with the same kernel, and a
10% user-space penalty is incurred because
data must be copied to an array of queues
for proper fan-out to a worker pool, and worker
threads woken-up. This test only make sense
with the single-queue 'e1000e' NICs so it was
not performed with multi-queue NICs.
^ permalink raw reply
* Attention administrateur système,
From: alexis.houdart @ 2011-10-01 10:54 UTC (permalink / raw)
System Administrator Waarschuwing,
Uw mailbox heeft overschreden de limiet van 20 GB, dat wordt gedefinieerd
door je manager, u op dit moment op 20.9GB, zult u niet
in staat zijn om een nieuwe e-mail te sturen maakt of ontvangt
opnieuw tot bevestigt u uw mailbox.To revalideren uw
mailbox,
Klik en vul de link hieronder
==================>http://buzurl.com/bo61
Bedankt voor uw begrip
De beheerder van het systeem.
^ permalink raw reply
* Re: [net-next 11/11 v2] ixgbe: allow eeprom writes via ethtool
From: Francois Romieu @ 2011-10-01 9:31 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, Emil Tantilov, netdev, gospo
In-Reply-To: <1317444771-13962-2-git-send-email-jeffrey.t.kirsher@intel.com>
Jeff Kirsher <jeffrey.t.kirsher@intel.com> :
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
> index 10ea29f..fb47abb 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
> @@ -812,6 +812,66 @@ static int ixgbe_get_eeprom(struct net_device *netdev,
[...]
> + ptr = (void *)eeprom_buff;
(nit) useless cast to void *.
> +
> + if (eeprom->offset & 1) {
[...]
> + ret_val = hw->eeprom.ops.read(hw, first_word, &eeprom_buff[0]);
> + ptr++;
> + }
> + if (((eeprom->offset + eeprom->len) & 1) && (ret_val == 0)) {
[...]
> + ret_val = hw->eeprom.ops.read(hw, last_word,
> + &eeprom_buff[last_word - first_word]);
> + }
I guess that the code tries to do its best to write something even when the
reads or writes partially fail but this one should imho be :
if ((eeprom->offset + eeprom->len) & 1) {
[...]
ret_val |= hw->eeprom.ops.read(hw, last_word,
> +
> + /* Device's eeprom is always little-endian, word addressable */
> + for (i = 0; i < last_word - first_word + 1; i++)
> + le16_to_cpus(&eeprom_buff[i]);
Shouldn't there be (drivers/net/ethernet/intel/ixgbe/ixgbe_type.h):
struct ixgbe_eeprom_operations {
[...]
s32 (*read)(struct ixgbe_hw *, u16, __le16 *);
instead of :
struct ixgbe_eeprom_operations {
[...]
s32 (*read)(struct ixgbe_hw *, u16, u16 *);
[...]
> + /* Update the checksum */
> + hw->eeprom.ops.update_checksum(hw);
The returned status code is ignored.
--
Ueimor
^ permalink raw reply
* Re: [RFC patch net-next-2.6] net: introduce ethernet teaming device
From: Jiri Pirko @ 2011-10-01 8:15 UTC (permalink / raw)
To: Stephen Hemminger
Cc: netdev, davem, eric.dumazet, bhutchings, fubar, andy, tgraf,
ebiederm, mirqus, kaber, greearb
In-Reply-To: <20110930092619.6b45087d@nehalam.linuxnetplumber.net>
Fri, Sep 30, 2011 at 06:26:19PM CEST, shemminger@vyatta.com wrote:
>On Fri, 30 Sep 2011 14:44:03 +0200
>Jiri Pirko <jpirko@redhat.com> wrote:
>
>> +static struct rtnl_link_stats64 *team_get_stats(struct net_device *dev,
>> + struct rtnl_link_stats64 *stats)
>> +{
>> + struct team *team = netdev_priv(dev);
>> + struct rtnl_link_stats64 temp;
>> + struct team_port *port;
>> +
>> + memset(stats, 0, sizeof(*stats));
>> +
>> + rcu_read_lock();
>> + list_for_each_entry_rcu(port, &team->port_list, list) {
>> + const struct rtnl_link_stats64 *pstats;
>
>You need to use u64_stats_sync macros to make this safe on 32 bit
>mode.
Well I'm doing this the same way it's done on several other place, as
for example bonding.
>
>Also, I am not sure about the handling of speed and duplex.
>There are people who do active backup with links of different speeds.
Yes, team can handle multiple ifaces with different speeds and duplexes.
Why would you think it cannot?
>
>The team device doesn't seem to handle hardware offload features
>as completely as it should. The TSO and transmit checksumming should
>be the union of the teamed ports.
>
Yeah, you are right here. I probably need something like
bond_compute_features() for team. Will add that.
Thank you Stephen.
Jirka
^ permalink raw reply
* (unknown),
From: FEDEX OFFICE @ 2011-10-01 4:56 UTC (permalink / raw)
Attn: Beneficiary,
This is to inform you that your package worth the sum of $800,000.00 (Eight
Hundred Thousand United State Dollars) in a certified bank draft is in our
office ready for delivery,We are sending you this email because your package
has been registered on a Special Order.You are advise to contact our Delivery
Department for immediate dispatch of your package to your designated address.
Regards
Mr.Umar Tony {Head Dispatch Officer}
FedEx Express ®Courier Company West-Africa
E-mail:fedexdelivery1952@msn.com
Telephone Number:+234-70-65749930
---------------------------------------------------------------------------------
www.galiciaaberta.com
Información mantida pola Secretaría Xeral de Emigración da Xunta de Galicia
^ permalink raw reply
* Re: big picture UDP/IP performance question re 2.6.18 -> 2.6.32
From: Eric Dumazet @ 2011-10-01 6:44 UTC (permalink / raw)
To: starlight; +Cc: linux-kernel, netdev, Peter Zijlstra
In-Reply-To: <6.2.5.6.2.20111001012019.05c05b80@flumedata.com>
Le samedi 01 octobre 2011 à 01:30 -0400, starlight@binnacle.cx a écrit :
> Hello,
>
> I'm hoping someone can provide a brief big-picture
> perspective on the dramatic UDP/IP multicast
> receive performance reduction from 2.6.18 to
> 2.6.32 that I just benchmarked.
>
> Have helped out in the past, mainly by identifying
> a bug in hugepage handling and providing a solid
> testcase that helped in quickly identifying and
> correcting the problem.
>
> Have a very-high-volume UDP multicast receiver
> application. Just finished benchmarking latest RH
> variant of 2.6.18 against latest RH 2.6.32 and
> vanilla 2.6.32.27 on the same 12 core Opteron
> 6174 processor system, one CPU.
>
> Application reads on 250 sockets with large socket
> buffer maximums. Zero data loss. Four Intel
> 'e1000e' 82571 gigabit NICs, or two Intel 'igb'
> 82571 gigabit NICs or two Intel 82599 10 gigabit
> NICs. Results similar on all.
>
> With 2.6.18, system CPU is reported in
> /proc/<pid>/stat as 25% of total. With 2.6.32,
> system consumption is 45% with the same exact data
> playback test. Jiffy count for user CPU is same
> for both kernels, but .32 system CPU is double
> .18 system CPU.
>
> Overall maximum performance capacity is reduced in
> proportion to the increased system overhead.
>
> ------
>
> My question is why is the performance significantly
> worse in the more recent kernels? Apparently
> network performance is worse for TCP by about the
> same amount--double the system overhead for the
> same amount of work.
>
> http://www.phoronix.com/scan.php?page=article&item=linux_2612_2637&num=6
>
> Is there any chance that network performance will
> improve in future kernels? Or is the situation
> a permanent trade-off for security, reliability
> or scalability reasons?
>
CC netdev
Since you have 2.6.32, you could use perf tool and provide us a
performance report.
In my experience, I have the exact opposite : performance greatly
improved in recent kernels. Unless you compile your kernel to include
new features that might reduce performance (namespaces, cgroup, ...)
It can vary a lot depending on many parameters, like cpu affinities,
device parameters (coalescing, interrupt mitigation...).
You cant expect switching from 2.6.18 to 2.6.32 and have exactly same
system behavior.
If your app is performance sensitive, you'll have to make some analysis
to find out what needs to be tuned.
One known problem of old kernels and UDP is that they was no memory
accouting, so an application could easily consume all kernel memory and
crash the machine.
So in 2.6.25, Hideo Aoki added memory limiting to UDP, slowing down a
lot of UDP operations because of added socket locking, both on transmit
and receive path.
If your application is multithreaded and use a single socket, you can
hit lock contention since 2.6.25.
Step by step, we tried to remove part of the scalability problems
introduced in 2.6.25
In 2.6.35, we speedup receive path a bit (avoiding backlog processing)
In 2.6.39, transmit path became lockless again, thanks to Herbert Xu.
I advise you to try a recent kernel if you need UDP performance, 2.6.32
is quite old
Multicast is quite a stress for process scheduler, so we experimented a
way to group all wakeups at the end of softirq handler.
Work is in progress in this area : Peter Zijlstra named this "delayed
wakeup". A further idea would be to be able to delegate the wakeups to
another cpu, since I suspect you have one CPU busy in softirq
processing, and other cpus are ile.
^ permalink raw reply
* Re: tg3: BMC stops responding in 3.0
From: Arkadiusz Miśkiewicz @ 2011-10-01 5:37 UTC (permalink / raw)
To: Matt Carlson; +Cc: Michael Chan, netdev@vger.kernel.org
In-Reply-To: <20110930235353.GB16743@mcarlson.broadcom.com>
On Saturday 01 of October 2011, Matt Carlson wrote:
> On Fri, Sep 30, 2011 at 01:06:25AM -0700, Arkadiusz Mi??kiewicz wrote:
> > On Friday 30 of September 2011, Matt Carlson wrote:
> > > On Mon, Sep 26, 2011 at 11:31:33AM -0700, Arkadiusz Mi??kiewicz wrote:
> > > > On Monday 26 of September 2011, Matt Carlson wrote:
> > > > > On Fri, Sep 23, 2011 at 12:45:50PM -0700, Arkadiusz Mi??kiewicz
wrote:
> > > > > > Hi,
> > > > > >
> > > > > > I was using 2.6.38.8 and recently tried to switch to 3.0.4 on
> > > > > > Tyan S2891 platform.
> > > > > >
> > > > > > This platform uses tg3:
> > > > > > tg3 0000:0a:09.1: eth1: Tigon3 [partno(BCM95704) rev 2003]
> > > > > > (PCIX:133MHz:64- bit) MAC address 00:e0:81:33:5e:af
> > > > > > tg3 0000:0a:09.1: eth1: attached PHY is 5704 (10/100/1000Base-T
> > > > > > Ethernet) (WireSpeed[1], EEE[0])
> > > > > > tg3 0000:0a:09.1: eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0]
> > > > > > TSOcap[1] tg3 0000:0a:09.1: eth1: dma_rwctrl[769f4000]
> > > > > > dma_mask[64-bit]
> > > > > >
> > > > > > With 2.6.38.8 everything was working fine. With 3.0.4 there is a
> > > > > > problem. As soon as tg3 module is loaded or eth0 configured
> > > > > > (can't tell which one since the machine is 400km away from me
> > > > > > and I have no way to play with it other than ipmi or ssh) BMC
> > > > > > stops responding (so all ipmitool commands over LAN stop
> > > > > > working). Normal tg3 activity is not affected - I can ssh-in
> > > > > > without a problem etc but ipmi over lan doesn't work.
> > > > > >
> > > > > > From ssh console "ipmitool lan print" works, shows data but for
> > > > > > example after "ipmitool mc reset cold" it doesn't recover -
> > > > > > ipmitool returns "Invalid channel: 255". I have to reboot to
> > > > > > 2.6.38.8 and then issue "ipmitool mc reset cold" to recover.
> > > > > >
> > > > > > Any idea which tg3 change could break this? Can't bisect this due
> > > > > > remote access only.
> > > > > >
> > > > > > I was hoping that maybe 9e975cc291d80d5e4562d6bed15ec171e896d69b
> > > > > > "tg3: Fix io failures after chip reset" will fix things for me
> > > > > > but no - this doesn't help.
> > > > >
> > > > > What version of the tg3 driver are you working with?
> > > >
> > > > The one in 3.0.4 kernel. I think it's 3.119 (at least modinfo says
> > > > so).
> > >
> > > Unfortunately there were a lot of changes between 3.117 and 3.119(+).
> > > Is there any way you can narrow down the gap?
> >
> > The machines are 400km away from me and it's hard to debug that way then
> > ipmi/network conectivity is in stake :-/ I could try some form of
> > bisecting but need to know if all git versions between 3.117 and 3.119
> > were known to be safe and working? I don't want to loose any conectivity
> > to this machine.
> >
> > I was going to try 2.6.39 but it looks like it also uses 3.117 driver.
>
> O.K. Can you give me the details of your machine? Maybe we have the
> exact machine or a machine similar enough to reproduce the problem with.
It's 1U server, with Tyan S2891 mainboard and some chenbro chassis. ipmi and
eth0 share physical rj45 port in the server.
lspci & dmidecode below:
00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3)
Subsystem: Tyan Computer Thunder K8SRE Mainboard
Flags: bus master, 66MHz, fast devsel, latency 0
Capabilities: [44] HyperTransport: Slave or Primary Interface
Capabilities: [e0] HyperTransport: MSI Mapping Enable+ Fixed-
00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3)
Subsystem: Tyan Computer Device 2891
Flags: bus master, 66MHz, fast devsel, latency 0
I/O ports at 8c00 [size=1K]
00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2)
Subsystem: Tyan Computer Device 2891
Flags: 66MHz, fast devsel
I/O ports at 1000 [size=32]
I/O ports at 5000 [size=64]
I/O ports at 5040 [size=64]
Capabilities: [44] Power Management version 2
00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2)
(prog-if 10 [OHCI])
Subsystem: Tyan Computer Device 2891
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 10
Memory at dd000000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [44] Power Management version 2
00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3)
(prog-if 20 [EHCI])
Subsystem: Tyan Computer Device 2891
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 7
Memory at dd001000 (32-bit, non-prefetchable) [size=256]
Capabilities: [44] Debug port: BAR=1 offset=0098
Capabilities: [80] Power Management version 2
00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f2) (prog-if 8a
[Master SecP PriP])
Subsystem: Tyan Computer Device 2891
Flags: bus master, 66MHz, fast devsel, latency 0
[virtual] Memory at 000001f0 (32-bit, non-prefetchable) [size=8]
[virtual] Memory at 000003f0 (type 3, non-prefetchable) [size=1]
[virtual] Memory at 00000170 (32-bit, non-prefetchable) [size=8]
[virtual] Memory at 00000370 (type 3, non-prefetchable) [size=1]
I/O ports at 1400 [size=16]
Capabilities: [44] Power Management version 2
00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3)
(prog-if 85 [Master SecO PriO])
Subsystem: Tyan Computer Device 2891
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 11
I/O ports at 1440 [size=8]
I/O ports at 1434 [size=4]
I/O ports at 1438 [size=8]
I/O ports at 1430 [size=4]
I/O ports at 1410 [size=16]
Memory at dd002000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [44] Power Management version 2
00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3)
(prog-if 85 [Master SecO PriO])
Subsystem: Tyan Computer Device 2891
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 10
I/O ports at 1458 [size=8]
I/O ports at 144c [size=4]
I/O ports at 1450 [size=8]
I/O ports at 1448 [size=4]
I/O ports at 1420 [size=16]
Memory at dd003000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [44] Power Management version 2
00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2) (prog-if 00
[Normal decode])
Flags: bus master, 66MHz, fast devsel, latency 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
I/O behind bridge: 00002000-00002fff
Memory behind bridge: dd100000-deffffff
Prefetchable memory behind bridge: d0000000-d00fffff
00:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) (prog-if 00
[Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
Capabilities: [40] Power Management version 2
Capabilities: [48] MSI: Enable- Count=1/2 Maskable- 64bit+
Capabilities: [58] HyperTransport: MSI Mapping Enable- Fixed-
Capabilities: [80] Express Root Port (Slot+), MSI 00
Kernel driver in use: pcieport
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
HyperTransport Technology Configuration
Flags: fast devsel
Capabilities: [80] HyperTransport: Host or Secondary Interface
Capabilities: [a0] HyperTransport: Host or Secondary Interface
Capabilities: [c0] HyperTransport: Host or Secondary Interface
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
Address Map
Flags: fast devsel
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM
Controller
Flags: fast devsel
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
Miscellaneous Control
Flags: fast devsel
00:19.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
HyperTransport Technology Configuration
Flags: fast devsel
Capabilities: [80] HyperTransport: Host or Secondary Interface
Capabilities: [a0] HyperTransport: Host or Secondary Interface
Capabilities: [c0] HyperTransport: Host or Secondary Interface
00:19.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
Address Map
Flags: fast devsel
00:19.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM
Controller
Flags: fast devsel
00:19.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
Miscellaneous Control
Flags: fast devsel
01:07.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27)
(prog-if 00 [VGA controller])
Subsystem: ATI Technologies Inc Rage XL
Flags: bus master, stepping, medium devsel, latency 66, IRQ 11
Memory at de000000 (32-bit, non-prefetchable) [size=16M]
I/O ports at 2000 [size=256]
Memory at dd100000 (32-bit, non-prefetchable) [size=4K]
[virtual] Expansion ROM at d0000000 [disabled] [size=128K]
Capabilities: [5c] Power Management version 2
08:0a.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev
12) (prog-if 00 [Normal decode])
Flags: bus master, 66MHz, medium devsel, latency 64
Bus: primary=08, secondary=09, subordinate=09, sec-latency=64
I/O behind bridge: 00003000-00003fff
Memory behind bridge: df300000-df3fffff
Prefetchable memory behind bridge: 00000000df500000-00000000df5fffff
Capabilities: [a0] PCI-X bridge device
Capabilities: [b8] HyperTransport: Interrupt Discovery and Configuration
Capabilities: [c0] HyperTransport: Slave or Primary Interface
08:0a.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X IOAPIC (rev 01)
(prog-if 10 [IO-APIC])
Subsystem: Tyan Computer Device 2891
Flags: bus master, medium devsel, latency 0
Memory at df200000 (64-bit, non-prefetchable) [size=4K]
08:0b.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev
12) (prog-if 00 [Normal decode])
Flags: bus master, 66MHz, medium devsel, latency 64
Bus: primary=08, secondary=0a, subordinate=0a, sec-latency=64
Memory behind bridge: df400000-df4fffff
Capabilities: [a0] PCI-X bridge device
Capabilities: [b8] HyperTransport: Interrupt Discovery and Configuration
08:0b.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X IOAPIC (rev 01)
(prog-if 10 [IO-APIC])
Subsystem: Tyan Computer Device 2891
Flags: bus master, medium devsel, latency 0
Memory at df201000 (64-bit, non-prefetchable) [size=4K]
09:08.0 Fibre Channel: QLogic Corp. ISP2312-based 2Gb Fibre Channel to PCI-X
HBA (rev 02)
Subsystem: Compaq Computer Corporation Device 0100
Flags: bus master, 66MHz, medium devsel, latency 128, IRQ 24
I/O ports at 3000 [size=256]
Memory at df300000 (64-bit, non-prefetchable) [size=4K]
[virtual] Expansion ROM at df500000 [disabled] [size=128K]
Capabilities: [44] Power Management version 2
Capabilities: [4c] PCI-X non-bridge device
Capabilities: [54] MSI: Enable- Count=1/8 Maskable- 64bit+
Capabilities: [64] CompactPCI hot-swap <?>
Kernel driver in use: qla2xxx
0a:09.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit
Ethernet (rev 03)
Subsystem: Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet
Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 28
Memory at df410000 (64-bit, non-prefetchable) [size=64K]
Memory at df400000 (64-bit, non-prefetchable) [size=64K]
Capabilities: [40] PCI-X non-bridge device
Capabilities: [48] Power Management version 2
Capabilities: [50] Vital Product Data
Capabilities: [58] MSI: Enable- Count=1/8 Maskable- 64bit+
Kernel driver in use: tg3
0a:09.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit
Ethernet (rev 03)
Subsystem: Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet
Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 29
Memory at df430000 (64-bit, non-prefetchable) [size=64K]
Memory at df420000 (64-bit, non-prefetchable) [size=64K]
Capabilities: [40] PCI-X non-bridge device
Capabilities: [48] Power Management version 2
Capabilities: [50] Vital Product Data
Capabilities: [58] MSI: Enable- Count=1/8 Maskable- 64bit+
Kernel driver in use: tg3
# dmidecode 2.11
SMBIOS version fixup (2.33 -> 2.3).
SMBIOS 2.3 present.
34 structures occupying 1202 bytes.
Table at 0x7FFEF000.
Handle 0x0000, DMI type 0, 20 bytes
BIOS Information
Vendor: Phoenix Technologies Ltd.
Version: 2003Q2
Release Date: 03/27/2006
Address: 0xE65B0
Runtime Size: 105040 bytes
ROM Size: 1024 kB
Characteristics:
PCI is supported
PNP is supported
BIOS is upgradeable
BIOS shadowing is allowed
ESCD support is available
Boot from CD is supported
Selectable boot is supported
EDD is supported
5.25"/360 kB floppy services are supported (int 13h)
5.25"/1.2 MB floppy services are supported (int 13h)
3.5"/720 kB floppy services are supported (int 13h)
3.5"/2.88 MB floppy services are supported (int 13h)
Print screen service is supported (int 5h)
8042 keyboard services are supported (int 9h)
Serial services are supported (int 14h)
Printer services are supported (int 17h)
CGA/mono video services are supported (int 10h)
ACPI is supported
USB legacy is supported
Handle 0x0001, DMI type 1, 25 bytes
System Information
Manufacturer: TYAN Computer Corp
Product Name: S2891
Version: REFERENCE
Serial Number: 0123456789
UUID: Not Settable
Wake-up Type: Power Switch
Handle 0x0002, DMI type 2, 8 bytes
Base Board Information
Manufacturer: TYAN Computer Corp
Product Name: GT24-B2891
Version: REFERENCE
Serial Number: 0123456789
Handle 0x0003, DMI type 3, 17 bytes
Chassis Information
Manufacturer: TYAN Computer Corp
Type: Main Server Chassis
Lock: Not Present
Version: Not Specified
Serial Number: Not Specified
Asset Tag: Not Specified
Boot-up State: Unknown
Power Supply State: Unknown
Thermal State: Unknown
Security Status: Unknown
OEM Information: 0x00000000
Handle 0x0004, DMI type 4, 35 bytes
Processor Information
Socket Designation: CPU0-Socket 940
Type: Central Processor
Family: Opteron
Manufacturer: AMD
ID: 12 0F 02 00 FF FB 8B 17
Signature: Family 15, Model 33, Stepping 2
Flags:
FPU (Floating-point unit on-chip)
VME (Virtual mode extension)
DE (Debugging extension)
PSE (Page size extension)
TSC (Time stamp counter)
MSR (Model specific registers)
PAE (Physical address extension)
MCE (Machine check exception)
CX8 (CMPXCHG8 instruction supported)
APIC (On-chip APIC hardware supported)
SEP (Fast system call)
MTRR (Memory type range registers)
PGE (Page global enable)
MCA (Machine check architecture)
CMOV (Conditional move instruction supported)
PAT (Page attribute table)
PSE-36 (36-bit page size extension)
CLFSH (CLFLUSH instruction supported)
MMX (MMX technology supported)
FXSR (FXSAVE and FXSTOR instructions supported)
SSE (Streaming SIMD extensions)
SSE2 (Streaming SIMD extensions 2)
HTT (Multi-threading)
Version: AMD
Voltage: 1.2 V
External Clock: 200 MHz
Max Speed: 3000 MHz
Current Speed: 2000 MHz
Status: Populated, Enabled
Upgrade: None
L1 Cache Handle: 0x0006
L2 Cache Handle: 0x0007
L3 Cache Handle: Not Provided
Serial Number: Not Specified
Asset Tag: Not Specified
Part Number: Not Specified
Handle 0x0005, DMI type 4, 35 bytes
Processor Information
Socket Designation: CPU1-Socket 940
Type: Central Processor
Family: Opteron
Manufacturer: AMD
ID: 12 0F 02 00 FF FB 8B 17
Signature: Family 15, Model 33, Stepping 2
Flags:
FPU (Floating-point unit on-chip)
VME (Virtual mode extension)
DE (Debugging extension)
PSE (Page size extension)
TSC (Time stamp counter)
MSR (Model specific registers)
PAE (Physical address extension)
MCE (Machine check exception)
CX8 (CMPXCHG8 instruction supported)
APIC (On-chip APIC hardware supported)
SEP (Fast system call)
MTRR (Memory type range registers)
PGE (Page global enable)
MCA (Machine check architecture)
CMOV (Conditional move instruction supported)
PAT (Page attribute table)
PSE-36 (36-bit page size extension)
CLFSH (CLFLUSH instruction supported)
MMX (MMX technology supported)
FXSR (FXSAVE and FXSTOR instructions supported)
SSE (Streaming SIMD extensions)
SSE2 (Streaming SIMD extensions 2)
HTT (Multi-threading)
Version: AMD
Voltage: 1.2 V
External Clock: 200 MHz
Max Speed: 3000 MHz
Current Speed: 2000 MHz
Status: Populated, Enabled
Upgrade: None
L1 Cache Handle: 0x0008
L2 Cache Handle: 0x0009
L3 Cache Handle: Not Provided
Serial Number: Not Specified
Asset Tag: Not Specified
Part Number: Not Specified
Handle 0x0006, DMI type 7, 19 bytes
Cache Information
Socket Designation: H0 L1 Cache
Configuration: Enabled, Not Socketed, Level 1
Operational Mode: Write Back
Location: Internal
Installed Size: 64 kB
Maximum Size: 64 kB
Supported SRAM Types:
Burst
Pipeline Burst
Asynchronous
Installed SRAM Type: Asynchronous
Speed: Unknown
Error Correction Type: Unknown
System Type: Unknown
Associativity: Unknown
Handle 0x0007, DMI type 7, 19 bytes
Cache Information
Socket Designation: H0 L2 Cache
Configuration: Enabled, Not Socketed, Level 2
Operational Mode: Write Through
Location: Internal
Installed Size: 2048 kB
Maximum Size: 1024 kB
Supported SRAM Types:
Burst
Pipeline Burst
Synchronous
Installed SRAM Type: Synchronous
Speed: Unknown
Error Correction Type: Unknown
System Type: Unified
Associativity: Unknown
Handle 0x0008, DMI type 7, 19 bytes
Cache Information
Socket Designation: H1 L1 Cache
Configuration: Enabled, Not Socketed, Level 1
Operational Mode: Write Back
Location: Internal
Installed Size: 64 kB
Maximum Size: 64 kB
Supported SRAM Types:
Burst
Pipeline Burst
Asynchronous
Installed SRAM Type: Asynchronous
Speed: Unknown
Error Correction Type: Unknown
System Type: Unknown
Associativity: Unknown
Handle 0x0009, DMI type 7, 19 bytes
Cache Information
Socket Designation: H1 L2 Cache
Configuration: Enabled, Not Socketed, Level 2
Operational Mode: Write Through
Location: Internal
Installed Size: 2048 kB
Maximum Size: 1024 kB
Supported SRAM Types:
Burst
Pipeline Burst
Synchronous
Installed SRAM Type: Synchronous
Speed: Unknown
Error Correction Type: Unknown
System Type: Unified
Associativity: Unknown
Handle 0x000A, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J2
Internal Connector Type: PS/2
External Reference Designator: PS/2 Mouse
External Connector Type: PS/2
Port Type: Mouse Port
Handle 0x000B, DMI type 9, 13 bytes
System Slot Information
Designation: PCI Slot 1
Type: 32-bit PCI
Current Usage: Unknown
Length: Long
ID: 0
Characteristics:
3.3 V is provided
PME signal is supported
Handle 0x000C, DMI type 11, 5 bytes
OEM Strings
String 1: 0
String 2: 0
String 3: .........................
Handle 0x000D, DMI type 16, 15 bytes
Physical Memory Array
Location: System Board Or Motherboard
Use: System Memory
Error Correction Type: Single-bit ECC
Maximum Capacity: 32 GB
Error Information Handle: Not Provided
Number Of Devices: 8
Handle 0x000E, DMI type 17, 27 bytes
Memory Device
Array Handle: 0x000D
Error Information Handle: No Error
Total Width: 128 bits
Data Width: 64 bits
Size: 8192 MB
Form Factor: DIMM
Set: 1
Locator: C0_DIMM0
Bank Locator: Bank 0
Type: DRAM
Type Detail: Synchronous
Speed: Unknown
Manufacturer: Not Specified
Serial Number: Not Specified
Asset Tag: Not Specified
Part Number: Not Specified
Handle 0x000F, DMI type 17, 27 bytes
Memory Device
Array Handle: 0x000D
Error Information Handle: No Error
Total Width: 128 bits
Data Width: 64 bits
Size: 8192 MB
Form Factor: DIMM
Set: 2
Locator: C0_DIMM1
Bank Locator: Bank 1
Type: DRAM
Type Detail: Synchronous
Speed: Unknown
Manufacturer: Not Specified
Serial Number: Not Specified
Asset Tag: Not Specified
Part Number: Not Specified
Handle 0x0010, DMI type 17, 27 bytes
Memory Device
Array Handle: 0x000D
Error Information Handle: No Error
Total Width: 128 bits
Data Width: 64 bits
Size: 8192 MB
Form Factor: DIMM
Set: 3
Locator: C0_DIMM2
Bank Locator: Bank 2
Type: DRAM
Type Detail: Synchronous
Speed: Unknown
Manufacturer: Not Specified
Serial Number: Not Specified
Asset Tag: Not Specified
Part Number: Not Specified
Handle 0x0011, DMI type 17, 27 bytes
Memory Device
Array Handle: 0x000D
Error Information Handle: No Error
Total Width: 128 bits
Data Width: 64 bits
Size: 8192 MB
Form Factor: DIMM
Set: 3
Locator: C0_DIMM3
Bank Locator: Bank 3
Type: DRAM
Type Detail: Synchronous
Speed: Unknown
Manufacturer: Not Specified
Serial Number: Not Specified
Asset Tag: Not Specified
Part Number: Not Specified
Handle 0x0012, DMI type 17, 27 bytes
Memory Device
Array Handle: 0x000D
Error Information Handle: No Error
Total Width: 128 bits
Data Width: 64 bits
Size: 8192 MB
Form Factor: DIMM
Set: 3
Locator: C0_DIMM0
Bank Locator: Bank 0
Type: DRAM
Type Detail: Synchronous
Speed: Unknown
Manufacturer: Not Specified
Serial Number: Not Specified
Asset Tag: Not Specified
Part Number: Not Specified
Handle 0x0013, DMI type 17, 27 bytes
Memory Device
Array Handle: 0x000D
Error Information Handle: No Error
Total Width: 128 bits
Data Width: 64 bits
Size: 8192 MB
Form Factor: DIMM
Set: 3
Locator: C1_DIMM1
Bank Locator: Bank 1
Type: DRAM
Type Detail: Synchronous
Speed: Unknown
Manufacturer: Not Specified
Serial Number: Not Specified
Asset Tag: Not Specified
Part Number: Not Specified
Handle 0x0014, DMI type 17, 27 bytes
Memory Device
Array Handle: 0x000D
Error Information Handle: No Error
Total Width: Unknown
Data Width: Unknown
Size: No Module Installed
Form Factor: DIMM
Set: 3
Locator: C1_DIMM2
Bank Locator: Bank 2
Type: DRAM
Type Detail: Synchronous
Speed: Unknown
Manufacturer: Not Specified
Serial Number: Not Specified
Asset Tag: Not Specified
Part Number: Not Specified
Handle 0x0015, DMI type 17, 27 bytes
Memory Device
Array Handle: 0x000D
Error Information Handle: No Error
Total Width: Unknown
Data Width: Unknown
Size: No Module Installed
Form Factor: DIMM
Set: 3
Locator: C1_DIMM3
Bank Locator: Bank 3
Type: DRAM
Type Detail: Synchronous
Speed: Unknown
Manufacturer: Not Specified
Serial Number: Not Specified
Asset Tag: Not Specified
Part Number: Not Specified
Handle 0x0016, DMI type 19, 15 bytes
Memory Array Mapped Address
Starting Address: 0x00000000000
Ending Address: 0x00BFFFFFFFF
Range Size: 48 GB
Physical Array Handle: 0x000D
Partition Width: 2
Handle 0x0017, DMI type 20, 19 bytes
Memory Device Mapped Address
Starting Address: 0x00000000000
Ending Address: 0x001FFFFFFFF
Range Size: 8 GB
Physical Device Handle: 0x000E
Memory Array Mapped Address Handle: 0x0016
Partition Row Position: 1
Interleaved Data Depth: 1
Handle 0x0018, DMI type 20, 19 bytes
Memory Device Mapped Address
Starting Address: 0x00200000000
Ending Address: 0x003FFFFFFFF
Range Size: 8 GB
Physical Device Handle: 0x000F
Memory Array Mapped Address Handle: 0x0016
Partition Row Position: 1
Interleaved Data Depth: 1
Handle 0x0019, DMI type 20, 19 bytes
Memory Device Mapped Address
Starting Address: 0x00400000000
Ending Address: 0x005FFFFFFFF
Range Size: 8 GB
Physical Device Handle: 0x0010
Memory Array Mapped Address Handle: 0x0016
Partition Row Position: 1
Interleaved Data Depth: 1
Handle 0x001A, DMI type 20, 19 bytes
Memory Device Mapped Address
Starting Address: 0x00600000000
Ending Address: 0x007FFFFFFFF
Range Size: 8 GB
Physical Device Handle: 0x0011
Memory Array Mapped Address Handle: 0x0016
Partition Row Position: 1
Interleaved Data Depth: 1
Handle 0x001B, DMI type 20, 19 bytes
Memory Device Mapped Address
Starting Address: 0x00800000000
Ending Address: 0x009FFFFFFFF
Range Size: 8 GB
Physical Device Handle: 0x0012
Memory Array Mapped Address Handle: 0x0016
Partition Row Position: 1
Interleaved Data Depth: 1
Handle 0x001C, DMI type 20, 19 bytes
Memory Device Mapped Address
Starting Address: 0x00A00000000
Ending Address: 0x00BFFFFFFFF
Range Size: 8 GB
Physical Device Handle: 0x0013
Memory Array Mapped Address Handle: 0x0016
Partition Row Position: 1
Interleaved Data Depth: 1
Handle 0x001D, DMI type 20, 19 bytes
Memory Device Mapped Address
Starting Address: 0x00BFFFFFC00
Ending Address: 0x00BFFFFFFFF
Range Size: 1 kB
Physical Device Handle: 0x0014
Memory Array Mapped Address Handle: 0x0016
Partition Row Position: 1
Interleaved Data Depth: 1
Handle 0x001E, DMI type 20, 19 bytes
Memory Device Mapped Address
Starting Address: 0x00BFFFFFC00
Ending Address: 0x00BFFFFFFFF
Range Size: 1 kB
Physical Device Handle: 0x0015
Memory Array Mapped Address Handle: 0x0016
Partition Row Position: 1
Interleaved Data Depth: 1
Handle 0x001F, DMI type 32, 20 bytes
System Boot Information
Status: <OUT OF SPEC>
Handle 0x0020, DMI type 38, 18 bytes
IPMI Device Information
Interface Type: KCS (Keyboard Control Style)
Specification Version: 2.0
I2C Slave Address: 0x10
NV Storage Device: Not Present
Base Address: 0x0000000000000CA8 (I/O)
Register Spacing: 32-bit Boundaries
Interrupt Polarity: Active Low
Interrupt Trigger Mode: Edge
Handle 0x0021, DMI type 127, 4 bytes
End Of Table
--
Arkadiusz Miśkiewicz PLD/Linux Team
arekm / maven.pl http://ftp.pld-linux.org/
^ permalink raw reply
* Re: [net-next 00/11 v2][pull request] Intel Wired LAN Driver Updates
From: Jeff Kirsher @ 2011-10-01 4:56 UTC (permalink / raw)
To: davem@davemloft.net; +Cc: netdev@vger.kernel.org, gospo@redhat.com
In-Reply-To: <1317444771-13962-1-git-send-email-jeffrey.t.kirsher@intel.com>
[-- Attachment #1: Type: text/plain, Size: 2384 bytes --]
On Fri, 2011-09-30 at 21:52 -0700, Kirsher, Jeffrey T wrote:
> The following series contains updates to e1000e and ixgbe. The one
> patch for e1000e makes function tables const, thanks to Stephen
> Hemminger for reporting this. The remaining patches are for ixgbe,
> and the contain the following:
>
> - minor cleanups
> - add support for 82599 device and ethtool -E support
> - removal of a PHY which is not used in production silicon
>
> v2- Updated patch 11 with the suggested changes from Ben Hutchings
>
> The following are changes since commit 56fd49e399ce1d82200fad5b8924d4e35a587809:
> bna: Driver Version changed to 3.0.2.2
> and are available in the git repository at
> git://github.com/Jkirsher/net-next.git
>
> Emil Tantilov (8):
> ixgbe: prevent link checks while resetting
> ixgbe: clear the data field in ixgbe_read_i2c_byte_generic
> ixgbe: remove return code for functions that always return 0
> ixgbe: add support for new 82599 device
> ixgbe: send MFLCN to ethtool
> ixgbe: do not disable flow control in ixgbe_check_mac_link
> ixgbe: remove instances of ixgbe_phy_aq for 82598 and 82599
> ixgbe: allow eeprom writes via ethtool
>
> Jacob Keller (1):
> ixgbe: fix driver version initialization in firmware
>
> Jeff Kirsher (1):
> e1000e: make function tables const
>
> Mika Lansirinne (1):
> ixgbe: get pauseparam autoneg
>
> drivers/net/ethernet/intel/e1000e/80003es2lan.c | 8 +-
> drivers/net/ethernet/intel/e1000e/82571.c | 20 +++---
> drivers/net/ethernet/intel/e1000e/e1000.h | 28 ++++----
> drivers/net/ethernet/intel/e1000e/ich8lan.c | 16 +++---
> drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c | 8 +--
> drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c | 7 +--
> drivers/net/ethernet/intel/ixgbe/ixgbe_common.c | 6 --
> drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 74 +++++++++++++++++++---
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 12 +++-
> drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c | 33 +++-------
> drivers/net/ethernet/intel/ixgbe/ixgbe_type.h | 1 +
> drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c | 1 +
> 12 files changed, 125 insertions(+), 89 deletions(-)
>
I did not re-send patches 1-10 of the series since there was no change.
I can re-send if necessary...
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* [net-next 11/11 v2] ixgbe: allow eeprom writes via ethtool
From: Jeff Kirsher @ 2011-10-01 4:52 UTC (permalink / raw)
To: davem; +Cc: Emil Tantilov, netdev, gospo, Jeff Kirsher
In-Reply-To: <1317444771-13962-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Emil Tantilov <emil.s.tantilov@intel.com>
Implement support for ethtool -E
v2- change 2 return values to EINVAL based on feedback
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
Tested-by: Stephen Ko <stephen.s.ko@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c | 1 +
drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 61 ++++++++++++++++++++++
2 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c
index e02e911..fff57a0 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c
@@ -1305,6 +1305,7 @@ static struct ixgbe_mac_operations mac_ops_82598 = {
static struct ixgbe_eeprom_operations eeprom_ops_82598 = {
.init_params = &ixgbe_init_eeprom_params_generic,
.read = &ixgbe_read_eerd_generic,
+ .write = &ixgbe_write_eeprom_generic,
.read_buffer = &ixgbe_read_eerd_buffer_generic,
.calc_checksum = &ixgbe_calc_eeprom_checksum_generic,
.validate_checksum = &ixgbe_validate_eeprom_checksum_generic,
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
index 10ea29f..fb47abb 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
@@ -812,6 +812,66 @@ static int ixgbe_get_eeprom(struct net_device *netdev,
return ret_val;
}
+static int ixgbe_set_eeprom(struct net_device *netdev,
+ struct ethtool_eeprom *eeprom, u8 *bytes)
+{
+ struct ixgbe_adapter *adapter = netdev_priv(netdev);
+ struct ixgbe_hw *hw = &adapter->hw;
+ u16 *eeprom_buff;
+ void *ptr;
+ int max_len, first_word, last_word, ret_val = 0;
+ u16 i;
+
+ if (eeprom->len == 0)
+ return -EINVAL;
+
+ if (eeprom->magic != (hw->vendor_id | (hw->device_id << 16)))
+ return -EINVAL;
+
+ max_len = hw->eeprom.word_size * 2;
+
+ first_word = eeprom->offset >> 1;
+ last_word = (eeprom->offset + eeprom->len - 1) >> 1;
+ eeprom_buff = kmalloc(max_len, GFP_KERNEL);
+ if (!eeprom_buff)
+ return -ENOMEM;
+
+ ptr = (void *)eeprom_buff;
+
+ if (eeprom->offset & 1) {
+ /*
+ * need read/modify/write of first changed EEPROM word
+ * only the second byte of the word is being modified
+ */
+ ret_val = hw->eeprom.ops.read(hw, first_word, &eeprom_buff[0]);
+ ptr++;
+ }
+ if (((eeprom->offset + eeprom->len) & 1) && (ret_val == 0)) {
+ /*
+ * need read/modify/write of last changed EEPROM word
+ * only the first byte of the word is being modified
+ */
+ ret_val = hw->eeprom.ops.read(hw, last_word,
+ &eeprom_buff[last_word - first_word]);
+ }
+
+ /* Device's eeprom is always little-endian, word addressable */
+ for (i = 0; i < last_word - first_word + 1; i++)
+ le16_to_cpus(&eeprom_buff[i]);
+
+ memcpy(ptr, bytes, eeprom->len);
+
+ for (i = 0; i <= (last_word - first_word); i++)
+ ret_val |= hw->eeprom.ops.write(hw, first_word + i,
+ eeprom_buff[i]);
+
+ /* Update the checksum */
+ hw->eeprom.ops.update_checksum(hw);
+
+ kfree(eeprom_buff);
+ return ret_val;
+}
+
static void ixgbe_get_drvinfo(struct net_device *netdev,
struct ethtool_drvinfo *drvinfo)
{
@@ -2526,6 +2586,7 @@ static const struct ethtool_ops ixgbe_ethtool_ops = {
.get_link = ethtool_op_get_link,
.get_eeprom_len = ixgbe_get_eeprom_len,
.get_eeprom = ixgbe_get_eeprom,
+ .set_eeprom = ixgbe_set_eeprom,
.get_ringparam = ixgbe_get_ringparam,
.set_ringparam = ixgbe_set_ringparam,
.get_pauseparam = ixgbe_get_pauseparam,
--
1.7.6.2
^ permalink raw reply related
* [net-next 00/11 v2][pull request] Intel Wired LAN Driver Updates
From: Jeff Kirsher @ 2011-10-01 4:52 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, gospo
The following series contains updates to e1000e and ixgbe. The one
patch for e1000e makes function tables const, thanks to Stephen
Hemminger for reporting this. The remaining patches are for ixgbe,
and the contain the following:
- minor cleanups
- add support for 82599 device and ethtool -E support
- removal of a PHY which is not used in production silicon
v2- Updated patch 11 with the suggested changes from Ben Hutchings
The following are changes since commit 56fd49e399ce1d82200fad5b8924d4e35a587809:
bna: Driver Version changed to 3.0.2.2
and are available in the git repository at
git://github.com/Jkirsher/net-next.git
Emil Tantilov (8):
ixgbe: prevent link checks while resetting
ixgbe: clear the data field in ixgbe_read_i2c_byte_generic
ixgbe: remove return code for functions that always return 0
ixgbe: add support for new 82599 device
ixgbe: send MFLCN to ethtool
ixgbe: do not disable flow control in ixgbe_check_mac_link
ixgbe: remove instances of ixgbe_phy_aq for 82598 and 82599
ixgbe: allow eeprom writes via ethtool
Jacob Keller (1):
ixgbe: fix driver version initialization in firmware
Jeff Kirsher (1):
e1000e: make function tables const
Mika Lansirinne (1):
ixgbe: get pauseparam autoneg
drivers/net/ethernet/intel/e1000e/80003es2lan.c | 8 +-
drivers/net/ethernet/intel/e1000e/82571.c | 20 +++---
drivers/net/ethernet/intel/e1000e/e1000.h | 28 ++++----
drivers/net/ethernet/intel/e1000e/ich8lan.c | 16 +++---
drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c | 8 +--
drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c | 7 +--
drivers/net/ethernet/intel/ixgbe/ixgbe_common.c | 6 --
drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 74 +++++++++++++++++++---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 12 +++-
drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c | 33 +++-------
drivers/net/ethernet/intel/ixgbe/ixgbe_type.h | 1 +
drivers/net/ethernet/intel/ixgbe/ixgbe_x540.c | 1 +
12 files changed, 125 insertions(+), 89 deletions(-)
--
1.7.6.2
^ permalink raw reply
* [PATCH 2/2] IPVS: Enhance grammar used to refer to Kconfig options
From: Simon Horman @ 2011-10-01 3:34 UTC (permalink / raw)
To: Patrick McHardy, Pablo Neira Ayuso
Cc: lvs-devel, netdev, netfilter-devel, Wensong Zhang,
Julian Anastasov, Simon Horman
In-Reply-To: <1317440059-31112-1-git-send-email-horms@verge.net.au>
Reported-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
Documentation/networking/ipvs-sysctl.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/networking/ipvs-sysctl.txt b/Documentation/networking/ipvs-sysctl.txt
index 13610e3..f2a2488 100644
--- a/Documentation/networking/ipvs-sysctl.txt
+++ b/Documentation/networking/ipvs-sysctl.txt
@@ -30,7 +30,7 @@ conntrack - BOOLEAN
Connections handled by the IPVS FTP application module
will have connection tracking entries regardless of this setting.
- Only available when IPVS is compiled with the CONFIG_IP_VS_NFCT
+ Only available when IPVS is compiled with CONFIG_IP_VS_NFCT enabled.
cache_bypass - BOOLEAN
0 - disabled (default)
@@ -56,7 +56,7 @@ debug_level - INTEGER
11 - IPVS packet handling (ip_vs_in/ip_vs_out)
12 or more - packet traversal
- Only available when IPVS is compiled with the CONFIG_IP_VS_DEBUG
+ Only available when IPVS is compiled with CONFIG_IP_VS_DEBUG enabled.
Higher debugging levels include the messages for lower debugging
levels, so setting debug level 2, includes level 0, 1 and 2
--
1.7.5.4
^ permalink raw reply related
* [PATCH 1/2] IPVS: secure_tcp does provide alternate state timeouts
From: Simon Horman @ 2011-10-01 3:34 UTC (permalink / raw)
To: Patrick McHardy, Pablo Neira Ayuso
Cc: lvs-devel, netdev, netfilter-devel, Wensong Zhang,
Julian Anastasov, Simon Horman
In-Reply-To: <1317440059-31112-1-git-send-email-horms@verge.net.au>
* Also reword the test to make it read more easily (to me)
Signed-off-by: Simon Horman <horms@verge.net.au>
---
Julian, I don't see that IPVS currently implements alternate
timeouts for secure_tcp. Am I missing something?
---
Documentation/networking/ipvs-sysctl.txt | 10 ++++------
1 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/Documentation/networking/ipvs-sysctl.txt b/Documentation/networking/ipvs-sysctl.txt
index 1dcdd49..13610e3 100644
--- a/Documentation/networking/ipvs-sysctl.txt
+++ b/Documentation/networking/ipvs-sysctl.txt
@@ -140,13 +140,11 @@ nat_icmp_send - BOOLEAN
secure_tcp - INTEGER
0 - disabled (default)
- The secure_tcp defense is to use a more complicated state
- transition table and some possible short timeouts of each
- state. In the VS/NAT, it delays the entering the ESTABLISHED
- until the real server starts to send data and ACK packet
- (after 3-way handshake).
+ The secure_tcp defense is to use a more complicated TCP state
+ transition table. For VS/NAT, it also delays entering the
+ TCP ESTABLISHED state until the three way handshake is completed.
- The value definition is the same as that of drop_entry or
+ The value definition is the same as that of drop_entry and
drop_packet.
sync_threshold - INTEGER
--
1.7.5.4
^ permalink raw reply related
* [GIT PULL nf-next] IPVS
From: Simon Horman @ 2011-10-01 3:34 UTC (permalink / raw)
To: Patrick McHardy, Pablo Neira Ayuso
Cc: lvs-devel, netdev, netfilter-devel, Wensong Zhang,
Julian Anastasov
Hi Pablo,
please consider pulling the following to get some
documentation changes from myself.
The following changes since commit 6fa4dec85e199f31774faf29be26a53329d02e9e:
ipvs: Removed unused variables (2011-09-28 21:09:24 +0200)
are available in the git repository at:
git@github.com:horms/ipvs-next.git master
Simon Horman (2):
IPVS: secure_tcp does provide alternate state timeouts
IPVS: Enhance grammar used to refer to Kconfig options
Documentation/networking/ipvs-sysctl.txt | 14 ++++++--------
1 files changed, 6 insertions(+), 8 deletions(-)
^ permalink raw reply
* Re: ICMP redirect issue
From: Simon Horman @ 2011-10-01 3:22 UTC (permalink / raw)
To: David Miller; +Cc: fbl, netdev
In-Reply-To: <20110928.191255.1803703769504267178.davem@davemloft.net>
On Wed, Sep 28, 2011 at 07:12:55PM -0400, David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Wed, 28 Sep 2011 18:56:54 -0400 (EDT)
>
> > From: Flavio Leitner <fbl@redhat.com>
> > Date: Wed, 28 Sep 2011 17:19:52 -0300
> >
> >> What about something like below? It will change a bit the
> >> secure_redirects documentation.
> >
> > The previous check was stronger, and served other purposes.
> >
> > Firstly, it required that the spoofer know the exact gateway
> > IP address we used previously, whereas your test requires only
> > knowing the subnet which is easier to figure out.
> >
> > But more importantly, the old test allowed us to ignore outdated
> > or erroneous redirects.
> >
> > We really have to restore the original behavior before my inetpeer
> > changes (enforce that the old gateway matches), and find another way
> > to accomodate IPVS.
>
> BTW, I just double-checked RFC1122 and it explicitly specifies the
> old_gw check:
>
> [ RFC1122, section 3.2.2.2 ]
>
> ...
>
> A Redirect message SHOULD be silently discarded if the new
> gateway address it specifies is not on the same connected
> (sub-) net through which the Redirect arrived [INTRO:2,
> Appendix A], or if the source of the Redirect is not the
> current first-hop gateway for the specified destination (see
> Section 3.3.1).
>
> In fact, it's saying that we should also validate that saddr == old_gw
> too.
>
> So really, we need to put the check back and find a way to accomodate IPVS.
Hi Dave,
I'm have to admit that this issues is new to me.
But doesn't it affect any setup where a secondary
address is being used as the gateway and the gateway
send an ICMP redirect?
Perhaps an option to weaken the check for these cases
would provide a work-around for those who need it.
Or does that break your inetpeer changes horribly?
^ permalink raw reply
* (unknown),
From: FEDEX OFFICE @ 2011-10-01 2:08 UTC (permalink / raw)
Attn: Beneficiary,
This is to inform you that your package worth the sum of $800,000.00 (Eight
Hundred Thousand United State Dollars) in a certified bank draft is in our
office ready for delivery,We are sending you this email because your package
has been registered on a Special Order.You are advise to contact our Delivery
Department for immediate dispatch of your package to your designated address.
Regards
Mr.Umar Tony {Head Dispatch Officer}
FedEx Express ®Courier Company West-Africa
E-mail:fedexdelivery1952@msn.com
Telephone Number:+234-70-65749930
---------------------------------------------------------------------------------
www.galiciaaberta.com
Información mantida pola Secretaría Xeral de Emigración da Xunta de Galicia
^ permalink raw reply
* [PATCH] bluetooth: macroize two small inlines to avoid module.h
From: Paul Gortmaker @ 2011-10-01 2:12 UTC (permalink / raw)
To: marcel-kz+m5ild9QBg9hUCZPvPmw, padovan-Y3ZbgMPKUGA34EUeqzHoZw
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA, Paul Gortmaker
These two small inlines make calls to try_module_get() and
module_put() which would force us to keep module.h present
within yet another common include header. We can avoid this
by turning them into macros. The hci_dev_hold construct
is patterned off of raw_spin_trylock_irqsave() in spinlock.h
Signed-off-by: Paul Gortmaker <paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ@public.gmane.org>
---
[This is something I've added to the module.h cleanup tree since
the original module.h cleanup RFC patchset; sending here just for
transparency and for any review comments.]
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 8f441b8..9a77e8a 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -498,11 +498,15 @@ static inline void __hci_dev_put(struct hci_dev *d)
d->destruct(d);
}
-static inline void hci_dev_put(struct hci_dev *d)
-{
- __hci_dev_put(d);
- module_put(d->owner);
-}
+/*
+ * hci_dev_put and hci_dev_hold are macros to avoid dragging all the
+ * overhead of all the modular infrastructure into this header.
+ */
+#define hci_dev_put(d) \
+do { \
+ __hci_dev_put(d); \
+ module_put(d->owner); \
+} while (0)
static inline struct hci_dev *__hci_dev_hold(struct hci_dev *d)
{
@@ -510,12 +514,10 @@ static inline struct hci_dev *__hci_dev_hold(struct hci_dev *d)
return d;
}
-static inline struct hci_dev *hci_dev_hold(struct hci_dev *d)
-{
- if (try_module_get(d->owner))
- return __hci_dev_hold(d);
- return NULL;
-}
+#define hci_dev_hold(d) \
+({ \
+ try_module_get(d->owner) ? __hci_dev_hold(d) : NULL; \
+})
#define hci_dev_lock(d) spin_lock(&d->lock)
#define hci_dev_unlock(d) spin_unlock(&d->lock)
--
1.7.6
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox