* Re: txqueuelen has wrong units; should be time
From: Mikael Abrahamsson @ 2011-03-02 6:41 UTC (permalink / raw)
To: Stephen Hemminger
Cc: John Heffner, Bill Sommerfeld, Hagen Paul Pfeifer, Albert Cahalan,
Jussi Kivilinna, Eric Dumazet, linux-kernel, netdev
In-Reply-To: <20110301222531.24832a93@nehalam>
On Tue, 1 Mar 2011, Stephen Hemminger wrote:
> It is possible to build an equivalent to WRED out existing GRED queuing
> discipline but it does require a lot of tc knowledge to get right.
To me who has worked with cisco routers for 10+ years and who is used to
the different variants Cisco use, tc is just weird. It must come from a
completely different school of thinking compared to what router people are
used to, because I have tried and failed twice to do anything sensible
with it.
> The inventor of RED (Van Jacobsen) has issues with WRED because of the
> added complexity of queue selection. RED requires some parameters which
> the average user has no idea how to set.
Of course there are issues and some of them can be adressed by simply
lowering the queue depth. Yes, that might bring down the performance of
some sessions, but for most of the interactive traffic, never buffering
more than 40ms is a good thing.
> There are several problems with RED that prevent prevent VJ from
> recommending it in the current form.
Ask if he prefers FIFO+tail drop to RED in current form.
--
Mikael Abrahamsson email: swmike@swm.pp.se
^ permalink raw reply
* Re: [PATCH net-next] pfkey: fix warning
From: David Miller @ 2011-03-02 6:52 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20110301223913.2caf53c3@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Tue, 1 Mar 2011 22:39:13 -0800
> If CONFIG_NET_KEY_MIGRATE is not defined the arguments of
> pfkey_migrate stub do not match causing warning.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied, thanks!
^ permalink raw reply
* Re: inet: Replace left-over references to inet->cork
From: David Miller @ 2011-03-02 7:01 UTC (permalink / raw)
To: herbert; +Cc: rick.jones2, therbert, wsommerfeld, daniel.baluta, netdev, tgraf
In-Reply-To: <20110302061517.GA17891@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Wed, 2 Mar 2011 14:15:17 +0800
> On Tue, Mar 01, 2011 at 08:36:47PM +0800, Herbert Xu wrote:
>> inet: Remove explicit write references to sk/inet in ip_append_data
>
> Just found a couple of spots where inet->cork was still used
> instead of just cork.
>
> inet: Replace left-over references to inet->cork
Applied, thanks Herbert.
^ permalink raw reply
* Re: [Bug-Fix][Patch 1/1] dccp: fix oops on Reset after close
From: David Miller @ 2011-03-02 7:02 UTC (permalink / raw)
To: gerrit; +Cc: netdev, jhovold
In-Reply-To: <20110302063447.GB4902@gerrit.erg.abdn.ac.uk>
From: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Date: Wed, 2 Mar 2011 07:34:47 +0100
> could you please apply the below bug fix for a condition where a simple packet
> reception can trigger oops.
Applied, thanks Gerrit.
^ permalink raw reply
* Re: [PATCH] ipv6: Make icmp route lookup code a bit clearer.
From: Herbert Xu @ 2011-03-02 7:02 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20110301.221543.226770795.davem@davemloft.net>
On Tue, Mar 01, 2011 at 10:15:43PM -0800, David Miller wrote:
>
> The route lookup code in icmpv6_send() is slightly tricky as a result of
> having to handle all of the requirements of RFC 4301 host relookups.
>
> Pull the route resolution into a seperate function, so that the error
> handling and route reference counting is hopefully easier to see and
> contained wholly within this new routine.
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
Looks good to me too.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: txqueuelen has wrong units; should be time
From: Stephen Hemminger @ 2011-03-02 7:07 UTC (permalink / raw)
To: Mikael Abrahamsson
Cc: John Heffner, Bill Sommerfeld, Hagen Paul Pfeifer, Albert Cahalan,
Jussi Kivilinna, Eric Dumazet, linux-kernel, netdev
In-Reply-To: <alpine.DEB.1.10.1103020736260.7942@uplift.swm.pp.se>
On Wed, 2 Mar 2011 07:41:30 +0100 (CET)
Mikael Abrahamsson <swmike@swm.pp.se> wrote:
> On Tue, 1 Mar 2011, Stephen Hemminger wrote:
>
> > It is possible to build an equivalent to WRED out existing GRED queuing
> > discipline but it does require a lot of tc knowledge to get right.
>
> To me who has worked with cisco routers for 10+ years and who is used to
> the different variants Cisco use, tc is just weird. It must come from a
> completely different school of thinking compared to what router people are
> used to, because I have tried and failed twice to do anything sensible
> with it.
Vyatta has scripting that handles all that:
vyatta@napa:~$ configure
[edit]
yatta@napa# set traffic-policy random-detect MyWFQ bandwidth 1gbps
[edit]
vyatta@napa# set interfaces ethernet eth0 traffic-policy out MyWFQ
[edit]
vyatta@napa# commit
[edit]
vyatta@napa# exit
vyatta@napa:~$ show queueing ethernet eth0
eth0 Queueing:
Class Policy Sent Rate Dropped Overlimit Backlog
root weighted-random 16550 0 0 0
vyatta@napa:~$ /sbin/tc qdisc show dev eth0
qdisc dsmark 1: root refcnt 2 indices 0x0008 set_tc_index
qdisc gred 2: parent 1:
DP:0 (prio 8) Average Queue 0b Measured Queue 0b
Packet drops: 0 (forced 0 early 0)
Packet totals: 82 (bytes 9540) ewma 3 Plog 17 Scell_log 3
DP:1 (prio 7) Average Queue 0b Measured Queue 0b
Packet drops: 0 (forced 0 early 0)
Packet totals: 0 (bytes 0) ewma 2 Plog 17 Scell_log 2
DP:2 (prio 6) Average Queue 0b Measured Queue 0b
Packet drops: 0 (forced 0 early 0)
Packet totals: 0 (bytes 0) ewma 2 Plog 17 Scell_log 2
DP:3 (prio 5) Average Queue 0b Measured Queue 0b
Packet drops: 0 (forced 0 early 0)
Packet totals: 0 (bytes 0) ewma 2 Plog 16 Scell_log 2
DP:4 (prio 4) Average Queue 0b Measured Queue 0b
Packet drops: 0 (forced 0 early 0)
Packet totals: 0 (bytes 0) ewma 2 Plog 16 Scell_log 2
DP:5 (prio 3) Average Queue 0b Measured Queue 0b
Packet drops: 0 (forced 0 early 0)
Packet totals: 0 (bytes 0) ewma 2 Plog 16 Scell_log 2
DP:6 (prio 2) Average Queue 0b Measured Queue 0b
Packet drops: 0 (forced 0 early 0)
Packet totals: 0 (bytes 0) ewma 2 Plog 15 Scell_log 2
DP:7 (prio 1) Average Queue 0b Measured Queue 0b
Packet drops: 0 (forced 0 early 0)
Packet totals: 0 (bytes 0) ewma 1 Plog 15 Scell_log 1
QoS on Cisco has different/other problems mostly because various groups
tried to fix the QoS problem over time and never got it quite right.
Also WRED is not default on faster links because it can't be done
fast enough.
^ permalink raw reply
* Re: net-next: warnings from sysctl_net_exit
From: Stephen Hemminger @ 2011-03-02 7:09 UTC (permalink / raw)
To: Lucian Adrian Grijincu; +Cc: David S. Miller, netdev
In-Reply-To: <AANLkTinL3UhjOtmr3uyEkSiDT5NFJo=FbG5mKm3XaU8R@mail.gmail.com>
On Mon, 28 Feb 2011 03:11:46 +0200
Lucian Adrian Grijincu <lucian.grijincu@gmail.com> wrote:
> On Mon, Feb 28, 2011 at 2:08 AM, Stephen Hemminger
> <shemminger@vyatta.com> wrote:
> >> The check is triggered at network namespace deletion, so a moment
> >> before deleting the netns should be fine.
> >
> > Although the kernel was compiled with netns, I never use net namespaces.
>
>
> This can be triggered at shutdown when the init_net network namespace
> is dismantled.
>
> Are you getting this at shutdown time? If not, is it easily reproducible?
> Can you post a .config?
>
It seems to happen right after ip6tables starts at boot.
I added more backtrace info to walk the list of remaining entries,
and got this but it doesn't help much.
[ 59.700687] ip6_tables: (C) 2000-2006 Netfilter Core Team
[ 60.413111] header=ffff8803239db000 count=1 used=0 unregistering= (null)
[ 60.413113] procname=net
[ 60.413115] ------------[ cut here ]------------
[ 60.413119] WARNING: at net/sysctl_net.c:98 sysctl_net_exit+0x94/0x9d()
[ 60.413121] Hardware name: System Product Name
[ 60.413122] Modules linked in: ip6table_filter ip6_tables nfs lockd fscache nfs_acl auth_rpcgss sunrpc binfmt_misc ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge stp llc kvm_intel kvm snd_hda_codec_analog lm63 radeon snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq ttm psmouse snd_timer drm_kms_helper serio_raw snd_seq_device pl2303 usbserial snd drm soundcore i7core_edac snd_page_alloc edac_core asus_atk0110 i2c_algo_bit hid_belkin usbhid hid pata_marvell ahci sky2 libahci igb e1000e dca floppy btrfs lzo_compress zlib_deflate crc32c libcrc32c
[ 60.413170] Pid: 67, comm: kworker/u:5 Not tainted 2.6.38-rc5-net-next+ #19
[ 60.413171] Call Trace:
[ 60.413176] [<ffffffff81040dce>] ? warn_slowpath_common+0x85/0x9d
[ 60.413180] [<ffffffff8136183a>] ? cleanup_net+0x0/0x19a
[ 60.413182] [<ffffffff81040e00>] ? warn_slowpath_null+0x1a/0x1c
[ 60.413184] [<ffffffff81414ebb>] ? sysctl_net_exit+0x94/0x9d
[ 60.413187] [<ffffffff81361492>] ? ops_exit_list+0x2a/0x5b
[ 60.413189] [<ffffffff81361934>] ? cleanup_net+0xfa/0x19a
[ 60.413193] [<ffffffff810575bd>] ? process_one_work+0x233/0x3aa
[ 60.413196] [<ffffffff81057524>] ? process_one_work+0x19a/0x3aa
[ 60.413199] [<ffffffff810599be>] ? worker_thread+0x13b/0x25a
[ 60.413201] [<ffffffff81059883>] ? worker_thread+0x0/0x25a
[ 60.413204] [<ffffffff8105d0f1>] ? kthread+0x9d/0xa5
[ 60.413207] [<ffffffff8106d614>] ? trace_hardirqs_on_caller+0x10c/0x130
[ 60.413210] [<ffffffff810030d4>] ? kernel_thread_helper+0x4/0x10
[ 60.413215] [<ffffffff8142ed40>] ? restore_args+0x0/0x30
[ 60.413217] [<ffffffff8105d054>] ? kthread+0x0/0xa5
[ 60.413219] [<ffffffff810030d0>] ? kernel_thread_helper+0x0/0x10
[ 60.413221] ---[ end trace 9b655d61bf30c4f8 ]---
^ permalink raw reply
* Re: SO_REUSEPORT - can it be done in kernel?
From: Tom Herbert @ 2011-03-02 7:12 UTC (permalink / raw)
To: Herbert Xu
Cc: Eric Dumazet, Thomas Graf, David Miller, rick.jones2, wsommerfeld,
daniel.baluta, netdev
In-Reply-To: <20110302023920.GA16072@gondor.apana.org.au>
On Tue, Mar 1, 2011 at 6:39 PM, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Wed, Mar 02, 2011 at 03:00:03AM +0100, Eric Dumazet wrote:
>> >
>> > Think about it, a TCP socket cannot be used by a multi-threaded app
>> > in a scalable way.
>>
>> Well...
>>
>> If you think about it, SO_REUSEPORT patch has exactly the same goal :
>
In a sense. SO_RESUSEPORT for TCP is intended to provide a scalable
listener solution. Sharing an established socket is not very
efficient, something like a multiplexing socket layer on top of TCP
might be good.
> UDP is a datagram protocol, TCP is not.
>
> Anyway, here is an alternate proposal. When a TCP socket transmits
> for the first time (SYN or SYN-ACK), we pick a queue based on CPU and
> store it in the socket. From then on we stick to that selection.
>
> We would only allow changes if we can ensure that all transmitted
> packets have left the queue. Or we just never change it like we
> do now.
>
XPS does all this already.
> For datagram protocols we simply use the current CPU.
>
Probably need to set skb->ooo_okay (for UDP etc.) also so that XPS
will change queues.
Tom
^ permalink raw reply
* Re: [PATCH 1/2] tlan: Remove changelog
From: Sakari Ailus @ 2011-03-02 7:13 UTC (permalink / raw)
To: Joe Perches; +Cc: Samuel Chessman, netdev, linux-kernel
In-Reply-To: <901ce76108a5ab7327159b57a1b8c9283673532b.1298998514.git.joe@perches.com>
Joe Perches wrote:
> As it isn't necessary nor really useful any longer.
>
> Signed-off-by: Joe Perches<joe@perches.com>
Thanks, Joe!
I had your patches still but have had practically no time since you sent
your last set. So, for both:
Acked-by: Sakari Ailus <sakari.ailus@iki.fi>
--
Sakari Ailus
sakari.ailus@iki.fi
^ permalink raw reply
* Re: [PATCH v2] net: don't allow CAP_NET_ADMIN to load non-netdev kernel modules
From: Michael Tokarev @ 2011-03-02 7:15 UTC (permalink / raw)
To: Vasiliy Kulikov
Cc: linux-kernel, arnd, mirqus, netdev, Ben Hutchings, David Miller,
kuznet, pekkas, jmorris, yoshfuji, kaber, eric.dumazet, therbert,
xiaosuo, jesse, kees.cook, eugene, dan.j.rosenberg, akpm
In-Reply-To: <20110301213313.GA6507@albatros>
02.03.2011 00:33, Vasiliy Kulikov wrote:
> Since a8f80e8ff94ecba629542d9b4b5f5a8ee3eb565c any process with
> CAP_NET_ADMIN may load any module from /lib/modules/. This doesn't mean
> that CAP_NET_ADMIN is a superset of CAP_SYS_MODULE as modules are
> limited to /lib/modules/**. However, CAP_NET_ADMIN capability shouldn't
> allow anybody load any module not related to networking.
>
> This patch restricts an ability of autoloading modules to netdev modules
> with explicit aliases. This fixes CVE-2011-1019.
[]
> Reference: https://lkml.org/lkml/2011/2/24/203
>
> Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
This looks much saner :)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
/mjt
^ permalink raw reply
* Re: SO_REUSEPORT - can it be done in kernel?
From: Herbert Xu @ 2011-03-02 7:31 UTC (permalink / raw)
To: Tom Herbert
Cc: Eric Dumazet, Thomas Graf, David Miller, rick.jones2, wsommerfeld,
daniel.baluta, netdev
In-Reply-To: <AANLkTim0+7mTYrQF3mttUW+JqOmvTyMoDXOdeCX_SSdp@mail.gmail.com>
On Tue, Mar 01, 2011 at 11:12:29PM -0800, Tom Herbert wrote:
>
> Probably need to set skb->ooo_okay (for UDP etc.) also so that XPS
> will change queues.
Hmm, not quite. We still want to maintain packet ordering from
the same CPU. That is, if I do two sendmsg calls from the same
CPU, they should go into the same queue in that order.
So this shouldn't just be a knob that says whether we can pick
queues at random.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: SO_REUSEPORT - can it be done in kernel?
From: Eric Dumazet @ 2011-03-02 8:04 UTC (permalink / raw)
To: Herbert Xu
Cc: Tom Herbert, Thomas Graf, David Miller, rick.jones2, wsommerfeld,
daniel.baluta, netdev
In-Reply-To: <20110302073123.GA18443@gondor.apana.org.au>
Le mercredi 02 mars 2011 à 15:31 +0800, Herbert Xu a écrit :
> On Tue, Mar 01, 2011 at 11:12:29PM -0800, Tom Herbert wrote:
> >
> > Probably need to set skb->ooo_okay (for UDP etc.) also so that XPS
> > will change queues.
>
> Hmm, not quite. We still want to maintain packet ordering from
> the same CPU. That is, if I do two sendmsg calls from the same
> CPU, they should go into the same queue in that order.
>
> So this shouldn't just be a knob that says whether we can pick
> queues at random.
>
Not sure why two UDP packets from the same cpu should be sent on same
queue.
- Some qdisc do reorder packets anyway.
- Some bonding setups use two links in round-robin mode (link
aggregation)
^ permalink raw reply
* Re: SO_REUSEPORT - can it be done in kernel?
From: Herbert Xu @ 2011-03-02 8:07 UTC (permalink / raw)
To: Eric Dumazet
Cc: Tom Herbert, Thomas Graf, David Miller, rick.jones2, wsommerfeld,
daniel.baluta, netdev
In-Reply-To: <1299053048.2930.85.camel@edumazet-laptop>
On Wed, Mar 02, 2011 at 09:04:08AM +0100, Eric Dumazet wrote:
>
> Not sure why two UDP packets from the same cpu should be sent on same
> queue.
>
> - Some qdisc do reorder packets anyway.
Which qdisc reorders packets belonging to the same flow?
> - Some bonding setups use two links in round-robin mode (link
> aggregation)
Just because the Internet may reorder things doesn't mean that
we should.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: SO_REUSEPORT - can it be done in kernel?
From: Eric Dumazet @ 2011-03-02 8:24 UTC (permalink / raw)
To: Herbert Xu
Cc: Tom Herbert, Thomas Graf, David Miller, rick.jones2, wsommerfeld,
daniel.baluta, netdev
In-Reply-To: <20110302080723.GA18773@gondor.apana.org.au>
Le mercredi 02 mars 2011 à 16:07 +0800, Herbert Xu a écrit :
> On Wed, Mar 02, 2011 at 09:04:08AM +0100, Eric Dumazet wrote:
> >
> > Not sure why two UDP packets from the same cpu should be sent on same
> > queue.
> >
> > - Some qdisc do reorder packets anyway.
>
> Which qdisc reorders packets belonging to the same flow?
>
Hmm to be fair you did not specified "same flow", and /sbin/named
answers are usually one packet long...
How are we going to detect flows in sendto() calls ?
Just kidding.
If you want to push your patch, I suspect a dynamic per_cpu variable is
needed per TX-multiqueue device, so that "current cpu -> txq number" is
one instruction.
^ permalink raw reply
* Re: [PATCH] bonding: added 802.3ad round-robin hashing policy and source mac selection mode
From: Oleg V. Ukhno @ 2011-03-02 9:15 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: Stephen Hemminger, netdev, David S. Miller
In-Reply-To: <413.1299034578@death>
On 03/02/2011 05:56 AM, Jay Vosburgh wrote:
> Stephen Hemminger<shemminger@vyatta.com> wrote:
>
>> On Wed, 2 Mar 2011 01:34:58 +0300
>> "Oleg V. Ukhno"<olegu@yandex-team.ru> wrote:
>>
>>
>> It seems to me the whole bonding policy is getting so complex
>> that the code is a mess. Perhaps it should be somehow linked into
>> existing packet classification or firewall mechanisms. This would
>> increase the flexibility and reduce the amount of policy code
>> in the bonding driver itself.
>
> Hmm.
>
> Yes, the number of special case knobs in bonding is getting
> rather large, and there are one or two other proposals in the pipe
> besides this one.
>
> It would be handy to be able to do things like run ebtables
> style rules against traffic going in and out of the bond. Right now
> ebtables is pretty tightly coupled with the bridge, so we'd need to add
> a whole new set of netfilter "bondtables" or something. Or add hooks
> for ebtables outside of the bridge.
>
> For this particular patch, the src-mac business could be handled
> by a netfilter module. The round-robin hash policy part would probably
> have to stay in bonding.
>
> -J
>
> ---
> -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
>
I am sorry, but I disagree with you, although it is possible to use
ebtables as a general mechanism to alter L2 headers.
It seems to be possible(never did so) to use ebtables for altering
src-mac field for outgoing packets, but is is done in iptables/ipchains
manner - with manual configuration - and requires to know all the
mac-address - interface bindings.
My point in collecting all this stuff in bonding module was :
- make bonding configuration with src-mac subtitution as simple as
possible, which reduces choice of human error when mantaining 100+
server deployments
- make configuration equally simple for any number of slaves and allow
simple slave addon/removal
- eliminate need for tracking hwaddress changes when replacing network
cards/server body.
- although I've never really used ebtables in my production, my
experience with iptables (this may not be true for all cases or may be
true for lesser part) tells me that using quite complex set of rules to
analyze and alter packets will introduce excessive CPU and latency
penalties, which will possibly cause (much?) worse packet reordering as
it is for this patch.
- one important thing for me (maybe it is not always true) - simplicity
of debugging any network problems with this kind of port-teaming.
--
Best regards,
Oleg Ukhno
^ permalink raw reply
* Re: fcoe: correct checking for bonding
From: Jiri Pirko @ 2011-03-02 9:55 UTC (permalink / raw)
To: linux-scsi, davem; +Cc: devel, robert.w.love, netdev, fubar, joe.eykholt
In-Reply-To: <20110302060535.GA2829@psychotron.redhat.com>
Or perhaps this should be applied to net-next?
Wed, Mar 02, 2011 at 07:05:35AM CET, jpirko@redhat.com wrote:
>Check for bonding master and refuse to use that.
>
>Signed-off-by: Jiri Pirko <jpirko@redhat.com>
>---
> drivers/scsi/fcoe/fcoe.c | 4 +---
> 1 files changed, 1 insertions(+), 3 deletions(-)
>
>diff --git a/drivers/scsi/fcoe/fcoe.c b/drivers/scsi/fcoe/fcoe.c
>index 9f9600b..3becc6a 100644
>--- a/drivers/scsi/fcoe/fcoe.c
>+++ b/drivers/scsi/fcoe/fcoe.c
>@@ -285,9 +285,7 @@ static int fcoe_interface_setup(struct fcoe_interface *fcoe,
> }
>
> /* Do not support for bonding device */
>- if ((netdev->priv_flags & IFF_MASTER_ALB) ||
>- (netdev->priv_flags & IFF_SLAVE_INACTIVE) ||
>- (netdev->priv_flags & IFF_MASTER_8023AD)) {
>+ if (netdev->priv_flags & IFF_BONDING && netdev->flags & IFF_MASTER) {
> FCOE_NETDEV_DBG(netdev, "Bonded interfaces not supported\n");
> return -EOPNOTSUPP;
> }
>--
>1.7.3.4
>
^ permalink raw reply
* Re: [patch net-next-2.6] bonding: remove skb_share_check in handle_frame
From: Jiri Pirko @ 2011-03-02 10:03 UTC (permalink / raw)
To: Andy Gospodarek; +Cc: netdev, davem, fubar, eric.dumazet, nicolas.2p.debian
In-Reply-To: <20110301203843.GN11864@gospo.rdu.redhat.com>
Tue, Mar 01, 2011 at 09:38:43PM CET, andy@greyhouse.net wrote:
>On Tue, Mar 01, 2011 at 10:29:07AM +0100, Jiri Pirko wrote:
>> Unapplicable, sorry (wrong branch :(). Here's corrected patch:
>>
>> Subject: [PATCH net-next-2.6 v2] bonding: remove skb_share_check in handle_frame
>>
>> No need to do share check here.
>>
>> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
>> ---
>> drivers/net/bonding/bond_main.c | 3 ---
>> 1 files changed, 0 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>> index 584f97b..367ea60 100644
>> --- a/drivers/net/bonding/bond_main.c
>> +++ b/drivers/net/bonding/bond_main.c
>> @@ -1498,9 +1498,6 @@ static struct sk_buff *bond_handle_frame(struct sk_buff *skb)
>> struct net_device *slave_dev;
>> struct net_device *bond_dev;
>>
>> - skb = skb_share_check(skb, GFP_ATOMIC);
>> - if (unlikely(!skb))
>> - return NULL;
>> slave_dev = skb->dev;
>> bond_dev = ACCESS_ONCE(slave_dev->master);
>> if (unlikely(!bond_dev))
>> --
>> 1.7.3.4
>>
>
>Why did you decide to get rid of it here rather than the 3 places in the
>bonding driver where it is currently needed? I think this can cover
>those cases since bond_handle_frame will be called after the ptype_all
>handlers before any of the ptype handlers.
I have already a patch prepared which converts bond ptype handlers into
being called from bond_handle_frame. You are propably right that this
should probably stay here.
So please Dave, drop this patch for now. Thanks.
^ permalink raw reply
* Re: [PATCH 2/3] [RFC] Changes for MQ virtio-net
From: Michael S. Tsirkin @ 2011-03-02 10:06 UTC (permalink / raw)
To: Krishna Kumar2
Cc: anthony, arnd, avi, davem, eric.dumazet, horms, kvm, netdev,
rusty
In-Reply-To: <OF2E9005A4.28D2C8A6-ON65257846.0054C7BB-65257846.00580600@in.ibm.com>
On Tue, Mar 01, 2011 at 09:32:56PM +0530, Krishna Kumar2 wrote:
> "Michael S. Tsirkin" <mst@redhat.com> wrote on 02/28/2011 03:13:20 PM:
>
> Thank you once again for your feedback on both these patches.
> I will send the qemu patch tomorrow. I will also send the next
> version incorporating these suggestions once we finalize some
> minor points.
>
> > Overall looks good.
> > The numtxqs meaning the number of rx queues needs some cleanup.
> > init/cleanup routines need more symmetry.
> > Error handling on setup also seems slightly buggy or at least
> asymmetrical.
> > Finally, this will use up a large number of MSI vectors,
> > while TX interrupts mostly stay unused.
> >
> > Some comments below.
> >
> > > +/* Maximum number of individual RX/TX queues supported */
> > > +#define VIRTIO_MAX_TXQS 16
> > > +
> >
> > This also does not seem to belong in the header.
>
> Both virtio-net and vhost need some check to make sure very
> high values are not passed by userspace. Is this not required?
Whatever we stick in the header is effectively part of
host/gues interface. Are you sure we'll never want
more than 16 VQs? This value does not seem that high.
> > > +#define VIRTIO_NET_F_NUMTXQS 21 /* Device supports multiple
> TX queue */
> >
> > VIRTIO_NET_F_MULTIQUEUE ?
>
> Yes, that's a better name.
>
> > > @@ -34,6 +38,8 @@ struct virtio_net_config {
> > > __u8 mac[6];
> > > /* See VIRTIO_NET_F_STATUS and VIRTIO_NET_S_* above */
> > > __u16 status;
> > > + /* number of RX/TX queues */
> > > + __u16 numtxqs;
> >
> > The interface here is a bit ugly:
> > - this is really both # of tx and rx queues but called numtxqs
> > - there's a hardcoded max value
> > - 0 is assumed to be same as 1
> > - assumptions above are undocumented.
> >
> > One way to address this could be num_queue_pairs, and something like
> > /* The actual number of TX and RX queues is num_queue_pairs +
> 1 each. */
> > __u16 num_queue_pairs;
> > (and tweak code to match).
> >
> > Alternatively, have separate registers for the number of tx and rx
> queues.
>
> OK, so virtio_net_config has num_queue_pairs, and this gets converted to
> numtxqs in virtnet_info?
Or put num_queue_pairs in virtnet_info too.
> > > +struct virtnet_info {
> > > + struct send_queue **sq;
> > > + struct receive_queue **rq;
> > > +
> > > + /* read-mostly variables */
> > > + int numtxqs ____cacheline_aligned_in_smp;
> >
> > Why do you think this alignment is a win?
>
> Actually this code was from the earlier patchset (MQ TX only) where
> the layout was different. Now rq and sq are allocated as follows:
> vi->sq = kzalloc(numtxqs * sizeof(*vi->sq), GFP_KERNEL);
> for (i = 0; i < numtxqs; i++) {
> vi->sq[i] = kzalloc(sizeof(*vi->sq[i]), GFP_KERNEL);
> Since the two pointers becomes read-only during use, there is no cache
> line dirty'ing. I will remove this directive.
>
> > > +/*
> > > + * Note for 'qnum' below:
> > > + * first 'numtxqs' vqs are RX, next 'numtxqs' vqs are TX.
> > > + */
> >
> > Another option to consider is to have them RX,TX,RX,TX:
> > this way vq->queue_index / 2 gives you the
> > queue pair number, no need to read numtxqs. On the other hand, it makes
> the
> > #RX==#TX assumption even more entrenched.
>
> OK. I was following how many drivers were allocating RX and TX's
> together - eg ixgbe_adapter has tx_ring and rx_ring arrays; bnx2
> has rx_buf_ring and tx_buf_ring arrays, etc.
That's fine. I am only talking about the VQ numbers.
> Also, vhost has some
> code that processes tx first before rx (e.g. vhost_net_stop/flush),
No idea why did I do it this way. I don't think it matters.
> so this approach seemed helpful.
> I am OK either way, what do you
> suggest?
We get less code generated but also less flexibility.
I am not sure, I'll play around with code, for now
let's keep it as is.
> > > + err = vi->vdev->config->find_vqs(vi->vdev, totalvqs, vqs,
> callbacks,
> > > + (const char
> **)names);
> > > + if (err)
> > > + goto free_params;
> > > +
> >
> > This would use up quite a lot of vectors. However,
> > tx interrupt is, in fact, slow path. So, assuming we don't have
> > enough vectors to use per vq, I think it's a good idea to
> > support reducing MSI vector usage by mapping all TX VQs to the same
> vector
> > and separate vectors for RX.
> > The hypervisor actually allows this, but we don't have an API at the
> virtio
> > level to pass that info to virtio pci ATM.
> > Any idea what a good API to use would be?
>
> Yes, it is a waste to have these vectors for tx ints. I initially
> thought of adding a flag to virtio_device to pass to vp_find_vqs,
> but it won't work, so a new API is needed. I can work with you on
> this in the background if you like.
OK. For starters, how about we change find_vqs to get a structure? Then
we can easily add flags that tell us that some interrupts are rare.
diff --git a/include/linux/virtio_config.h b/include/linux/virtio_config.h
index 800617b..2b765bb 100644
--- a/include/linux/virtio_config.h
+++ b/include/linux/virtio_config.h
@@ -78,7 +78,14 @@
* This gives the final feature bits for the device: it can change
* the dev->feature bits if it wants.
*/
+
typedef void vq_callback_t(struct virtqueue *);
+struct virtqueue_info {
+ struct virtqueue *vq;
+ vq_callback_t *callback;
+ const char *name;
+};
+
struct virtio_config_ops {
void (*get)(struct virtio_device *vdev, unsigned offset,
void *buf, unsigned len);
@@ -88,9 +95,7 @@ struct virtio_config_ops {
void (*set_status)(struct virtio_device *vdev, u8 status);
void (*reset)(struct virtio_device *vdev);
int (*find_vqs)(struct virtio_device *, unsigned nvqs,
- struct virtqueue *vqs[],
- vq_callback_t *callbacks[],
- const char *names[]);
+ struct virtqueue_info vq_info[]);
void (*del_vqs)(struct virtio_device *);
u32 (*get_features)(struct virtio_device *vdev);
void (*finalize_features)(struct virtio_device *vdev);
> > > + for (i = 0; i < numtxqs; i++) {
> > > + vi->rq[i]->rvq = vqs[i];
> > > + vi->sq[i]->svq = vqs[i + numtxqs];
> >
> > This logic is spread all over. We need some kind of macro to
> > get queue number of vq number and back.
>
> Will add this.
>
> > > + if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_CTRL_VQ)) {
> > > + vi->cvq = vqs[i + numtxqs];
> > > +
> > > + if (virtio_has_feature(vi->vdev,
> VIRTIO_NET_F_CTRL_VLAN))
> > > + vi->dev->features |=
> NETIF_F_HW_VLAN_FILTER;
> >
> > This bit does not seem to belong in initialize_vqs.
>
> I will move it back to probe.
>
> > > + err = virtio_config_val(vdev, VIRTIO_NET_F_NUMTXQS,
> > > + offsetof(struct
> virtio_net_config, numtxqs),
> > > + &numtxqs);
> > > +
> > > + /* We need atleast one txq */
> > > + if (err || !numtxqs)
> > > + numtxqs = 1;
> >
> > err is okay, but should we just fail on illegal values?
> > Or change the semantics:
> > n = 0;
> > err = virtio_config_val(vdev, VIRTIO_NET_F_NUMTXQS,
> > offsetof(struct virtio_net_config, numtxqs),
> > &n);
> > numtxq = n + 1;
>
> Will this be better:
> int num_queue_pairs = 2;
> int numtxqs;
>
> err = virtio_config_val(vdev, VIRTIO_NET_F_MULTIQUEUE,
> offsetof(struct virtio_net_config,
> num_queue_pairs), &num_queue_pairs);
> <ignore error, if any>
> numtxqs = num_queue_pairs / 2;
>
> > > + if (numtxqs > VIRTIO_MAX_TXQS)
> > > + return -EINVAL;
> >
> > Do we strictly need this?
> > I think we should just use whatever hardware has,
> > or alternatively somehow ignore the unused queues
> > (easy for tx, not sure about rx).
>
> vq's are matched between qemu, virtio-net and vhost. Isn't some check
> required that userspace has not passed a bad value?
For virtio, I'm not too concerned: qemu can already easily
crash the guest :)
For vhost yes, but I'm concerned that even with 16 VQs we are
drinking a lot of resources already. I would be happier
if we had a file descriptor per VQs pair in some way.
The the amount of memory userspace can use up is
limited by the # of file descriptors.
> > > + if (vi->rq[i]->num == 0) {
> > > + err = -ENOMEM;
> > > + goto free_recv_bufs;
> > > + }
> > > }
> > If this fails for vq > 0, you have to detach bufs.
>
> Right, will fix this.
>
> > > free_vqs:
> > > + for (i = 0; i < numtxqs; i++)
> > > + cancel_delayed_work_sync(&vi->rq[i]->refill);
> > > vdev->config->del_vqs(vdev);
> > > -free:
> > > + free_rq_sq(vi);
> >
> > If we have a wrapper to init all vqs, pls add a wrapper to clean up
> > all vqs as well.
>
> Will add that.
>
> > > + for (i = 0; i < vi->numtxqs; i++) {
> > > + struct virtqueue *rvq = vi->rq[i]->rvq;
> > > +
> > > + while (1) {
> > > + buf = virtqueue_detach_unused_buf
> (rvq);
> > > + if (!buf)
> > > + break;
> > > + if (vi->mergeable_rx_bufs || vi->
> big_packets)
> > > + give_pages(vi->rq[i],
> buf);
> > > + else
> > > + dev_kfree_skb(buf);
> > > + --vi->rq[i]->num;
> > > + }
> > > + BUG_ON(vi->rq[i]->num != 0);
> > > }
> > > - BUG_ON(vi->num != 0);
> > > +
> > > + free_rq_sq(vi);
> >
> >
> > This looks wrong here. This function should detach
> > and free all bufs, not internal malloc stuff.
>
> That is being done by free_receive_buf after free_unused_bufs()
> returns. I hope this addresses your point.
>
> > I think we should have free_unused_bufs that handles
> > a single queue, and call it in a loop.
>
> OK, so define free_unused_bufs() as:
>
> static void free_unused_bufs(struct virtnet_info *vi, struct virtqueue
> *svq,
> struct virtqueue *rvq)
> {
> /* Use svq and rvq with the remaining code unchanged */
> }
>
> Thanks,
>
> - KK
Not sure I understand. I am just suggesting
adding symmetrical functions like init/cleanup
alloc/free etc instead of adding stuff in random
functions that just happens to be called at the right time.
--
MST
^ permalink raw reply related
* Re: [PATCH 3/3] [RFC] Changes for MQ vhost
From: Michael S. Tsirkin @ 2011-03-02 10:11 UTC (permalink / raw)
To: Krishna Kumar2
Cc: anthony, arnd, avi, davem, eric.dumazet, horms, kvm, netdev,
rusty
In-Reply-To: <OFF5B60FC2.DE5700BA-ON65257846.00552576-65257846.00582CA0@in.ibm.com>
On Tue, Mar 01, 2011 at 09:34:35PM +0530, Krishna Kumar2 wrote:
> "Michael S. Tsirkin" <mst@redhat.com> wrote on 02/28/2011 03:34:23 PM:
>
> > > The number of vhost threads is <= #txqs. Threads handle more
> > > than one txq when #txqs is more than MAX_VHOST_THREADS (4).
> >
> > It is this sharing that prevents us from just reusing multiple vhost
> > descriptors?
>
> Sorry, I didn't understand this question.
>
> > 4 seems a bit arbitrary - do you have an explanation
> > on why this is a good number?
>
> I was not sure what is the best way - a sysctl parameter? Or should the
> maximum depend on number of host cpus? But that results in too many
> threads, e.g. if I have 16 cpus and 16 txqs.
I guess the question is, wouldn't # of threads == # of vqs work best?
If we process stuff on a single CPU, let's make it pass through
a single VQ.
And to do this, we could simply open multiple vhost fds without
changing vhost at all.
Would this work well?
> > > + struct task_struct *worker; /* worker for this vq */
> > > + spinlock_t *work_lock; /* points to a dev->work_lock[] entry
> */
> > > + struct list_head *work_list; /* points to a dev->work_list[]
> entry */
> > > + int qnum; /* 0 for RX, 1 -> n-1 for TX */
> >
> > Is this right?
>
> Will fix this.
>
> > > @@ -122,12 +128,33 @@ struct vhost_dev {
> > > int nvqs;
> > > struct file *log_file;
> > > struct eventfd_ctx *log_ctx;
> > > - spinlock_t work_lock;
> > > - struct list_head work_list;
> > > - struct task_struct *worker;
> > > + spinlock_t *work_lock[MAX_VHOST_THREADS];
> > > + struct list_head *work_list[MAX_VHOST_THREADS];
> >
> > This looks a bit strange. Won't sticking everything in a single
> > array of structures rather than multiple arrays be better for cache
> > utilization?
>
> Correct. In that context, which is better:
> struct {
> spinlock_t *work_lock;
> struct list_head *work_list;
> } work[MAX_VHOST_THREADS];
> or, to make sure work_lock/work_list is cache-aligned:
> struct work_lock_list {
> spinlock_t work_lock;
> struct list_head work_list;
> } ____cacheline_aligned_in_smp;
> and define:
> struct vhost_dev {
> ...
> struct work_lock_list work[MAX_VHOST_THREADS];
> };
> Second method uses a little more space but each vhost needs only
> one (read-only) cache line. I tested with this and can confirm it
> aligns each element on a cache-line. BW improved slightly (upto
> 3%), remote SD improves by upto -4% or so.
Makes sense, let's align them.
> > > +static inline int get_nvhosts(int nvqs)
> >
> > nvhosts -> nthreads?
>
> Yes.
>
> > > +static inline int vhost_get_thread_index(int index, int numtxqs, int
> nvhosts)
> > > +{
> > > + return (index % numtxqs) % nvhosts;
> > > +}
> > > +
> >
> > As the only caller passes MAX_VHOST_THREADS,
> > just use that?
>
> Yes, nice catch.
>
> > > struct vhost_net {
> > > struct vhost_dev dev;
> > > - struct vhost_virtqueue vqs[VHOST_NET_VQ_MAX];
> > > - struct vhost_poll poll[VHOST_NET_VQ_MAX];
> > > + struct vhost_virtqueue *vqs;
> > > + struct vhost_poll *poll;
> > > + struct socket **socks;
> > > /* Tells us whether we are polling a socket for TX.
> > > * We only do this when socket buffer fills up.
> > > * Protected by tx vq lock. */
> > > - enum vhost_net_poll_state tx_poll_state;
> > > + enum vhost_net_poll_state *tx_poll_state;
> >
> > another array?
>
> Yes... I am also allocating twice the space than what is required
> to make it's usage simple.
Where's the allocation? Couldn't find it.
> Please let me know what you feel about
> this.
>
> Thanks,
>
> - KK
^ permalink raw reply
* RE: e1000 - rx misses
From: denys @ 2011-03-02 10:23 UTC (permalink / raw)
To: Brandeburg, Jesse
Cc: John Bermudez, Ronciak, John, Kirsher, Jeffrey T, netdev,
e1000-devel
In-Reply-To: <alpine.WNT.2.00.1103011658050.5424@JBRANDEB-DESK2.amr.corp.intel.com>
On my experience such things happen because of too long iptables chains
or many "linear" u32 iproute2 filters (also long chains).
Sometimes also machines with non-tsc timesource + promisc mode enabled
or ping running.
On Tue, 1 Mar 2011 17:01:49 -0800 (Pacific Standard Time), Brandeburg,
Jesse wrote:
> <removed non-relevant users>
>
> On Tue, 1 Mar 2011, John Bermudez wrote:
>
>> Thanks for your time
>> Can you tell me the command to lengthen the input fifo rx queue?
>> is this possible
>
> You can try increasing the number of rx buffers via the command
> # ethtool -G ethX rx 4096
>
> and if you were really gung ho, you could increase the amount of fifo
> allocated to the rx side of the fifo by modifying the source. That
> said,
> I don't think that will buy you anything because it seems from the
> small
> amount of data provided that you are having exceptionally long
> periods of
> time where the data is coming faster than your machine can process
> (for
> whatever reason) and increasing the fifo only will give you a
> marginal
> (4kB or so) increasing in buffering.
>
>
>
>>
>> -----Original Message-----
>> From: Brandeburg, Jesse [mailto:jesse.brandeburg@intel.com]
>> Sent: Monday, February 28, 2011 11:05 AM
>> To: John Bermudez
>> Cc: cramerj; Ronciak, John; Kirsher, Jeffrey T; Kok, Auke-jan H;
>> netdev@vger.kernel.org; e1000-devel@lists.sourceforge.net
>> Subject: Re: e1000 - rx misses
>>
>> added e1000-devel, responses inline...
>>
>> On Wed, 23 Feb 2011, John Bermudez wrote:
>>
>> > Hello All,
>> > I got your contact info in a forum.
>> > maybe you could give me a quick pointer.
>> >
>> > I have a device that is experiencing RX misses. I tried 1000/full
>> and 100/full
>> > it occurs at both speeds. I seem to get a burst of loss so I am
>> assuming I am overrunning the FIFO RX queue.
>>
>> overrunning at 100Mb/s seems pretty unlikely to be our hardware's
>> fault,
>> as your buffer (in time) is increasing by 10x.
>>
>> >
>> > Any known workarounds?
>> > Configuration modifications?
>> >
>> > your time is much appreciated
>> >
>> >
>> >
>> > /lib/modules/2.4.31-uc0/kernel/drivers/net/e1000
>> > # ls
>> > e1000.o
>>
>> ow, 2.4.31 kernel is pretty much so old as to not be supportable.
>>
>> > # ethtool -S eth1
>> > NIC statistics:
>> > rx_packets: 217454512
>> > tx_packets: 266698397
>> > rx_bytes: 172995819593
>> > tx_bytes: 246744709750
>> > rx_broadcast: 0
>> > tx_broadcast: 528
>> <snip>
>> > rx_no_buffer_count: 925
>>
>> This count above indicates that your cpu is not returning buffers to
>> hardware fast enough. Do you have NAPI enabled?
>>
>> > rx_missed_errors: 48206
>>
>> This error means that for the length of time the fifo was buffering
>> the
>> adapter was not able to get any data buffers from the OS, filled the
>> FIFO
>> and had to drop this many packets.
>>
>> > tx_aborted_errors: 0
>> > tx_carrier_errors: 0
>> > tx_fifo_errors: 0
>> > tx_heartbeat_errors: 0
>> > tx_window_errors: 0
>> > tx_abort_late_coll: 0
>> > tx_deferred_ok: 0
>> > tx_single_coll_ok: 0
>> > tx_multi_coll_ok: 0
>> > tx_timeout_count: 0
>> > tx_restart_queue: 0
>> > rx_long_length_errors: 0
>> > rx_short_length_errors: 0
>> > rx_align_errors: 0
>> > tx_tcp_seg_good: 0
>> > tx_tcp_seg_failed: 0
>> > rx_flow_control_xon: 0
>> > rx_flow_control_xoff: 0
>> > tx_flow_control_xon: 0
>> > tx_flow_control_xoff: 0
>>
>> flow control is either not happenning or is disabled, if it is
>> disabled
>> you could try enabling it on both ends to get a little more
>> buffering in
>> your switch.
>>
>> > rx_long_byte_count: 172995819593
>> > rx_csum_offload_good: 217406235
>> > rx_csum_offload_errors: 17
>> > rx_header_split: 0
>> > alloc_rx_buff_failed: 0
>> > tx_smbus: 0
>> > rx_smbus: 5262
>>
>> hm, you have IPMI traffic, could these be related to your stalls?
>>
>> > dropped_smbus: 0
>> > #
>> >
>> >
>> > Thank you and have a nice day,
>> >
>> > Mr. John Bermudez
>> > NOC Level 3 Engineer
>> >
>> >
>>
>> You didn't include lots of data we need, like hardware type,
>> adapter/chip,
>> ethtool -i output, cat /proc/interrupts, system info, .config, etc.
>>
>> I suggest that something is running either in interrupt context on
>> your
>> system for a very long time (keeping us from running our interrupt
>> handler) or that your cpu is underpowered and unable to keep up with
>> whatever tasks it is running besides the network driver.
>>
>> If you wish to continue troubleshooting please file a bug at
>> e1000.sf.net
>> and attach the requested info there.
>>
>> Jesse
>>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [GIT PULL nf-2.6] IPVS
From: Patrick McHardy @ 2011-03-02 10:58 UTC (permalink / raw)
To: Simon Horman
Cc: lvs-devel, netdev, netfilter-devel, netfilter, Hans Schillstrom,
Julian Anastasov
In-Reply-To: <1299020375-11362-1-git-send-email-horms@verge.net.au>
Am 01.03.2011 23:59, schrieb Simon Horman:
> Hi Patrick,
>
> please consider pulling
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/lvs-test-2.6.git for-patrick
> to get the following change from Julian. Please note that it is an nf-2.6
> (that is 2.6.38-rc) change.
>
> Julian Anastasov (1):
> ipvs: fix dst_lock locking on dest update
Pulled, thanks Simon.
^ permalink raw reply
* Re: [Lxc-users] Bad checksums and lost packets with macvlan on dummy
From: Patrick McHardy @ 2011-03-02 11:03 UTC (permalink / raw)
To: Daniel Lezcano; +Cc: Eric Dumazet, Andrian Nord, lxc-users, Linux Netdev List
In-Reply-To: <4D6D515A.8060707@free.fr>
Am 01.03.2011 21:04, schrieb Daniel Lezcano:
> On 03/01/2011 05:51 PM, Patrick McHardy wrote:
>>> Patrick, do you have any suggestions to fix this ?
>> Since the frames are only looped back locally, I suppose the easiest
>> fix would be to mark them with CHECKSUM_UNNECESSARY. Alternatively
>> we need to complete the checksum manually, similar to what
>> dev_hard_start_xmit() does.
>
> That sounds very simple to fix, maybe too much simple :)
>
> I did the following change:
>
> --- linux-next.orig/drivers/net/macvlan.c
> +++ linux-next/drivers/net/macvlan.c
> @@ -222,6 +222,7 @@ static int macvlan_queue_xmit(struct sk_
>
> if (vlan->mode == MACVLAN_MODE_BRIDGE) {
> const struct ethhdr *eth = (void *)skb->data;
> + skb->ip_summed = CHECKSUM_UNNECESSARY;
>
> /* send to other bridge ports directly */
> if (is_multicast_ether_addr(eth->h_dest)) {
>
>
> and that fixed the problem. Do you think it is acceptable ?
The only problem I see is if the packets are bridged to a
different networking device (or redirected using the mirred
action), in this case the checksum will not be completed.
This would be a very strange setup though and probably wouldn't
be using dummy as lower device, so I'm not sure we have to
worry about this case.
^ permalink raw reply
* Re: [PATCH] sched: QFQ - quick fair queue scheduler (v2)
From: Eric Dumazet @ 2011-03-02 11:17 UTC (permalink / raw)
To: Fabio Checconi; +Cc: Stephen Hemminger, David Miller, Luigi Rizzo, netdev
In-Reply-To: <20110302020610.GD1005@gandalf.sssup.it>
Le mercredi 02 mars 2011 à 03:06 +0100, Fabio Checconi a écrit :
> Hi,
>
> > From: Stephen Hemminger <shemminger@vyatta.com>
> > Date: Mon, Feb 28, 2011 05:17:38PM -0800
> >
> > This is an implementation of the Quick Fair Queue scheduler developed
> > by Fabio Checconi. The same algorithm is already implemented in ipfw
> > in FreeBSD. Fabio had an earlier version developed on Linux, I just
> > cleaned it up and tested it. All bugs are mine.
> >
>
> thanks for posting, I'm pretty sure that bugs are more likely to be
> ours than yours :)
>
> During the development of the algorithm we used a simple traffic
> simulator to verify (informally) the timestamping and the guarantees
> provided. I've tested this version of the code with the simulator and
> so far it worked fine, so I think that timestamping and guarantees should
> be OK.
>
> Please let us know if we can be of any help,
> fabio
Hmm, I tried to setup QFQ (using iproute2patch
http://patchwork.ozlabs.org/patch/77902/ ) but failed
Do you have a link to a script/sample ?
Thanks
^ permalink raw reply
* Re: [PATCH 0/7] Final BKL removal, take 2
From: Mauro Carvalho Chehab @ 2011-03-02 11:32 UTC (permalink / raw)
To: Greg KH
Cc: Arnd Bergmann, linux-kernel, Andi Kleen, Andrew Hendry,
Arnaldo Carvalho de Melo, David Miller, Eric Dumazet,
Evgeniy Dushistov, linux-fsdevel, linux-x25, Max Vozeler,
Mikulas Patocka, netdev, Nick Bowler, Nick Piggin,
Palash Bandyopadhyay, Takahiro Hirofuchi
In-Reply-To: <20110302045923.GA28214@suse.de>
Em 02-03-2011 01:59, Greg KH escreveu:
> On Wed, Mar 02, 2011 at 12:13:04AM +0100, Arnd Bergmann wrote:
>> This is the set of patches that remain from
>> my previous submission one month ago. I've
>> dropped the ones that have either gone into
>> linux-next or got a sufficient number of
>> Acked-by:s so I put them into my own tree.
>>
>> I've updated the usbip, hpfs, ufs and appletalk
>> patches according to the feedback I got.
>>
>> If possible, I'd like the three networking patches
>> to go through the net-next tree, and the two
>> staging patches through the staging tree. I'll
>> add the other ones to my own series if I hear
>> no objections.
>
> I'll queue up the staging patches in the staging-next tree in a day or
> so, thanks for digging them up.
Greg,
It is probably better to queue the staging/cx25821 patch via my tree, as this is one
of those staging files that it is handled via media tree. So, if it is ok
for you both, I'll get patch 2/7.
Thanks,
Mauro
^ permalink raw reply
* Re: Kernel panic nf_nat_setup_info+0x5b3/0x6e0
From: Patrick McHardy @ 2011-03-02 11:37 UTC (permalink / raw)
To: Oleg A. Arkhangelsky; +Cc: netfilter-devel, netdev
In-Reply-To: <118081298480841@web25.yandex.ru>
Am 23.02.2011 18:07, schrieb "Oleg A. Arkhangelsky":
> Hello,
>
> Got this panic yesterday:
> http://www.progtech.ru/~oleg/crash.txt
>
> The offending instruction is:
> cmpb 54(%edx), %cl # <variable>.tuple.dst.protonum,
>
> and here is the assembler code of net/ipv4/netfilter/nf_nat_core.c:
> http://www.progtech.ru/~oleg/nf_nat_core.s
>
> Quick investigation lead me to conclusion that the problem is in
> return of same_src function:
>
> return (t->dst.protonum == tuple->dst.protonum &&
> t->src.u3.ip == tuple->src.u3.ip &&
> t->src.u.all == tuple->src.u.all);
>
> So either t or tuple pointer is bad, but I don't understand how
> this can be.
I'm not sure myself, I'm guessing it has something to do with
reallocation of the NAT extension area. Please post your full
ruleset and any helpers in use.
> [2971152.752502] Pid: 0, comm: swapper Not tainted (2.6.32.25-pt #1)
Also please try whether the problem still happens with the current
kernel version.
^ permalink raw reply
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