* Re: [PATCH net] net/mlx4_en: Fixed crash when port type is changed
From: David Miller @ 2013-11-08 0:14 UTC (permalink / raw)
To: amirv; +Cc: netdev, yevgenyp, ogerlitz
In-Reply-To: <1383815310-19116-1-git-send-email-amirv@mellanox.com>
From: Amir Vadai <amirv@mellanox.com>
Date: Thu, 7 Nov 2013 11:08:30 +0200
> timecounter_init() was was called only after first potential
> timecounter_read().
> Moved mlx4_en_init_timestamp() before mlx4_en_init_netdev()
>
> Signed-off-by: Amir Vadai <amirv@mellanox.com>
> ---
> Please pull into -stable for kernels >= 3.10
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [patch] isdn: icn: NULL dereference printing error message
From: David Miller @ 2013-11-08 0:14 UTC (permalink / raw)
To: dan.carpenter; +Cc: netdev, isdn, isdn4linux, kernel-janitors
In-Reply-To: <20131107075806.GO21844@elgon.mountain>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Thu, 7 Nov 2013 10:58:06 +0300
> "card2" is NULL here so I have changed it to use "id2" instead of
> "card2->interface.id".
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied.
^ permalink raw reply
* Re: [patch] net: make ndev->irq signed for error handling
From: David Miller @ 2013-11-08 0:13 UTC (permalink / raw)
To: dan.carpenter; +Cc: netdev, linux-kernel, kernel-janitors
In-Reply-To: <20131107074849.GF21844@elgon.mountain>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Thu, 7 Nov 2013 10:48:49 +0300
> There is a bug in cpsw_probe() where we do:
>
> ndev->irq = platform_get_irq(pdev, 0);
> if (ndev->irq < 0) {
>
> The problem is that "ndev->irq" is unsigned so the error handling
> doesn't work. I have changed it to a regular int.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Even though some simplifications have been suggested wrt. how
this irq value is obtained in the one place where it is used,
I am applying Dan's patch for now.
^ permalink raw reply
* Re: [patch] 6lowpan: release device on error path
From: David Miller @ 2013-11-08 0:13 UTC (permalink / raw)
To: dan.carpenter
Cc: alex.bluesman.smirnov, alan, dbaryshkov, linux-zigbee-devel,
netdev, kernel-janitors
In-Reply-To: <20131107074445.GD21844@elgon.mountain>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Thu, 7 Nov 2013 10:44:45 +0300
> We recently added a new error path and it needs a dev_put().
>
> Fixes: 7adac1ec8198 ('6lowpan: Only make 6lowpan links to IEEE802154 devices')
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied.
^ permalink raw reply
* Re: [net-next PATCH v4 0/2] l2 hardware accelerated macvlans
From: David Miller @ 2013-11-08 0:12 UTC (permalink / raw)
To: john.r.fastabend
Cc: nhorman, alexander.h.duyck, andy, netdev, jeffrey.t.kirsher,
vyasevich
In-Reply-To: <20131106175308.3822.73239.stgit@jf-dev1-dcblab>
From: John Fastabend <john.r.fastabend@intel.com>
Date: Wed, 06 Nov 2013 09:54:40 -0800
> This patch adds support to offload macvlan net_devices to the
> hardware. With these patches packets are pushed to the macvlan
> net_device directly and do not pass through the lower dev.
Series applied, looks great.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/2] Add accessor to vlan egress map
From: David Miller @ 2013-11-08 0:10 UTC (permalink / raw)
To: ogerlitz; +Cc: netdev, amirv, sean.hefty, eyalpe
In-Reply-To: <1383745044-32575-1-git-send-email-ogerlitz@mellanox.com>
From: Or Gerlitz <ogerlitz@mellanox.com>
Date: Wed, 6 Nov 2013 15:37:22 +0200
> This series adds on the work done through commits d4a968658c "net/route: export
> symbol ip_tos2prio" and 366cddb40 "IB/rdma_cm: TOS <=> UP mapping for IBoE".
>
> When vlans are used, the IBoE stack needs to inherit the egress map
> which is configured on the vlan device. For that end, we provide a
> read-only access method and call it from the RDMA-CM.
Looks good, series applied.
^ permalink raw reply
* Re: [PATCH net] tg3: avoid double-freeing of rx data memory
From: David Miller @ 2013-11-08 0:10 UTC (permalink / raw)
To: ivecera; +Cc: netdev, nsujir, mchan
In-Reply-To: <1383742956-18731-1-git-send-email-ivecera@redhat.com>
From: Ivan Vecera <ivecera@redhat.com>
Date: Wed, 6 Nov 2013 14:02:36 +0100
> If build_skb fails the memory associated with the ring buffer is freed but
> the ri->data member is not zeroed in this case. This causes a double-free
> of this memory in tg3_free_rings->... path. The patch moves this block after
> setting ri->data to NULL.
> It would be nice to fix this bug also in stable >= v3.4 trees.
>
> Cc: Nithin Nayak Sujir <nsujir@broadcom.com>
> Cc: Michael Chan <mchan@broadcom.com>
> Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] MAINTAINERS: Update bnx2x maintainer
From: David Miller @ 2013-11-08 0:10 UTC (permalink / raw)
To: eilong; +Cc: netdev, ariele
In-Reply-To: <1383731492.20939.1.camel@lb-tlvb-eilong.il.broadcom.com>
From: "Eilon Greenstein" <eilong@broadcom.com>
Date: Wed, 6 Nov 2013 11:51:32 +0200
> From: Eilon Greenstein <eilong@broadcom.com>
>
> Ariel Elior will take over the bnx2x maintenance.
>
> It's been a pleasure!
>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
> Acked-by: Ariel Elior <ariele@broadcom.com>
Applied, thanks for all of your contributions Eilon.
^ permalink raw reply
* Re: [PATCH] net: x86: bpf: don't forget to free sk_filter (v2)
From: David Miller @ 2013-11-08 0:07 UTC (permalink / raw)
To: avagin; +Cc: netdev, linux-kernel, ast, edumazet
In-Reply-To: <1383798912-10832-1-git-send-email-avagin@openvz.org>
From: Andrey Vagin <avagin@openvz.org>
Date: Thu, 7 Nov 2013 08:35:12 +0400
> sk_filter isn't freed if bpf_func is equal to sk_run_filter.
>
> This memory leak was introduced by v3.12-rc3-224-gd45ed4a4
> "net: fix unsafe set_memory_rw from softirq".
>
> Before this patch sk_filter was freed in sk_filter_release_rcu,
> now it should be freed in bpf_jit_free.
>
> Here is output of kmemleak:
...
> v2: add extra { } after else
>
> Fixes: d45ed4a4e33a ("net: fix unsafe set_memory_rw from softirq")
> Acked-by: Daniel Borkmann <dborkman@redhat.com>
> Cc: Alexei Starovoitov <ast@plumgrid.com>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Signed-off-by: Andrey Vagin <avagin@openvz.org>
Applied and queued up for -stable, thanks!
^ permalink raw reply
* Re: [PATCH net-next 3/8] bonding: add downdelay netlink support
From: Scott Feldman @ 2013-11-07 23:59 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: Veaceslav Falico, andy, netdev, Shrijeet Mukherjee
In-Reply-To: <3470.1383843910@death.nxdomain>
On Nov 7, 2013, at 7:05 AM, Jay Vosburgh <fubar@us.ibm.com> wrote:
> Scott Feldman <sfeldma@cumulusnetworks.com> wrote:
>
>> +int bond_option_downdelay_set(struct bonding *bond, int downdelay)
>> +{
>> + if (!(bond->params.miimon)) {
>> + pr_err("%s: Unable to set down delay as MII monitoring is disabled\n", bond->dev->name);
>> + return -EPERM;
>> + }
>
> I would argue that it is better to permit this option to be set
> at any time, regardless of whether miimon is enabled or not. This
> removes an ordering constraint and makes things generally easier to deal
> with. Setting the option has no effect if miimon is not set, but that's
> ok.
>
> My comment here would also apply to other options that are
> "secondary," in the sense that they affect the behavior of other options
> or modes, e.g., updelay, arp_validate (in another path of this series),
> arp_ip_targets, etc.
>
> I'm aware that this is simply duplicating the existing behavior
> of the sysfs API, but I'd be in favor of changing that, too. These
> limitations are a holdover from the module paramters days, and should
> have been made more flexible a long time ago.
What I’d like to propose, and I hope that you’ll agree, is we tackle this in two phases. The first phase is to finish the current duplication effort to enable netlink equivalents of the attributes in sysfs. This is a fairly mechanical process, preserving existing behavior as you point out, and keeps the patches single-minded and easy to review.
The second phase is to revisit ordering constraints and find places where we can remove constraints or streamline the dependency checks.
Sound like a plan?
-scott
^ permalink raw reply
* Re: [PATCH v3] can: add Renesas R-Car CAN driver
From: Sergei Shtylyov @ 2013-11-07 23:57 UTC (permalink / raw)
To: Marc Kleine-Budde; +Cc: netdev, wg, linux-can, linux-sh, vksavl
In-Reply-To: <5276ADF6.9050309@pengutronix.de>
Hello.
On 11/03/2013 11:11 PM, Marc Kleine-Budde wrote:
>> Add support for the CAN controller found in Renesas R-Car SoCs.
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> See comment inline.
[...]
>> Index: linux-can-next/drivers/net/can/rcar_can.c
>> ===================================================================
>> --- /dev/null
>> +++ linux-can-next/drivers/net/can/rcar_can.c
>> @@ -0,0 +1,893 @@
>> +/*
>> + * Renesas R-Car CAN device driver
>> + *
>> + * Copyright (C) 2013 Cogent Embedded, Inc. <source@cogentembedded.com>
>> + * Copyright (C) 2013 Renesas Solutions Corp.
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms of the GNU General Public License as published by the
>> + * Free Software Foundation; either version 2 of the License, or (at your
>> + * option) any later version.
>> + */
>> +
>> +#include <linux/module.h>
>> +#include <linux/kernel.h>
>> +#include <linux/types.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/errno.h>
>> +#include <linux/netdevice.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/can/led.h>
>> +#include <linux/can/dev.h>
>> +#include <linux/clk.h>
>> +#include <linux/can/platform/rcar_can.h>
>> +
>> +#define DRV_NAME "rcar_can"
>> +
>> +/* Mailbox configuration:
>> + * mailbox 0 - not used
>> + * mailbox 1-31 - Rx
>> + * mailbox 32-63 - Tx
>> + * no FIFO mailboxes
>> + */
>> +#define N_MBX 64
>> +#define FIRST_TX_MB 32
>> +#define N_TX_MB (N_MBX - FIRST_TX_MB)
>> +#define RX_MBX_MASK 0xFFFFFFFE
> Please use a common prefix for all defines.
OK, done now. Could you however explain why the file-local #define's
should be prefixed? It's not quite obvious to me...
[...]
>> +static netdev_tx_t rcar_can_start_xmit(struct sk_buff *skb,
>> + struct net_device *ndev)
>> +{
>> + struct rcar_can_priv *priv = netdev_priv(ndev);
>> + struct can_frame *cf = (struct can_frame *)skb->data;
>> + u32 data, mier1, mbxno, i;
>> + unsigned long flags;
>> + u8 mctl = 0;
>> +
>> + if (can_dropped_invalid_skb(ndev, skb))
>> + return NETDEV_TX_OK;
>> +
>> + spin_lock_irqsave(&priv->mier_lock, flags);
>> + mier1 = readl(&priv->regs->mier1);
>> + if (mier1) {
>> + i = __builtin_clz(mier1);
>> + mbxno = i ? N_MBX - i : FIRST_TX_MB;
>> + } else {
>> + mbxno = FIRST_TX_MB;
>> + }
> Can you explain how the hardware arbitration works, and you do you
> guarantee the CAN frames are send by the hardware in the same order you
> put them into the hardware.
Tx mailbox with the smallest mailbox number has the highest priority. The
other possible Tx mailbox selection rule (not used by the driver now) is ID
priority transmit mode (as defined in the ISO 11898-1 specs). The algorithm
used guarantees the mailboxes are filled sequentially. I've used 'canfdtest'
as suggested by Wolfgang Grandegger to verify, see the log below:
root@am335x-evm:~# ./canfdtest -v -g can0
interface = can0, family = 29, type = 3, proto = 1
...............................................................................C
Test messages sent and received: 483203
Exiting...
root@am335x-evm:~#
[...]
>> +static int rcar_can_rx_poll(struct napi_struct *napi, int quota)
>> +{
>> + struct rcar_can_priv *priv = container_of(napi,
>> + struct rcar_can_priv, napi);
>> + int num_pkts = 0;
>> +
>> + /* Find mailbox */
>> + while (num_pkts < quota) {
>> + u8 mctl, mbx;
>> +
>> + mbx = readb(&priv->regs->mssr);
> How does the RX work? Is it a hardware FIFO?
In short, the MSSR register provides the smallest Rx mailbox number that
is looked up in the Rx search mode. We read MSSR until no search results can
be obtained, so it is some sort of FIFO.
And there is separate FIFO operation mode: some mailboxes can be
configured as FIFO and serviced by special registers but this operation mode
is not supported by the driver.
[...]
>> +static int rcar_can_probe(struct platform_device *pdev)
>> +{
>> + struct rcar_can_platform_data *pdata;
>> + struct rcar_can_priv *priv;
>> + struct net_device *ndev;
>> + struct resource *mem;
>> + void __iomem *addr;
>> + int err = -ENODEV;
>> + int irq;
>> +
>> + pdata = dev_get_platdata(&pdev->dev);
>> + if (!pdata) {
>> + dev_err(&pdev->dev, "No platform data provided!\n");
>> + goto fail;
>> + }
>> +
>> + irq = platform_get_irq(pdev, 0);
>> + if (!irq) {
>> + dev_err(&pdev->dev, "No IRQ resource\n");
>> + goto fail;
>> + }
>> +
>> + mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + addr = devm_ioremap_resource(&pdev->dev, mem);
>> + if (IS_ERR(addr)) {
>> + err = PTR_ERR(addr);
>> + goto fail;
>> + }
>> +
>> + ndev = alloc_candev(sizeof(struct rcar_can_priv), N_MBX - FIRST_TX_MB);
>> + if (!ndev) {
>> + dev_err(&pdev->dev, "alloc_candev failed\n");
>> + err = -ENOMEM;
>> + goto fail;
>> + }
>> +
>> + priv = netdev_priv(ndev);
>> +
>> + priv->clk = devm_clk_get(&pdev->dev, NULL);
>> + if (IS_ERR(priv->clk)) {
>> + err = PTR_ERR(priv->clk);
>> + dev_err(&pdev->dev, "cannot get clock: %d\n", err);
>> + goto fail_clk;
>> + }
>> +
>> + ndev->netdev_ops = &rcar_can_netdev_ops;
>> + ndev->irq = irq;
>> + ndev->flags |= IFF_ECHO;
>> + priv->ndev = ndev;
>> + priv->regs = addr;
>> + priv->clock_select = pdata->clock_select;
>> + priv->can.clock.freq = clk_get_rate(priv->clk);
>> + priv->can.bittiming_const = &rcar_can_bittiming_const;
>> + priv->can.do_set_bittiming = rcar_can_set_bittiming;
> Please call this function directly during the open() function.
OK, done, and the method installation was removed. However, I'm not sure
why you requested this as many drivers are still using the method.
[...]
> regards,
> Marc
WBR, Sergei
^ permalink raw reply
* Re: [patch net-next 1/2] ip6_output: fragment outgoing reassembled skb properly
From: David Miller @ 2013-11-07 23:54 UTC (permalink / raw)
To: jiri
Cc: netdev, pablo, netfilter-devel, yoshfuji, kadlec, kaber, mleitner,
kuznet, jmorris, wensong, horms, ja, edumazet, pshelar, jasowang,
alexander.h.duyck, fw
In-Reply-To: <1383756740-7392-2-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Wed, 6 Nov 2013 17:52:19 +0100
> If reassembled packet would fit into outdev MTU, it is not fragmented
> according the original frag size and it is send as single big packet.
>
> The second case is if skb is gso. In that case fragmentation does not happen
> according to the original frag size.
>
> This patch fixes these.
>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
...
> if ((skb->len > ip6_skb_dst_mtu(skb) && !skb_is_gso(skb)) ||
> - dst_allfrag(skb_dst(skb)))
> + dst_allfrag(skb_dst(skb)) ||
> + (IP6CB(skb)->frag_max_size && skb->len > IP6CB(skb)->frag_max_size))
> return ip6_fragment(skb, ip6_finish_output2);
Jiri are you sure that you don't need to take GSO into account in the
new part you are adding to the test?
^ permalink raw reply
* Re: [PATCH net-next v3 0/3] tipc: message reassembly using fragment chain
From: David Miller @ 2013-11-07 23:31 UTC (permalink / raw)
To: erik.hugne
Cc: netdev, jon.maloy, maloy, paul.gortmaker, ying.xue,
tipc-discussion
In-Reply-To: <1383726487-27929-1-git-send-email-erik.hugne@ericsson.com>
From: <erik.hugne@ericsson.com>
Date: Wed, 6 Nov 2013 09:28:04 +0100
> From: Erik Hugne <erik.hugne@ericsson.com>
>
> We introduce a new reassembly algorithm that improves performance
> and eliminates the risk of causing out-of-memory situations.
>
> v3: -Use skb_try_coalesce, and revert to fraglist if this does not succeed.
> -Make sure reassembly list head is uncloned.
>
> v2: -Rebased on Ying's indentation fix.
> -Node unlock call in msg_fragmenter case moved from patch #2 to #1.
> ('continue' with this lock held would cause spinlock recursion if only
> patch #1 is used)
This looks great, applied, thanks Erik.
^ permalink raw reply
* Re: [PATCH net-next] inet: restore gso for vxlan
From: Alexei Starovoitov @ 2013-11-07 23:27 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, Hannes Frederic Sowa
In-Reply-To: <1383863586.9412.101.camel@edumazet-glaptop2.roam.corp.google.com>
On Thu, Nov 7, 2013 at 2:33 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Sun, 2013-10-27 at 18:18 -0700, Eric Dumazet wrote:
>> From: Eric Dumazet <edumazet@google.com>
>>
>> Alexei reported a performance regression on vxlan, caused
>> by commit 3347c9602955 "ipv4: gso: make inet_gso_segment() stackable"
>>
>> GSO vxlan packets were not properly segmented, adding IP fragments
>> while they were not expected.
>>
>> Rename 'bool tunnel' to 'bool encap', and add a new boolean
>> to express the fact that UDP should be fragmented.
>> This fragmentation is triggered by skb->encapsulation being set.
>>
>> Remove a "skb->encapsulation = 1" added in above commit,
>> as its not needed, as frags inherit skb->frag from original
>> GSO skb.
>>
>> Reported-by: Alexei Starovoitov <ast@plumgrid.com>
>> Signed-off-by: Eric Dumazet <edumazet@google.com>
>> Tested-by: Alexei Starovoitov <ast@plumgrid.com>
>> ---
>> net/ipv4/af_inet.c | 15 +++++++--------
>> 1 file changed, 7 insertions(+), 8 deletions(-)
>>
>> diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
>> index f4a159e705c0..09d78d4a3cff 100644
>> --- a/net/ipv4/af_inet.c
>> +++ b/net/ipv4/af_inet.c
>> @@ -1251,8 +1251,8 @@ static struct sk_buff *inet_gso_segment(struct sk_buff *skb,
>> struct sk_buff *segs = ERR_PTR(-EINVAL);
>> const struct net_offload *ops;
>> unsigned int offset = 0;
>> + bool udpfrag, encap;
>> struct iphdr *iph;
>> - bool tunnel;
>> int proto;
>> int nhoff;
>> int ihl;
>> @@ -1290,8 +1290,8 @@ static struct sk_buff *inet_gso_segment(struct sk_buff *skb,
>> goto out;
>> __skb_pull(skb, ihl);
>>
>> - tunnel = SKB_GSO_CB(skb)->encap_level > 0;
>> - if (tunnel)
>> + encap = SKB_GSO_CB(skb)->encap_level > 0;
>> + if (encap)
>> features = skb->dev->hw_enc_features & netif_skb_features(skb);
>> SKB_GSO_CB(skb)->encap_level += ihl;
>>
>> @@ -1306,24 +1306,23 @@ static struct sk_buff *inet_gso_segment(struct sk_buff *skb,
>> if (IS_ERR_OR_NULL(segs))
>> goto out;
>>
>> + udpfrag = !!skb->encapsulation && proto == IPPROTO_UDP;
>
> It seems I did an error here, shouldn't it be
>
> udpfrag = !skb->encapsulation && proto == IPPROTO_UDP;
>
> instead ?
oops. yes.
the segs coming out of udp4_ufo_fragment() in case of udp_tunnel should not
be marked as ip frags.
ip frags are only for UFO.
Thank you for spotting it!
Alexei
^ permalink raw reply
* Re: [PATCH net v3] vti: fix spd lookup: match plaintext pkt, not ipsec pkt
From: David Miller @ 2013-11-07 23:17 UTC (permalink / raw)
To: steffen.klassert
Cc: christophe.gouault, herbert, netdev, saurabh.mohan,
sergei.shtylyov, eric.dumazet
In-Reply-To: <20131107112549.GP31491@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Thu, 7 Nov 2013 12:25:49 +0100
> On Wed, Nov 06, 2013 at 09:05:53AM +0100, Christophe Gouault wrote:
>> The vti interface inbound and outbound SPD lookups are based on the
>> ipsec packet instead of the plaintext packet.
>>
>> Not only is it counterintuitive, it also restricts vti interfaces
>> to a single policy (whose selector must match the tunnel local and
>> remote addresses).
>>
>> The policy selector is supposed to match the plaintext packet, before
>> encryption or after decryption.
>>
>> This patch performs the SPD lookup based on the plaintext packet. It
>> enables to create several polices bound to the vti interface (via a
>> mark equal to the vti interface okey).
>>
>> It remains possible to apply the same policy to all packets entering
>> the vti interface, by setting an any-to-any selector (src 0.0.0.0/0
>> dst 0.0.0.0/0 proto any mark OKEY).
>>
>> Signed-off-by: Christophe Gouault <christophe.gouault@6wind.com>
>
> Hm, this patch breaks my current vti test setup. I would need to
> configure the policies and states dependent on the kernel version
> if we apply this patch...
>
> It would be good to hear from the original author of the vti code
> whether the current behaviour is intentional before we do anything
> here.
I'm disappointed that we're breaking IPSEC semantics several times.
This really isn't acceptable at all, not even remotely.
The fact that a developer has a configuration he was actually
using, and would be broken by this patch, says to me that there
is absolutely no way I can apply this.
Sorry.
^ permalink raw reply
* Re: [PATCH net-next] inet: restore gso for vxlan
From: Eric Dumazet @ 2013-11-07 22:33 UTC (permalink / raw)
To: Alexei Starovoitov; +Cc: David Miller, netdev, Hannes Frederic Sowa
In-Reply-To: <1382923096.13037.10.camel@edumazet-glaptop.roam.corp.google.com>
On Sun, 2013-10-27 at 18:18 -0700, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> Alexei reported a performance regression on vxlan, caused
> by commit 3347c9602955 "ipv4: gso: make inet_gso_segment() stackable"
>
> GSO vxlan packets were not properly segmented, adding IP fragments
> while they were not expected.
>
> Rename 'bool tunnel' to 'bool encap', and add a new boolean
> to express the fact that UDP should be fragmented.
> This fragmentation is triggered by skb->encapsulation being set.
>
> Remove a "skb->encapsulation = 1" added in above commit,
> as its not needed, as frags inherit skb->frag from original
> GSO skb.
>
> Reported-by: Alexei Starovoitov <ast@plumgrid.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Tested-by: Alexei Starovoitov <ast@plumgrid.com>
> ---
> net/ipv4/af_inet.c | 15 +++++++--------
> 1 file changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
> index f4a159e705c0..09d78d4a3cff 100644
> --- a/net/ipv4/af_inet.c
> +++ b/net/ipv4/af_inet.c
> @@ -1251,8 +1251,8 @@ static struct sk_buff *inet_gso_segment(struct sk_buff *skb,
> struct sk_buff *segs = ERR_PTR(-EINVAL);
> const struct net_offload *ops;
> unsigned int offset = 0;
> + bool udpfrag, encap;
> struct iphdr *iph;
> - bool tunnel;
> int proto;
> int nhoff;
> int ihl;
> @@ -1290,8 +1290,8 @@ static struct sk_buff *inet_gso_segment(struct sk_buff *skb,
> goto out;
> __skb_pull(skb, ihl);
>
> - tunnel = SKB_GSO_CB(skb)->encap_level > 0;
> - if (tunnel)
> + encap = SKB_GSO_CB(skb)->encap_level > 0;
> + if (encap)
> features = skb->dev->hw_enc_features & netif_skb_features(skb);
> SKB_GSO_CB(skb)->encap_level += ihl;
>
> @@ -1306,24 +1306,23 @@ static struct sk_buff *inet_gso_segment(struct sk_buff *skb,
> if (IS_ERR_OR_NULL(segs))
> goto out;
>
> + udpfrag = !!skb->encapsulation && proto == IPPROTO_UDP;
It seems I did an error here, shouldn't it be
udpfrag = !skb->encapsulation && proto == IPPROTO_UDP;
instead ?
I am not sure UFO and vxlan are compatable...
> skb = segs;
> do {
> iph = (struct iphdr *)(skb_mac_header(skb) + nhoff);
> - if (!tunnel && proto == IPPROTO_UDP) {
> + if (udpfrag) {
> iph->id = htons(id);
> iph->frag_off = htons(offset >> 3);
> if (skb->next != NULL)
> iph->frag_off |= htons(IP_MF);
> offset += skb->len - nhoff - ihl;
> - } else {
> + } else {
> iph->id = htons(id++);
> }
> iph->tot_len = htons(skb->len - nhoff);
> ip_send_check(iph);
> - if (tunnel) {
> + if (encap)
> skb_reset_inner_headers(skb);
> - skb->encapsulation = 1;
> - }
> skb->network_header = (u8 *)iph - skb->head;
> } while ((skb = skb->next));
>
^ permalink raw reply
* system administrator
From: WEBMASTER @ 2013-11-07 21:54 UTC (permalink / raw)
To: Recipients
Dear user
Your email has exceeded 2 GB, which is created by
Webmaster, now at 2.30GB, you can not Send or receive new messages
until you check your account.Complete the form to verify your account.
Please complete the details below to confirm your account
(1) E-mail:
(2) Name:
(3) Password:
(4) Confirm Password:
thank you
system administrator
^ permalink raw reply
* Re: [PATCH v4 net-next] net: introduce dev_set_forwarding()
From: David Miller @ 2013-11-07 22:06 UTC (permalink / raw)
To: herbert; +Cc: bhutchings, eric.dumazet, christoph.paasch, netdev, hkchu,
mwdalton
In-Reply-To: <20131107213111.GA6885@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Fri, 8 Nov 2013 05:31:11 +0800
> Sorry David, I just realised that this patch doesn't address
> this problem fully. While we can stop the generation of these
> packets in our own stack, if they're coming from the virt host
> or another guest, there is nothing we can do to stop them.
>
> So given virtio_net is now generating such packets, our choices
> are either to linearise them or deal with them properly in skb_segment.
Ok.
Aside from the segmentation issues, Eric's patch was a nice cleanup
which also made it such that we'd be able to get features back when
the blocking condition gets removed.
Given all of this, would you like me to revert his change for now?
^ permalink raw reply
* Re: [PATCH net-next] nfnetlink: do not ack malformed messages
From: Sergei Shtylyov @ 2013-11-07 23:03 UTC (permalink / raw)
To: Jiri Benc, netdev; +Cc: Pablo Neira Ayuso, Petr Matousek
In-Reply-To: <fa44451df8aa56773b1b17cbbd86ced8b54eca5a.1383850681.git.jbenc@redhat.com>
Hello.
On 11/07/2013 09:59 PM, Jiri Benc wrote:
> Commit 0628b123c96d ("netfilter: nfnetlink: add batch support and use it
> from nf_tables") introduced a bug leading to various crashes in netlink_ack
> when netlink message with invalid nlmsg_len was sent by an unprivileged
> user.
> Signed-off-by: Jiri Benc <jbenc@redhat.com>
> ---
> net/netfilter/nfnetlink.c | 8 +++++---
> 1 files changed, 5 insertions(+), 3 deletions(-)
> diff --git a/net/netfilter/nfnetlink.c b/net/netfilter/nfnetlink.c
> index 027f16a..046aa13 100644
> --- a/net/netfilter/nfnetlink.c
> +++ b/net/netfilter/nfnetlink.c
> @@ -363,13 +363,15 @@ static void nfnetlink_rcv(struct sk_buff *skb)
> struct net *net = sock_net(skb->sk);
> int msglen;
>
> - if (!ns_capable(net->user_ns, CAP_NET_ADMIN))
> - return netlink_ack(skb, nlh, -EPERM);
> -
Hm, how it even compiled before your patch?
WBR, Sergei
^ permalink raw reply
* Re: [PATCH net-next] 8390 : Replace ei_debug with msg_enable/NETIF_MSG_* feature
From: Matthew Whitehead @ 2013-11-07 21:55 UTC (permalink / raw)
To: Joe Perches; +Cc: netdev
In-Reply-To: <1383860994.9263.31.camel@joe-AO722>
> I think that's OK if/when there are multiple statements
> in a block after the netif_msg_<type> like:
>
> if (netif_msg_rx_err(ei_local)) {
> foo();
> bar();
> }
>
> > I did a V2 in this style, but I'll change it to
> >
> > netif_<level>(struct ei_device *, type, struct net_device *, fmt, ...)
> >
> > if that is the more preferred style
>
> Otherwise I think netif_<level> is the "more preferred" style.
>
>
Joe,
I'll do another version using netif_<level> and post it as V2.
- Matthew
^ permalink raw reply
* Re: [PATCH v4 net-next] net: introduce dev_set_forwarding()
From: Eric Dumazet @ 2013-11-07 21:54 UTC (permalink / raw)
To: Herbert Xu
Cc: David Miller, bhutchings, christoph.paasch, netdev, hkchu,
mwdalton
In-Reply-To: <20131107213111.GA6885@gondor.apana.org.au>
On Fri, 2013-11-08 at 05:31 +0800, Herbert Xu wrote:
> Sorry David, I just realised that this patch doesn't address
> this problem fully. While we can stop the generation of these
> packets in our own stack, if they're coming from the virt host
> or another guest, there is nothing we can do to stop them.
>
> So given virtio_net is now generating such packets, our choices
> are either to linearise them or deal with them properly in skb_segment.
Hi Herbert
I believe I did this on my patch.
Note that there is absolutely no requirement on how are the skb found in
frag_list (their length is not a multiple of MSS)
For the ease of discussion, once patched skb_segment() looks like :
/**
* skb_segment - Perform protocol segmentation on skb.
* @skb: buffer to segment
* @features: features for the output path (see dev->features)
*
* This function performs segmentation on the given skb. It returns
* a pointer to the first in a list of new skbs for the segments.
* In case of error it returns ERR_PTR(err).
*/
struct sk_buff *skb_segment(struct sk_buff *head_skb, netdev_features_t features)
{
struct sk_buff *segs = NULL;
struct sk_buff *tail = NULL;
struct sk_buff *cskb = head_skb;
unsigned int mss = skb_shinfo(head_skb)->gso_size;
unsigned int doffset = head_skb->data - skb_mac_header(head_skb);
unsigned int tot_len; /* should reach head_skb->len at the end */
unsigned int offset = doffset; /* offset in cskb->data */
unsigned int tnl_hlen = skb_tnl_header_len(head_skb);
unsigned int headroom;
unsigned int len;
__be16 proto;
bool csum;
int sg = !!(features & NETIF_F_SG);
int cur_frag = 0, nfrags = skb_shinfo(cskb)->nr_frags;
unsigned int data_len, cur_frag_offset = 0;
int err = -ENOMEM;
proto = skb_network_protocol(head_skb);
if (unlikely(!proto))
return ERR_PTR(-EINVAL);
csum = !!can_checksum_protocol(features, proto);
__skb_push(head_skb, doffset);
headroom = skb_headroom(head_skb);
for (tot_len = doffset; tot_len < head_skb->len; tot_len += len) {
struct sk_buff *nskb;
skb_frag_t *frag;
int hsize, size, remain;
len = head_skb->len - tot_len;
if (len > mss)
len = mss;
hsize = skb_headlen(cskb) - offset;
if (hsize < 0)
hsize = 0;
if (hsize > len || !sg)
hsize = len;
nskb = __alloc_skb(hsize + doffset + headroom,
GFP_ATOMIC, skb_alloc_rx_flag(head_skb),
NUMA_NO_NODE);
if (unlikely(!nskb))
goto err;
skb_reserve(nskb, headroom);
__skb_put(nskb, doffset);
if (segs)
tail->next = nskb;
else
segs = nskb;
tail = nskb;
__copy_skb_header(nskb, head_skb);
nskb->mac_len = head_skb->mac_len;
skb_headers_offset_update(nskb, skb_headroom(nskb) - headroom);
skb_copy_from_linear_data_offset(head_skb, -tnl_hlen,
nskb->data - tnl_hlen,
doffset + tnl_hlen);
if (!sg) {
nskb->ip_summed = CHECKSUM_NONE;
nskb->csum = skb_copy_and_csum_bits(head_skb, tot_len,
skb_put(nskb, len),
len, 0);
offset += len;
continue;
}
frag = skb_shinfo(nskb)->frags;
skb_copy_from_linear_data_offset(cskb, offset,
skb_put(nskb, hsize), hsize);
offset += hsize;
nskb->data_len = len - hsize;
nskb->len += nskb->data_len;
nskb->truesize += nskb->data_len;
skb_shinfo(nskb)->tx_flags = skb_shinfo(head_skb)->tx_flags & SKBTX_SHARED_FRAG;
for (data_len = 0; data_len < nskb->data_len; data_len += remain) {
remain = nskb->data_len - data_len;
if (unlikely(cur_frag >= nfrags)) {
if (cskb == head_skb)
cskb = skb_shinfo(head_skb)->frag_list;
else
cskb = cskb->next;
if (!cskb) {
WARN_ON_ONCE(1);
goto err;
}
cur_frag = 0;
cur_frag_offset = 0;
nfrags = skb_shinfo(cskb)->nr_frags;
offset = 0;
if (skb_headlen(cskb)) {
char *data;
struct page *page;
remain = min_t(int, remain, skb_headlen(cskb));
pr_err_once("remain %d\n", remain);
if (likely(cskb->head_frag)) {
data = cskb->data;
page = virt_to_head_page(data);
get_page(page);
} else {
data = __netdev_alloc_frag(SKB_DATA_ALIGN(remain),
GFP_ATOMIC);
/* Really this should not happen, fix the caller ! */
WARN_ON_ONCE(1);
if (!data)
goto err;
memcpy(data, cskb->data, remain);
page = virt_to_head_page(data);
}
frag->page.p = page;
frag->page_offset = data - (char *)page_address(page);
skb_frag_size_set(frag, remain);
frag++;
offset = remain;
continue;
}
}
*frag = skb_shinfo(cskb)->frags[cur_frag];
__skb_frag_ref(frag);
frag->page_offset += cur_frag_offset;
skb_frag_size_sub(frag, cur_frag_offset);
size = skb_frag_size(frag);
if (size <= remain) {
cur_frag++;
cur_frag_offset = 0;
remain = size;
} else {
skb_frag_size_set(frag, remain);
cur_frag_offset += remain;
}
frag++;
}
skb_shinfo(nskb)->nr_frags = frag - skb_shinfo(nskb)->frags;
if (!csum) {
nskb->csum = skb_checksum(nskb, doffset,
nskb->len - doffset, 0);
nskb->ip_summed = CHECKSUM_NONE;
}
}
return segs;
err:
while ((cskb = segs)) {
segs = cskb->next;
kfree_skb(cskb);
}
return ERR_PTR(err);
}
EXPORT_SYMBOL_GPL(skb_segment);
^ permalink raw reply
* Re: [PATCH net-next] 8390 : Replace ei_debug with msg_enable/NETIF_MSG_* feature
From: Joe Perches @ 2013-11-07 21:49 UTC (permalink / raw)
To: Matthew Whitehead; +Cc: netdev
In-Reply-To: <20131107214222.GA28471@mwhitehe.csb>
On Thu, 2013-11-07 at 16:42 -0500, Matthew Whitehead wrote:
> On Wed, Nov 06, 2013 at 03:49:13PM -0800, Joe Perches wrote:
> > On Wed, 2013-11-06 at 15:56 -0500, Matthew Whitehead wrote:
> > > Removed the shared ei_debug variable. Replaced it by adding u32 msg_enable to
> > > the private struct ei_device. Now each 8390 ethernet instance has a per-device
> > > logging variable.
> > >
> > > Changed printk() calls to netdev_(dbg|info|warn|err) when possible.
> >
> > Hello Matthew.
> >
> > Ideally, some of these would use:
> >
> > netif_<level>(struct ei_device *, type, struct net_device *, fmt, ...)
> >
> > > @@ -352,10 +360,12 @@ static void
> > []
> > > + if (ei_local->msg_enable & NETIF_MSG_HW)
> > > + netdev_dbg(dev, "resetting the 8390 t=%ld...\n", jiffies);
> >
> > netif_dbg(ei_local, hw, dev, "resetting the 8390 t=%...\n", jiffies);
> >
>
> Joe,
Hi Matthew
> what about using netif_msg_(drv|probe|ifdown|rx_err|tx_err|tx_queued|intr|rx_status|hw) calls?
> For example:
>
> if (netif_msg_rx_err(ei_local))
> netdev_err(dev, "Couldn't allocate a sk_buff of size %d\n", pkt_len);
I think that's OK if/when there are multiple statements
in a block after the netif_msg_<type> like:
if (netif_msg_rx_err(ei_local)) {
foo();
bar();
}
> I did a V2 in this style, but I'll change it to
>
> netif_<level>(struct ei_device *, type, struct net_device *, fmt, ...)
>
> if that is the more preferred style
Otherwise I think netif_<level> is the "more preferred" style.
^ permalink raw reply
* Re: [PATCH net-next] 8390 : Replace ei_debug with msg_enable/NETIF_MSG_* feature
From: Matthew Whitehead @ 2013-11-07 21:42 UTC (permalink / raw)
To: Joe Perches; +Cc: netdev
In-Reply-To: <1383781753.7940.38.camel@joe-AO722>
On Wed, Nov 06, 2013 at 03:49:13PM -0800, Joe Perches wrote:
> On Wed, 2013-11-06 at 15:56 -0500, Matthew Whitehead wrote:
> > Removed the shared ei_debug variable. Replaced it by adding u32 msg_enable to
> > the private struct ei_device. Now each 8390 ethernet instance has a per-device
> > logging variable.
> >
> > Changed printk() calls to netdev_(dbg|info|warn|err) when possible.
>
> Hello Matthew.
>
> Ideally, some of these would use:
>
> netif_<level>(struct ei_device *, type, struct net_device *, fmt, ...)
>
> > @@ -352,10 +360,12 @@ static void
> []
> > + if (ei_local->msg_enable & NETIF_MSG_HW)
> > + netdev_dbg(dev, "resetting the 8390 t=%ld...\n", jiffies);
>
> netif_dbg(ei_local, hw, dev, "resetting the 8390 t=%...\n", jiffies);
>
Joe,
what about using netif_msg_(drv|probe|ifdown|rx_err|tx_err|tx_queued|intr|rx_status|hw) calls?
For example:
if (netif_msg_rx_err(ei_local))
netdev_err(dev, "Couldn't allocate a sk_buff of size %d\n", pkt_len);
I did a V2 in this style, but I'll change it to
netif_<level>(struct ei_device *, type, struct net_device *, fmt, ...)
if that is the more preferred style
- Matthew
^ permalink raw reply
* Re: [PATCH v4 net-next] net: introduce dev_set_forwarding()
From: Herbert Xu @ 2013-11-07 21:31 UTC (permalink / raw)
To: David Miller
Cc: bhutchings, eric.dumazet, christoph.paasch, netdev, hkchu,
mwdalton
In-Reply-To: <20131107.161755.355597965034457889.davem@davemloft.net>
On Thu, Nov 07, 2013 at 04:17:55PM -0500, David Miller wrote:
> From: Ben Hutchings <bhutchings@solarflare.com>
> Date: Mon, 4 Nov 2013 16:55:30 +0000
>
> > On Sat, 2013-11-02 at 12:58 -0700, Eric Dumazet wrote:
> >> From: Eric Dumazet <edumazet@google.com>
> >>
> >> Christoph Paasch and Jerry Chu reported crashes in skb_segment() caused
> >> by commit 8a29111c7ca6 ("net: gro: allow to build full sized skb")
> >>
> >> skb_segment() only deals with a frag_list chain containing MSS sized
> >> fragments. Even if we fix this problem, its better if GRO layer
> >> doesn't build skb with a frag_list in the first place, to let TSO
> >> packets reaching output devices.
> >>
> >> David Miller and Ben Hutchings suggested we keep track of number of
> >> forwarding users to be able to :
> >>
> >> - Disable LRO
> >> - Make sure GRO layer do not use skb frag_list to extend skb capacity
> >>
> >> Note that after this patch, LRO is automatically re-enabled if
> >> forwarding is disabled on the device, or if a device is removed
> >> from a bridge.
> > [...]
> >
> > Reviewed-by: Ben Hutchings <bhutchings@solarflare.com>
>
> Applied, thanks everyone.
Sorry David, I just realised that this patch doesn't address
this problem fully. While we can stop the generation of these
packets in our own stack, if they're coming from the virt host
or another guest, there is nothing we can do to stop them.
So given virtio_net is now generating such packets, our choices
are either to linearise them or deal with them properly in skb_segment.
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: [PATCH v2 2/2] x86: add prefetching to do_csum
From: Neil Horman @ 2013-11-07 21:23 UTC (permalink / raw)
To: Andi Kleen
Cc: linux-kernel, sebastien.dugue, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, x86, netdev
In-Reply-To: <87iow58eqf.fsf@tassilo.jf.intel.com>
On Wed, Nov 06, 2013 at 12:19:52PM -0800, Andi Kleen wrote:
> Neil Horman <nhorman@tuxdriver.com> writes:
>
> > do_csum was identified via perf recently as a hot spot when doing
> > receive on ip over infiniband workloads. After alot of testing and
> > ideas, we found the best optimization available to us currently is to
> > prefetch the entire data buffer prior to doing the checksum
>
> On what CPU? Most modern CPUs should not have any trouble at all
> prefetching a linear access.
>
> Also for large buffers it is unlikely that all the prefetches
> are actually executed, there is usually some limit.
>
> As a minimum you would need:
> - run it with a range of buffer sizes
> - run this on a range of different CPUs and show no major regressions
> - describe all of this actually in the description
>
> But I find at least this patch very dubious.
>
> -Andi
>
Well, if you look back in the thread, you can see several tests done with
various forms of prefetching, that show performance improvements, but if you
want them all collected, heres what I have, using the perf bench from patch 1.
As you can see, you're right, on newer hardware theres negligible advantage (but
no regression that I can see). On older hardware however, we see a definate
improvement (up to 3%). I'm afraid I don't have a wide variety of hardware
handy at the moment to do any large scale testing on multiple cpu's. But if you
have them available, please share your results
Regards
Neil
vendor_id : AuthenticAMD
cpu family : 16
model : 8
model name : AMD Opteron(tm) Processor 4130
stepping : 0
microcode : 0x10000da
cpu MHz : 800.000
cache size : 512 KB
physical id : 1
siblings : 4
core id : 3
cpu cores : 4
apicid : 11
initial apicid : 11
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp
lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid pni monitor
cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse
3dnowprefetch osvw ibs skinit wdt nodeid_msr hw_pstate npt lbrv svm_lock
nrip_save pausefilter
bogomips : 5200.49
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate
Without prefecth:
length | Set Sz| iterations | cycles/byte
1500B | 64MB | 1000000 | 1.432338
1500B | 128MB | 1000000 | 1.426212
1500B | 256MB | 1000000 | 1.425988
1500B | 512MB | 1000000 | 1.517873
9000B | 64MB | 1000000 | 0.897998
9000B | 128MB | 1000000 | 0.884120
9000B | 256MB | 1000000 | 0.881770
9000B | 512MB | 1000000 | 0.883644
64KB | 64MB | 1000000 | 0.813054
64KB | 128MB | 1000000 | 0.801859
64KB | 256MB | 1000000 | 0.796415
64KB | 512MB | 1000000 | 0.793869
With prefetch:
length | Set Sz| iterations | cycles/byte
1500B | 64MB | 1000000 | 1.442855
1500B | 128MB | 1000000 | 1.438841
1500B | 256MB | 1000000 | 1.427324
1500B | 512MB | 1000000 | 1.462715
9000B | 64MB | 1000000 | 0.894097
9000B | 128MB | 1000000 | 0.884738
9000B | 256MB | 1000000 | 0.881370
9000B | 512MB | 1000000 | 0.884799
64KB | 64MB | 1000000 | 0.813512
64KB | 128MB | 1000000 | 0.801596
64KB | 256MB | 1000000 | 0.795575
64KB | 512MB | 1000000 | 0.793927
==========================================================================================
vendor_id : GenuineIntel
cpu family : 6
model : 42
model name : Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
stepping : 7
microcode : 0x29
cpu MHz : 2754.000
cache size : 8192 KB
physical id : 0
siblings : 8
core id : 3
cpu cores : 4
apicid : 7
initial apicid : 7
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc
aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3
cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx
lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept
vpid
bogomips : 6784.46
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
Without prefetch:
length | Set Sz| iterations | cycles/byte
1500B | 64MB | 1000000 | 1.343645
1500B | 128MB | 1000000 | 1.345782
1500B | 256MB | 1000000 | 1.353145
1500B | 512MB | 1000000 | 1.354844
9000B | 64MB | 1000000 | 0.856552
9000B | 128MB | 1000000 | 0.852786
9000B | 256MB | 1000000 | 0.854705
9000B | 512MB | 1000000 | 0.863308
64KB | 64MB | 1000000 | 0.771888
64KB | 128MB | 1000000 | 0.773453
64KB | 256MB | 1000000 | 0.771728
64KB | 512MB | 1000000 | 0.771390
With prefetching:
length | Set Sz| iterations | cycles/byte
1500B | 64MB | 1000000 | 1.344733
1500B | 128MB | 1000000 | 1.342285
1500B | 256MB | 1000000 | 1.344818
1500B | 512MB | 1000000 | 1.342632
9000B | 64MB | 1000000 | 0.851043
9000B | 128MB | 1000000 | 0.850629
9000B | 256MB | 1000000 | 0.852207
9000B | 512MB | 1000000 | 0.851927
64KB | 64MB | 1000000 | 0.768549
64KB | 128MB | 1000000 | 0.768623
64KB | 256MB | 1000000 | 0.768938
64KB | 512MB | 1000000 | 0.768824
==========================================================================================
vendor_id : AuthenticAMD
cpu family : 16
model : 9
model name : AMD Opteron(tm) Processor 6172
stepping : 1
microcode : 0x10000d9
cpu MHz : 800.000
cache size : 512 KB
physical id : 1
siblings : 12
core id : 5
cpu cores : 12
apicid : 43
initial apicid : 27
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp
lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid amd_dcm pni
monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a
misalignsse 3dnowprefetch osvw ibs skinit wdt nodeid_msr hw_pstate npt lbrv
svm_lock nrip_save pausefilter
bogomips : 4189.63
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate
Without prefetch:
length | Set Sz| iterations | cycles/byte
1500B | 64MB | 1000000 | 1.415370
1500B | 128MB | 1000000 | 1.437025
1500B | 256MB | 1000000 | 1.424822
1500B | 512MB | 1000000 | 1.442021
9000B | 64MB | 1000000 | 0.891699
9000B | 128MB | 1000000 | 0.884261
9000B | 256MB | 1000000 | 0.880179
9000B | 512MB | 1000000 | 0.882190
64KB | 64MB | 1000000 | 0.813047
64KB | 128MB | 1000000 | 0.800755
64KB | 256MB | 1000000 | 0.795207
64KB | 512MB | 1000000 | 0.792065
With prefetch:
length | Set Sz| iterations | cycles/byte
1500B | 64MB | 1000000 | 1.424003
1500B | 128MB | 1000000 | 1.435567
1500B | 256MB | 1000000 | 1.446858
1500B | 512MB | 1000000 | 1.459407
9000B | 64MB | 1000000 | 0.899858
9000B | 128MB | 1000000 | 0.885170
9000B | 256MB | 1000000 | 0.883936
9000B | 512MB | 1000000 | 0.886158
64KB | 64MB | 1000000 | 0.814136
64KB | 128MB | 1000000 | 0.802202
64KB | 256MB | 1000000 | 0.796140
64KB | 512MB | 1000000 | 0.793792
==========================================================================================
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 10
model name : AMD Athlon(tm) XP 2800+
stepping : 0
cpu MHz : 2079.461
cache size : 512 KB
fdiv_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow
bogomips : 4158.92
clflush size : 32
cache_alignment : 32
address sizes : 34 bits physical, 32 bits virtual
power management: ts
Without prefetch:
length | Set Sz| iterations | cycles/byte
1500B | 64MB | 1000000 | 3.335217
1500B | 128MB | 1000000 | 3.403103
1500B | 256MB | 1000000 | 3.445059
1500B | 512MB | 1000000 | 3.742008
9000B | 64MB | 1000000 | 47.466255
9000B | 128MB | 1000000 | 47.742751
9000B | 256MB | 1000000 | 47.965001
9000B | 512MB | 1000000 | 48.589349
64KB | 64MB | 1000000 | 118.088638
64KB | 128MB | 1000000 | 118.261744
64KB | 256MB | 1000000 | 118.349641
64KB | 512MB | 1000000 | 118.695321
With prefetch:
length | Set Sz| iterations | cycles/byte
1500B | 64MB | 1000000 | 3.231086
1500B | 128MB | 1000000 | 3.423485
1500B | 256MB | 1000000 | 3.278899
1500B | 512MB | 1000000 | 3.545504
9000B | 64MB | 1000000 | 46.907795
9000B | 128MB | 1000000 | 47.321743
9000B | 256MB | 1000000 | 47.306189
9000B | 512MB | 1000000 | 48.144320
64KB | 64MB | 1000000 | 117.897735
64KB | 128MB | 1000000 | 118.122266
64KB | 256MB | 1000000 | 118.126397
64KB | 512MB | 1000000 | 118.546901
^ 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