* Re: [PATCH][Trivial] net/wan/hdlc_ppp: remove dead goto
From: Jesper Juhl @ 2011-08-21 21:38 UTC (permalink / raw)
To: David Miller; +Cc: khc, netdev, linux-kernel, trivial
In-Reply-To: <20110818.220249.1523360015062657902.davem@davemloft.net>
On Thu, 18 Aug 2011, David Miller wrote:
> From: Jesper Juhl <jj@chaosbits.net>
> Date: Sat, 13 Aug 2011 01:39:43 +0200 (CEST)
>
> > From: Jesper Juhl <jj@chaosbits.net>
> >
> > We'll either hit one of the case labels or the default in the switch
> > and in all cases do we then 'goto out', so having 'goto out' right
> > after the switch is pointless as we can never hit it - remove it.
> >
> > Signed-off-by: Jesper Juhl <jj@chaosbits.net>
>
> Probably a lot cleaner to use break statements in the switch() statement
> and keep this goto in place.
>
> That's more straightforward control flow than what this thing is doing.
Here you are :)
From: Jesper Juhl <jj@chaosbits.net>
Subject: [PATCH] net/wan/hdlc_ppp: use break in switch
We'll either hit one of the case labels or the default in the switch
and in all cases do we then 'goto out' and we also have a 'goto out'
after the switch that is redundant. Change to just use break in the
case statements and leave the 'goto out' after the lop for everyone to
hit.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
drivers/net/wan/hdlc_ppp.c | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wan/hdlc_ppp.c b/drivers/net/wan/hdlc_ppp.c
index 055a918..0d76455 100644
--- a/drivers/net/wan/hdlc_ppp.c
+++ b/drivers/net/wan/hdlc_ppp.c
@@ -515,37 +515,37 @@ static int ppp_rx(struct sk_buff *skb)
switch (cp->code) {
case CP_CONF_REQ:
ppp_cp_parse_cr(dev, pid, cp->id, len, skb->data);
- goto out;
+ break;
case CP_CONF_ACK:
if (cp->id == proto->cr_id)
ppp_cp_event(dev, pid, RCA, 0, 0, 0, NULL);
- goto out;
+ break;
case CP_CONF_REJ:
case CP_CONF_NAK:
if (cp->id == proto->cr_id)
ppp_cp_event(dev, pid, RCN, 0, 0, 0, NULL);
- goto out;
+ break;
case CP_TERM_REQ:
ppp_cp_event(dev, pid, RTR, 0, cp->id, 0, NULL);
- goto out;
+ break;
case CP_TERM_ACK:
ppp_cp_event(dev, pid, RTA, 0, 0, 0, NULL);
- goto out;
+ break;
case CP_CODE_REJ:
ppp_cp_event(dev, pid, RXJ_BAD, 0, 0, 0, NULL);
- goto out;
+ break;
default:
len += sizeof(struct cp_header);
if (len > dev->mtu)
len = dev->mtu;
ppp_cp_event(dev, pid, RUC, 0, 0, len, cp);
- goto out;
+ break;
}
goto out;
--
1.7.6
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply related
* Re: r8169 hard-freezes the system on big network loads
From: Francois Romieu @ 2011-08-21 22:11 UTC (permalink / raw)
To: Michael Brade; +Cc: netdev, nic_swsd
In-Reply-To: <201108211520.50400.brade@informatik.uni-muenchen.de>
Michael Brade <brade@informatik.uni-muenchen.de> :
[...]
> r8169 0000:13:00.0: eth0: RTL8168d/8111d at 0xffffc90000c72000,
> f0:4d:a2:b8:ce:62, XID 083000c0 IRQ 52
RTL_GIGA_MAC_VER_26
> hope that helps,
Yes. There is enough data for me to reproduce the bug with the
exact same chipset.
--
Ueimor
^ permalink raw reply
* Re: [PATCH] virtio-net: Read MAC only after initializing MSI-X
From: Rusty Russell @ 2011-08-22 0:24 UTC (permalink / raw)
To: Michael S. Tsirkin, Sasha Levin; +Cc: linux-kernel, virtualization, netdev, kvm
In-Reply-To: <20110819152335.GA19489@redhat.com>
On Fri, 19 Aug 2011 18:23:35 +0300, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Sat, Aug 13, 2011 at 11:51:01AM +0300, Sasha Levin wrote:
> > The MAC of a virtio-net device is located at the first field of the device
> > specific header. This header is located at offset 20 if the device doesn't
> > support MSI-X or offset 24 if it does.
> >
> > Current code in virtnet_probe() used to probe the MAC before checking for
> > MSI-X, which means that the read was always made from offset 20 regardless
> > of whether MSI-X in enabled or not.
> >
> > This patch moves the MAC probe to after the detection of whether MSI-X is
> > enabled. This way the MAC will be read from offset 24 if the device indeed
> > supports MSI-X.
> >
> > Cc: Rusty Russell <rusty@rustcorp.com.au>
> > Cc: Michael S. Tsirkin <mst@redhat.com>
> > Cc: virtualization@lists.linux-foundation.org
> > Cc: netdev@vger.kernel.org
> > Cc: kvm@vger.kernel.org
> > Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
>
> I am not sure I see a bug in virtio: the config pace layout simply
> changes as msix is enabled and disabled (and if you look at the latest
> draft, also on whether 64 bit features are enabled).
> It doesn't depend on msix capability being present in device.
>
> The spec seems to be explicit enough:
> If MSI-X is enabled for the device, two additional fields immediately
> follow this header.
>
> So I'm guessing the bug is in kvm tools which assume
> same layout for when msix is enabled and disabled.
> qemu-kvm seems to do the right thing so the device
> seems to get the correct mac.
So, the config space moves once MSI-X is enabled? In which case, it
should say "ONCE MSI-X is enabled..."
Thanks,
Rusty.
^ permalink raw reply
* Re: [PATCH 0/2] pktgen: Clone skb to avoid corruption of skbs in ndo_start_xmit methods (v3)
From: Neil Horman @ 2011-08-22 0:27 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev
In-Reply-To: <1313593637.2776.9.camel@bwh-desktop>
On Wed, Aug 17, 2011 at 04:07:17PM +0100, Ben Hutchings wrote:
> On Tue, 2011-07-26 at 12:05 -0400, Neil Horman wrote:
> > Ok, after considering all your comments, Dave suggested this as an alternate
> > approach:
> >
> > 1) We create a new priv_flag, IFF_SKB_TX_SHARED, to identify drivers capable of
> > handling shared skbs. Default is to not set this flag
> >
> > 2) Modify ether_setup to enable this flag, under the assumption that any driver
> > calling this function is initalizing a real ethernet device and as such can
> > handle shared skbs since they don't tend to store state in the skb struct.
> > Pktgen can then query this flag when a user script attempts to issue the
> > clone_skb command and decide if it is to be alowed or not.
> [...]
>
> A bunch of Ethernet drivers do skb_pad() or skb_padto() in their
> ndo_start_xmit implementations, either to avoid hardware bugs or because
> the MAC doesn't automatically pad to the minimum frame length. This
> presumably means they can't generally handle shared skbs, though in the
> specific case of pktgen it should be safe as long as a single skb is not
> submitted by multiple threads at once.
>
Agreed, given that pktgen is doing skb sharing in a serialized manner (i.e. one
thread of execution increasing skb->users rather than in multiple threads), the
skb_pad[to] cases are safe. Are there cases in which shared skbs are
transmitted in parallel threads that we need to check for?
Neil
> Ben.
>
> --
> Ben Hutchings, Staff Engineer, Solarflare
> Not speaking for my employer; that's the marketing department's job.
> They asked us to note that Solarflare product names are trademarked.
>
>
^ permalink raw reply
* Re: [omega-g1:11072] Re: [PATCH] net: configurable sysctl parameter "net.core.tcp_lowat" for sk_stream_min_wspace()
From: Jun.Kondo @ 2011-08-22 0:33 UTC (permalink / raw)
To: David Miller
Cc: linux-kernel, omega-g1, notsuki, motokazu.kozaki, htaira, netdev,
tomohiko.takahashi, kotaro.sakai, ken.sugawara
In-Reply-To: <20110819.024326.598275465899000817.davem@davemloft.net>
By using this patch, we want to prevent "timeout occured over the network that is low throughput but available".
But in the current implementation, both blocking and non-blocking,
user processes can't recognize the reason in detail
when failed to write to socket buffer, we think.
is it (really) network problem ?
or is wmem not enough free to write?
As stated above, we think it is difficult for user processes to handle timeout of writing socket buffer,
when wmem is configured large value.(to ensure high throughput over the high ralency network, like 3G).
(2011/08/19 18:43), David Miller wrote:
> From: "Jun.Kondo"<jun.kondo@ctc-g.co.jp>
> Date: Fri, 19 Aug 2011 18:28:45 +0900
>
>> You suggested to use non-blocking writes, but we think
>> we have to rewrite the Apache code if doing so.
>> That is, we have to make a modification to Apache that
>> depends on the architecture.
>> By using this patch, it can be handled by changing the
>> configuration a little bit on the kernel side for such
>> applications that it is difficult to do so on application
>> side.
> The kernel provides the facilities necessary to achieve your
> goals. It is a userspace problem.
>
--
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
近藤 潤
v 伊藤忠テクノソリューションズ株式会社(CTC)
v システム技術第1部 技術第4課
v 個人:03-6757-2144
v FAX:03-5800-2256
v
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
^ permalink raw reply
* Re: linux-next: boot test failure (net tree)
From: Stephen Rothwell @ 2011-08-22 1:30 UTC (permalink / raw)
To: David Miller
Cc: netdev, linux-next, linux-kernel, jeffrey.t.kirsher, mikey,
torvalds, akpm, ppc-dev, Benjamin Herrenschmidt, Paul Mackerras
In-Reply-To: <20110817.225356.1790362313048139752.davem@davemloft.net>
Hi Dave,
On Wed, 17 Aug 2011 22:53:56 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 18 Aug 2011 15:22:14 +1000
>
> > Mikey asks: Will Dave take these updates if we get Acks from the
> > maintainers? :-)
>
> I'm more than happy to :-)
Here's what I am applying as a merge fixup to the net tree today so that
my ppc64_defconfig builds actually build more or less the same set of
drivers as before this rearrangement.
This has no Acks yet, but produces a very similar .config to what we had
previously.
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 22 Aug 2011 11:23:56 +1000
Subject: [PATCH] powerpc: update ppc64_defconfig for net device movement
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/configs/ppc64_defconfig | 71 +++++++++++++--------------------
1 files changed, 28 insertions(+), 43 deletions(-)
diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/configs/ppc64_defconfig
index 84a685a5..9a424c4 100644
--- a/arch/powerpc/configs/ppc64_defconfig
+++ b/arch/powerpc/configs/ppc64_defconfig
@@ -49,7 +49,6 @@ CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_HZ_100=y
CONFIG_BINFMT_MISC=m
-CONFIG_HOTPLUG_CPU=y
CONFIG_KEXEC=y
CONFIG_IRQ_ALL_CPUS=y
CONFIG_MEMORY_HOTREMOVE=y
@@ -75,7 +74,6 @@ CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=m
# CONFIG_IPV6 is not set
CONFIG_NETFILTER=y
-CONFIG_NETFILTER_NETLINK_QUEUE=m
CONFIG_NF_CONNTRACK=m
CONFIG_NF_CONNTRACK_EVENTS=y
CONFIG_NF_CT_PROTO_SCTP=m
@@ -133,7 +131,6 @@ CONFIG_NETFILTER_XT_MATCH_U32=m
CONFIG_NF_CONNTRACK_IPV4=m
CONFIG_IP_NF_QUEUE=m
CONFIG_IP_NF_IPTABLES=m
-CONFIG_IP_NF_MATCH_ADDRTYPE=m
CONFIG_IP_NF_MATCH_AH=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_TTL=m
@@ -145,7 +142,6 @@ CONFIG_NF_NAT=m
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_NETMAP=m
CONFIG_IP_NF_TARGET_REDIRECT=m
-CONFIG_NF_NAT_SNMP_BASIC=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_CLUSTERIP=m
CONFIG_IP_NF_TARGET_ECN=m
@@ -176,7 +172,6 @@ CONFIG_CHR_DEV_SG=y
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_FC_ATTRS=y
-CONFIG_SCSI_SAS_ATTRS=m
CONFIG_SCSI_CXGB3_ISCSI=m
CONFIG_SCSI_CXGB4_ISCSI=m
CONFIG_SCSI_BNX2_ISCSI=m
@@ -208,13 +203,6 @@ CONFIG_DM_SNAPSHOT=m
CONFIG_DM_MIRROR=m
CONFIG_DM_ZERO=m
CONFIG_DM_MULTIPATH=m
-CONFIG_IEEE1394=y
-CONFIG_IEEE1394_OHCI1394=y
-CONFIG_IEEE1394_SBP2=m
-CONFIG_IEEE1394_ETH1394=m
-CONFIG_IEEE1394_RAWIO=y
-CONFIG_IEEE1394_VIDEO1394=m
-CONFIG_IEEE1394_DV1394=m
CONFIG_ADB_PMU=y
CONFIG_PMAC_SMU=y
CONFIG_THERM_PM72=y
@@ -223,43 +211,49 @@ CONFIG_WINDFARM_PM81=y
CONFIG_WINDFARM_PM91=y
CONFIG_WINDFARM_PM112=y
CONFIG_WINDFARM_PM121=y
-CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
CONFIG_BONDING=m
CONFIG_TUN=m
CONFIG_MARVELL_PHY=y
CONFIG_BROADCOM_PHY=m
-CONFIG_NET_ETHERNET=y
-CONFIG_SUNGEM=y
CONFIG_NET_VENDOR_3COM=y
CONFIG_VORTEX=y
-CONFIG_IBMVETH=m
-CONFIG_NET_PCI=y
-CONFIG_PCNET32=y
-CONFIG_E100=y
+CONFIG_NET_VENDOR_ALTEON=y
CONFIG_ACENIC=m
CONFIG_ACENIC_OMIT_TIGON_I=y
-CONFIG_E1000=y
-CONFIG_E1000E=y
+CONFIG_NET_VENDOR_AMD=y
+CONFIG_PCNET32=y
CONFIG_TIGON3=y
-CONFIG_BNX2=m
-CONFIG_SPIDER_NET=m
-CONFIG_GELIC_NET=m
-CONFIG_GELIC_WIRELESS=y
CONFIG_CHELSIO_T1=m
-CONFIG_CHELSIO_T3=m
-CONFIG_CHELSIO_T4=m
+CONFIG_NET_VENDOR_EMULEX=y
+CONFIG_BE2NET=m
+CONFIG_NET_VENDOR_EXAR=y
+CONFIG_S2IO=m
+CONFIG_NET_VENDOR_IBM=y
+CONFIG_IBMVETH=m
+CONFIG_ISERIES_VETH=m
CONFIG_EHEA=m
-CONFIG_IXGBE=m
+CONFIG_NET_VENDOR_INTEL=y
+CONFIG_E100=y
+CONFIG_E1000=y
+CONFIG_E1000E=y
CONFIG_IXGB=m
-CONFIG_S2IO=m
+CONFIG_IXGBE=m
+CONFIG_MLX4_EN=m
+CONFIG_NET_VENDOR_MYRI=y
CONFIG_MYRI10GE=m
-CONFIG_NETXEN_NIC=m
+CONFIG_NET_VENDOR_NVIDIA=y
+CONFIG_NET_VENDOR_PASEMI=y
CONFIG_PASEMI_MAC=y
-CONFIG_MLX4_EN=m
+CONFIG_NET_VENDOR_QLOGIC=y
CONFIG_QLGE=m
-CONFIG_BE2NET=m
-CONFIG_ISERIES_VETH=m
+CONFIG_NETXEN_NIC=m
+CONFIG_NET_VENDOR_SUN=y
+CONFIG_SUNGEM=y
+CONFIG_NET_VENDOR_TOSHIBA=y
+CONFIG_GELIC_NET=m
+CONFIG_GELIC_WIRELESS=y
+CONFIG_SPIDER_NET=m
CONFIG_PPP=m
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
@@ -331,7 +325,6 @@ CONFIG_USB=y
CONFIG_USB_DEVICEFS=y
CONFIG_USB_MON=m
CONFIG_USB_EHCI_HCD=y
-CONFIG_USB_EHCI_TT_NEWSCHED=y
# CONFIG_USB_EHCI_HCD_PPC_OF is not set
CONFIG_USB_OHCI_HCD=y
CONFIG_USB_STORAGE=m
@@ -373,11 +366,9 @@ CONFIG_JFS_POSIX_ACL=y
CONFIG_JFS_SECURITY=y
CONFIG_XFS_FS=m
CONFIG_XFS_POSIX_ACL=y
-CONFIG_OCFS2_FS=m
CONFIG_BTRFS_FS=m
CONFIG_BTRFS_FS_POSIX_ACL=y
CONFIG_NILFS2_FS=m
-CONFIG_INOTIFY=y
CONFIG_AUTOFS4_FS=m
CONFIG_FUSE_FS=m
CONFIG_ISO9660_FS=y
@@ -398,7 +389,6 @@ CONFIG_ROOT_NFS=y
CONFIG_NFSD=m
CONFIG_NFSD_V3_ACL=y
CONFIG_NFSD_V4=y
-CONFIG_RPCSEC_GSS_SPKM3=m
CONFIG_CIFS=m
CONFIG_CIFS_XATTR=y
CONFIG_CIFS_POSIX=y
@@ -444,15 +434,13 @@ CONFIG_CRC_T10DIF=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_KERNEL=y
CONFIG_LOCKUP_DETECTOR=y
-CONFIG_DETECT_HUNG_TASK=y
CONFIG_DEBUG_MUTEXES=y
-# CONFIG_RCU_CPU_STALL_DETECTOR is not set
+CONFIG_DEBUG_STACK_USAGE=y
CONFIG_LATENCYTOP=y
CONFIG_SYSCTL_SYSCALL_CHECK=y
CONFIG_SCHED_TRACER=y
CONFIG_BLK_DEV_IO_TRACE=y
CONFIG_DEBUG_STACKOVERFLOW=y
-CONFIG_DEBUG_STACK_USAGE=y
CONFIG_CODE_PATCHING_SELFTEST=y
CONFIG_FTR_FIXUP_SELFTEST=y
CONFIG_MSI_BITMAP_SELFTEST=y
@@ -463,10 +451,8 @@ CONFIG_CRYPTO_NULL=m
CONFIG_CRYPTO_TEST=m
CONFIG_CRYPTO_CCM=m
CONFIG_CRYPTO_GCM=m
-CONFIG_CRYPTO_ECB=m
CONFIG_CRYPTO_PCBC=m
CONFIG_CRYPTO_HMAC=y
-CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MICHAEL_MIC=m
CONFIG_CRYPTO_SHA256=m
CONFIG_CRYPTO_SHA512=m
@@ -474,7 +460,6 @@ CONFIG_CRYPTO_TGR192=m
CONFIG_CRYPTO_WP512=m
CONFIG_CRYPTO_AES=m
CONFIG_CRYPTO_ANUBIS=m
-CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_BLOWFISH=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_KHAZAD=m
--
1.7.5.4
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* linux-next: manual merge of the net tree with the tree
From: Stephen Rothwell @ 2011-08-22 1:51 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Josh Boyer, Niklaus Giger, Tony Breeds
[-- Attachment #1: Type: text/plain, Size: 455 bytes --]
Hi all,
Today's linux-next merge of the net tree got a conflict in
arch/powerpc/configs/40x/hcu4_defconfig between commit 9fcd768d0cc8
("powerpc/40x: Remove obsolete HCU4 board") from the 4xx tree and commit
3b3bceef26f8 ("net: fix IBM EMAC driver after rename") from the net tree.
The former commit removes the file, so I just did that.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH 0/2] Improve sequence number generation.
From: George Spelvin @ 2011-08-22 2:06 UTC (permalink / raw)
To: linux, tytso; +Cc: dan, davem, gerrit, herbert, linux-kernel, mpm, netdev, w
In-Reply-To: <20110821032753.GA8992@thunk.org>
> Here's a random thought --- it won't help on anything other than
> modern x86's, but who's to say we have to use the same algorithm on
> all platforms?
We absolutely do not. With 15 64-bit registers, there are a lot more
efficient algorithms available than x86-32.
Here are my current timing experiments trying to find an efficient
hash for that case. Timings are for 100,000 iterations, so these are
generally in the 100-200 cycles range per operation.
This is 32-bit code, even though it's running on 64-bit machines.
The first 3 are various MD5 implementations (standard, with the k[]
constants in an external array, with the input and K values scheduled
separately so it's a 64-word linear fetch while running).
Then are three similar variants of two-at-a-time MD5 computation.
The lines reporting 0 time are the second outputs.
The last two MD5 timings (9 and 10) are the current half_md4_transform
and twothirdsMD4Transform. Those are the timing figures to match,
or preferably beat.
ChaCha is 8 rounds, and simply not fast enough.
The Skein192 (to be renamed; it's NOT approved by the designers!) is a
36-round, 6x32-bit variant of the SHA-3 candidate Skein. 0 is C code,
1 and 2 are rolled up assembly variants, 3 and 4 are unrolled assembly,
and 5 is unrolled assembly that also drops the tweak words. (Which is
hardly important if we're only hashing one block.)
That, as you can see, is about half the time of MD5 and competitive with
the 2/3 MD4. And probably considerably more secure. (It's basically a
secure 192-bit hash with zero margin; I could maybe shave another couple
of rounds and still have 128-bit security.)
Shabal is a supposedly-fast SHA-3 candidate that made it to round 2,
just to see what the timing is like. The second line is a half-size
variant that works on 8 as opposed to 16 words at a time.
2.4 GHz Phenom, hot cache:
MD5 (& half MD4) implementations:
0: 36912577 cycles 16d174cf 10a7082f e1a2b897 3faddc63
1: 36937728 cycles 16d174cf 10a7082f e1a2b897 3faddc63
2: 37354723 cycles 16d174cf 10a7082f e1a2b897 3faddc63
3: 58866027 cycles 16d174cf 10a7082f e1a2b897 3faddc63
4: 0 cycles 16d174cf 10a7082f e1a2b897 3faddc63
5: 96074375 cycles 16d174cf 10a7082f e1a2b897 3faddc63
6: 0 cycles 16d174cf 10a7082f e1a2b897 3faddc63
7: 101722571 cycles 16d174cf 10a7082f e1a2b897 3faddc63
8: 0 cycles 16d174cf 10a7082f e1a2b897 3faddc63
9: 12321905 cycles b4b721c6 5635b583 b06c6474 c9871bee
10: 18038018 cycles 336f8820 5565aa9b 0133a23a 0b62780f
ChaCha implementations:
0: 37345090 cycles 751ddf6a 6977b031 60730a4f c1e2d89e
1: 30782411 cycles d5fec2fe a8937844 33da9645 cbff3484
Skein192 implementations:
0: 30343213 cycles 646ce01c 7f2228dd 229a336d 033748b5 0de3a665 c79cf4f7
1: 22137253 cycles 646ce01c 7f2228dd 229a336d 033748b5 0de3a665 c79cf4f7
2: 22439643 cycles 646ce01c 7f2228dd 229a336d 033748b5 0de3a665 c79cf4f7
3: 18189990 cycles 646ce01c 7f2228dd 229a336d 033748b5 0de3a665 c79cf4f7
4: 19025781 cycles 646ce01c 7f2228dd 229a336d 033748b5 0de3a665 c79cf4f7
5: 17335443 cycles 646ce01c 7f2228dd 229a336d 033748b5 0de3a665 c79cf4f7
Shabal implementations:
0: 177585782 cycles 6c192c71 ed0912f7 ec4513bb c8f03710 8e4e71b2 5200adff f4f40b0c 81ab7e54
1: 88048716 cycles 51e5dab0 ed0912f7 ec4513bb c8f03710 8e4e71b2 5200adff f4f40b0c 81ab7e54
2.4 GHz Phenom, "cool cache": Run each of the 20 code paths once, then repeat 100,000 times.
MD5 (& half MD4) implementations:
0: 43746107 cycles 16d174cf 10a7082f e1a2b897 3faddc63
1: 43682485 cycles 16d174cf 10a7082f e1a2b897 3faddc63
2: 43554706 cycles 16d174cf 10a7082f e1a2b897 3faddc63
3: 65376283 cycles 16d174cf 10a7082f e1a2b897 3faddc63
4: 0 cycles 16d174cf 10a7082f e1a2b897 3faddc63
5: 105050654 cycles 16d174cf 10a7082f e1a2b897 3faddc63
6: 0 cycles 16d174cf 10a7082f e1a2b897 3faddc63
7: 109949761 cycles 16d174cf 10a7082f e1a2b897 3faddc63
8: 0 cycles 16d174cf 10a7082f e1a2b897 3faddc63
9: 19284802 cycles b4b721c6 5635b583 b06c6474 c9871bee
10: 24359312 cycles 336f8820 5565aa9b 0133a23a 0b62780f
ChaCha implementations:
0: 46379423 cycles 751ddf6a 6977b031 60730a4f c1e2d89e
1: 38641131 cycles d5fec2fe a8937844 33da9645 cbff3484
Skein192 implementations:
0: 38125833 cycles 646ce01c 7f2228dd 229a336d 033748b5 0de3a665 c79cf4f7
1: 31800936 cycles 646ce01c 7f2228dd 229a336d 033748b5 0de3a665 c79cf4f7
2: 29010869 cycles 646ce01c 7f2228dd 229a336d 033748b5 0de3a665 c79cf4f7
3: 25627838 cycles 646ce01c 7f2228dd 229a336d 033748b5 0de3a665 c79cf4f7
4: 25913924 cycles 646ce01c 7f2228dd 229a336d 033748b5 0de3a665 c79cf4f7
5: 24318110 cycles 646ce01c 7f2228dd 229a336d 033748b5 0de3a665 c79cf4f7
Shabal implementations:
0: 185723030 cycles 6c192c71 ed0912f7 ec4513bb c8f03710 8e4e71b2 5200adff f4f40b0c 81ab7e54
1: 92834811 cycles 51e5dab0 ed0912f7 ec4513bb c8f03710 8e4e71b2 5200adff f4f40b0c 81ab7e54
2.67 GHz i7 (Xeon W3520), hot cache:
MD5 (& half MD4) implementations:
0: 36919956 cycles 16d174cf 10a7082f e1a2b897 3faddc63
1: 37156578 cycles 16d174cf 10a7082f e1a2b897 3faddc63
2: 35044283 cycles 16d174cf 10a7082f e1a2b897 3faddc63
3: 61506553 cycles 16d174cf 10a7082f e1a2b897 3faddc63
4: 0 cycles 16d174cf 10a7082f e1a2b897 3faddc63
5: 97228616 cycles 16d174cf 10a7082f e1a2b897 3faddc63
6: 0 cycles 16d174cf 10a7082f e1a2b897 3faddc63
7: 102025434 cycles 16d174cf 10a7082f e1a2b897 3faddc63
8: 0 cycles 16d174cf 10a7082f e1a2b897 3faddc63
9: 11890788 cycles b4b721c6 5635b583 b06c6474 c9871bee
10: 19542853 cycles 336f8820 5565aa9b 0133a23a 0b62780f
ChaCha implementations:
0: 32864931 cycles 751ddf6a 6977b031 60730a4f c1e2d89e
1: 28502254 cycles d5fec2fe a8937844 33da9645 cbff3484
Skein192 implementations:
0: 28894544 cycles 646ce01c 7f2228dd 229a336d 033748b5 0de3a665 c79cf4f7
1: 25963843 cycles 646ce01c 7f2228dd 229a336d 033748b5 0de3a665 c79cf4f7
2: 26394942 cycles 646ce01c 7f2228dd 229a336d 033748b5 0de3a665 c79cf4f7
3: 22960214 cycles 646ce01c 7f2228dd 229a336d 033748b5 0de3a665 c79cf4f7
4: 22458045 cycles 646ce01c 7f2228dd 229a336d 033748b5 0de3a665 c79cf4f7
5: 21020691 cycles 646ce01c 7f2228dd 229a336d 033748b5 0de3a665 c79cf4f7
Shabal implementations:
0: 107339671 cycles 6c192c71 ed0912f7 ec4513bb c8f03710 8e4e71b2 5200adff f4f40b0c 81ab7e54
1: 52250187 cycles 51e5dab0 ed0912f7 ec4513bb c8f03710 8e4e71b2 5200adff f4f40b0c 81ab7e54
2.67 GHz i7 (Xeon W3520), cool cache:
MD5 (& half MD4) implementations:
0: 38680693 cycles 16d174cf 10a7082f e1a2b897 3faddc63
1: 37812504 cycles 16d174cf 10a7082f e1a2b897 3faddc63
2: 35577261 cycles 16d174cf 10a7082f e1a2b897 3faddc63
3: 60584516 cycles 16d174cf 10a7082f e1a2b897 3faddc63
4: 0 cycles 16d174cf 10a7082f e1a2b897 3faddc63
5: 96525869 cycles 16d174cf 10a7082f e1a2b897 3faddc63
6: 0 cycles 16d174cf 10a7082f e1a2b897 3faddc63
7: 98360974 cycles 16d174cf 10a7082f e1a2b897 3faddc63
8: 0 cycles 16d174cf 10a7082f e1a2b897 3faddc63
9: 13622987 cycles b4b721c6 5635b583 b06c6474 c9871bee
10: 20895171 cycles 336f8820 5565aa9b 0133a23a 0b62780f
ChaCha implementations:
0: 34210571 cycles 751ddf6a 6977b031 60730a4f c1e2d89e
1: 29135985 cycles d5fec2fe a8937844 33da9645 cbff3484
Skein192 implementations:
0: 29621108 cycles 646ce01c 7f2228dd 229a336d 033748b5 0de3a665 c79cf4f7
1: 27885244 cycles 646ce01c 7f2228dd 229a336d 033748b5 0de3a665 c79cf4f7
2: 26022084 cycles 646ce01c 7f2228dd 229a336d 033748b5 0de3a665 c79cf4f7
3: 22360719 cycles 646ce01c 7f2228dd 229a336d 033748b5 0de3a665 c79cf4f7
4: 24639107 cycles 646ce01c 7f2228dd 229a336d 033748b5 0de3a665 c79cf4f7
5: 21072150 cycles 646ce01c 7f2228dd 229a336d 033748b5 0de3a665 c79cf4f7
Shabal implementations:
0: 105186652 cycles 6c192c71 ed0912f7 ec4513bb c8f03710 8e4e71b2 5200adff f4f40b0c 81ab7e54
1: 57009351 cycles 51e5dab0 ed0912f7 ec4513bb c8f03710 8e4e71b2 5200adff f4f40b0c 81ab7e54
^ permalink raw reply
* linux kernel development
From: Niloofar Fazlollahi @ 2011-08-22 4:51 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, linux-next
In-Reply-To: <CAK8ka9y1VhMzS0X2GSEg4AQzSMPwOkS3HQxBuX4t-Rp-_OwDow@mail.gmail.com>
Hi,
I have a generic question and appreciate your kind response.
What is the process and requirements for getting the linux kernel community
approval to commit a code into linux kernel (related to networking - TCP).
Regards
Niloofar F
^ permalink raw reply
* Re: linux kernel development
From: Américo Wang @ 2011-08-22 4:53 UTC (permalink / raw)
To: Niloofar Fazlollahi; +Cc: netdev, linux-kernel, linux-next
In-Reply-To: <CAK8ka9wP_V7ngtR0jv7T3vNZoTep9c18=AgRSe9efYAyXejUPg@mail.gmail.com>
On Mon, Aug 22, 2011 at 12:51 PM, Niloofar Fazlollahi
<nfazlollahi@gmail.com> wrote:
> Hi,
>
> I have a generic question and appreciate your kind response.
>
> What is the process and requirements for getting the linux kernel community
>
> approval to commit a code into linux kernel (related to networking - TCP).
Hello,
Please read the documents in Documentation/development-process/ directory
of the kernel source code.
Thanks.
^ permalink raw reply
* Re: [PATCH v2] Proportional Rate Reduction for TCP.
From: Nandita Dukkipati @ 2011-08-22 6:21 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: David S. Miller, Netdev, Tom Herbert, Matt Mathis, Yuchung Cheng
In-Reply-To: <alpine.DEB.2.00.1108201534590.24318@melkinpaasi.cs.helsinki.fi>
On Sat, Aug 20, 2011 at 5:41 AM, Ilpo Järvinen
<ilpo.jarvinen@helsinki.fi> wrote:
> On Fri, 19 Aug 2011, Nandita Dukkipati wrote:
>
>> Forgot to turn off gmail's rich formatting, so re-sending to the list.
>>
>> On Fri, Aug 19, 2011 at 3:25 AM, Ilpo Järvinen
>> <ilpo.jarvinen@helsinki.fi> wrote:
>> >
>> > On Fri, 19 Aug 2011, Nandita Dukkipati wrote:
>> >
>> > > +static void tcp_update_cwnd_in_recovery(struct sock *sk, int newly_acked_sacked,
>> > > + int fast_rexmit, int flag)
>> > > +{
>> > > + struct tcp_sock *tp = tcp_sk(sk);
>> > > + int sndcnt = 0;
>> > > + int delta = tp->snd_ssthresh - tcp_packets_in_flight(tp);
>> > > +
>> > > + if (tcp_packets_in_flight(tp) > tp->snd_ssthresh) {
>> > > + if (WARN_ON(!tp->prior_cwnd))
>> > > + tp->prior_cwnd = 1;
>> >
>> > This should still be made larger to avoid problems if it ever will be
>> > needed.
>>
>> I am letting the value remain at 1, mainly because this is the valid
>> lowest non-zero value for snd_cwnd to take on. The main purpose of
>> this code is to catch any lurking bug outside of PRR which results in
>> an undesirable divide by 0 in PRR. I would like to fix that bug if I
>> find this code is executed.
>
> NACK, until this value is at least 2 * tp->snd_ssthresh. Or alternatively
> the fallback is removed so that we DBZ and do not end up wrecking the
> network.
If prior_cwnd is suspect at this point, snd_ssthresh cannot be trusted either.
So it appears to me that it's best to remove the fallback and spare
the network.
Done in patch v4.
Nandita
>
> Other than that I'm ok with the patch (assuming the branches I brought
> up earlier is ok for everybody else).
>
>
> --
> i.
^ permalink raw reply
* [PATCH v4] Proportional Rate Reduction for TCP.
From: Nandita Dukkipati @ 2011-08-22 6:21 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Tom Herbert, Matt Mathis, Yuchung Cheng,
Nandita Dukkipati
In-Reply-To: <1313803779-6221-1-git-send-email-nanditad@google.com>
This patch implements Proportional Rate Reduction (PRR) for TCP.
PRR is an algorithm that determines TCP's sending rate in fast
recovery. PRR avoids excessive window reductions and aims for
the actual congestion window size at the end of recovery to be as
close as possible to the window determined by the congestion control
algorithm. PRR also improves accuracy of the amount of data sent
during loss recovery.
The patch implements the recommended flavor of PRR called PRR-SSRB
(Proportional rate reduction with slow start reduction bound) and
replaces the existing rate halving algorithm. PRR improves upon the
existing Linux fast recovery under a number of conditions including:
1) burst losses where the losses implicitly reduce the amount of
outstanding data (pipe) below the ssthresh value selected by the
congestion control algorithm and,
2) losses near the end of short flows where application runs out of
data to send.
As an example, with the existing rate halving implementation a single
loss event can cause a connection carrying short Web transactions to
go into the slow start mode after the recovery. This is because during
recovery Linux pulls the congestion window down to packets_in_flight+1
on every ACK. A short Web response often runs out of new data to send
and its pipe reduces to zero by the end of recovery when all its packets
are drained from the network. Subsequent HTTP responses using the same
connection will have to slow start to raise cwnd to ssthresh. PRR on
the other hand aims for the cwnd to be as close as possible to ssthresh
by the end of recovery.
A description of PRR and a discussion of its performance can be found at
the following links:
- IETF Draft:
http://tools.ietf.org/html/draft-mathis-tcpm-proportional-rate-reduction-01
- IETF Slides:
http://www.ietf.org/proceedings/80/slides/tcpm-6.pdf
http://tools.ietf.org/agenda/81/slides/tcpm-2.pdf
- Paper to appear in Internet Measurements Conference (IMC) 2011:
Improving TCP Loss Recovery
Nandita Dukkipati, Matt Mathis, Yuchung Cheng
Signed-off-by: Nandita Dukkipati <nanditad@google.com>
---
Changelog since v3:
- Removed the fallback of cwnd to 1 in tcp_update_cwnd_recovery(), for the extremely
unlikely event that tp->prior_cwnd takes on a value of 0 (bug outside of PRR).
Changelog since v2:
- Used div_u64 in tcp_update_cwnd_in_recovery() to ensure portable 64-bit division.
- Removed an empty line in tcp_complete_cwr().
Changelog since v1:
- Took care of overflow for large congestion windows in tcp_update_cwnd_in_recovery().
- Renamed prr_cwnd to prior_cwnd.
- Renamed pkts_delivered to newly_acked_sacked.
include/linux/tcp.h | 4 +++
net/ipv4/tcp_input.c | 58 +++++++++++++++++++++++++++++++++++++++++++-----
net/ipv4/tcp_output.c | 7 +++++-
3 files changed, 62 insertions(+), 7 deletions(-)
diff --git a/include/linux/tcp.h b/include/linux/tcp.h
index 531ede8..6b63b31 100644
--- a/include/linux/tcp.h
+++ b/include/linux/tcp.h
@@ -379,6 +379,10 @@ struct tcp_sock {
u32 snd_cwnd_clamp; /* Do not allow snd_cwnd to grow above this */
u32 snd_cwnd_used;
u32 snd_cwnd_stamp;
+ u32 prior_cwnd; /* Congestion window at start of Recovery. */
+ u32 prr_delivered; /* Number of newly delivered packets to
+ * receiver in Recovery. */
+ u32 prr_out; /* Total number of pkts sent during Recovery. */
u32 rcv_wnd; /* Current receiver window */
u32 write_seq; /* Tail(+1) of data held in tcp send buffer */
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index ea0d218..385c470 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -2830,9 +2830,13 @@ static int tcp_try_undo_loss(struct sock *sk)
static inline void tcp_complete_cwr(struct sock *sk)
{
struct tcp_sock *tp = tcp_sk(sk);
- /* Do not moderate cwnd if it's already undone in cwr or recovery */
- if (tp->undo_marker && tp->snd_cwnd > tp->snd_ssthresh) {
- tp->snd_cwnd = tp->snd_ssthresh;
+
+ /* Do not moderate cwnd if it's already undone in cwr or recovery. */
+ if (tp->undo_marker) {
+ if (inet_csk(sk)->icsk_ca_state == TCP_CA_CWR)
+ tp->snd_cwnd = min(tp->snd_cwnd, tp->snd_ssthresh);
+ else /* PRR */
+ tp->snd_cwnd = tp->snd_ssthresh;
tp->snd_cwnd_stamp = tcp_time_stamp;
}
tcp_ca_event(sk, CA_EVENT_COMPLETE_CWR);
@@ -2950,6 +2954,38 @@ void tcp_simple_retransmit(struct sock *sk)
}
EXPORT_SYMBOL(tcp_simple_retransmit);
+/* This function implements the PRR algorithm, specifcally the PRR-SSRB
+ * (proportional rate reduction with slow start reduction bound) as described in
+ * http://www.ietf.org/id/draft-mathis-tcpm-proportional-rate-reduction-01.txt.
+ * It computes the number of packets to send (sndcnt) based on packets newly
+ * delivered:
+ * 1) If the packets in flight is larger than ssthresh, PRR spreads the
+ * cwnd reductions across a full RTT.
+ * 2) If packets in flight is lower than ssthresh (such as due to excess
+ * losses and/or application stalls), do not perform any further cwnd
+ * reductions, but instead slow start up to ssthresh.
+ */
+static void tcp_update_cwnd_in_recovery(struct sock *sk, int newly_acked_sacked,
+ int fast_rexmit, int flag)
+{
+ struct tcp_sock *tp = tcp_sk(sk);
+ int sndcnt = 0;
+ int delta = tp->snd_ssthresh - tcp_packets_in_flight(tp);
+
+ if (tcp_packets_in_flight(tp) > tp->snd_ssthresh) {
+ u64 dividend = (u64)tp->snd_ssthresh * tp->prr_delivered +
+ tp->prior_cwnd - 1;
+ sndcnt = div_u64(dividend, tp->prior_cwnd) - tp->prr_out;
+ } else {
+ sndcnt = min_t(int, delta,
+ max_t(int, tp->prr_delivered - tp->prr_out,
+ newly_acked_sacked) + 1);
+ }
+
+ sndcnt = max(sndcnt, (fast_rexmit ? 1 : 0));
+ tp->snd_cwnd = tcp_packets_in_flight(tp) + sndcnt;
+}
+
/* Process an event, which can update packets-in-flight not trivially.
* Main goal of this function is to calculate new estimate for left_out,
* taking into account both packets sitting in receiver's buffer and
@@ -2961,7 +2997,8 @@ EXPORT_SYMBOL(tcp_simple_retransmit);
* It does _not_ decide what to send, it is made in function
* tcp_xmit_retransmit_queue().
*/
-static void tcp_fastretrans_alert(struct sock *sk, int pkts_acked, int flag)
+static void tcp_fastretrans_alert(struct sock *sk, int pkts_acked,
+ int newly_acked_sacked, int flag)
{
struct inet_connection_sock *icsk = inet_csk(sk);
struct tcp_sock *tp = tcp_sk(sk);
@@ -3111,13 +3148,17 @@ static void tcp_fastretrans_alert(struct sock *sk, int pkts_acked, int flag)
tp->bytes_acked = 0;
tp->snd_cwnd_cnt = 0;
+ tp->prior_cwnd = tp->snd_cwnd;
+ tp->prr_delivered = 0;
+ tp->prr_out = 0;
tcp_set_ca_state(sk, TCP_CA_Recovery);
fast_rexmit = 1;
}
if (do_lost || (tcp_is_fack(tp) && tcp_head_timedout(sk)))
tcp_update_scoreboard(sk, fast_rexmit);
- tcp_cwnd_down(sk, flag);
+ tp->prr_delivered += newly_acked_sacked;
+ tcp_update_cwnd_in_recovery(sk, newly_acked_sacked, fast_rexmit, flag);
tcp_xmit_retransmit_queue(sk);
}
@@ -3632,6 +3673,8 @@ static int tcp_ack(struct sock *sk, struct sk_buff *skb, int flag)
u32 prior_in_flight;
u32 prior_fackets;
int prior_packets;
+ int prior_sacked = tp->sacked_out;
+ int newly_acked_sacked = 0;
int frto_cwnd = 0;
/* If the ack is older than previous acks
@@ -3703,6 +3746,9 @@ static int tcp_ack(struct sock *sk, struct sk_buff *skb, int flag)
/* See if we can take anything off of the retransmit queue. */
flag |= tcp_clean_rtx_queue(sk, prior_fackets, prior_snd_una);
+ newly_acked_sacked = (prior_packets - prior_sacked) -
+ (tp->packets_out - tp->sacked_out);
+
if (tp->frto_counter)
frto_cwnd = tcp_process_frto(sk, flag);
/* Guarantee sacktag reordering detection against wrap-arounds */
@@ -3715,7 +3761,7 @@ static int tcp_ack(struct sock *sk, struct sk_buff *skb, int flag)
tcp_may_raise_cwnd(sk, flag))
tcp_cong_avoid(sk, ack, prior_in_flight);
tcp_fastretrans_alert(sk, prior_packets - tp->packets_out,
- flag);
+ newly_acked_sacked, flag);
} else {
if ((flag & FLAG_DATA_ACKED) && !frto_cwnd)
tcp_cong_avoid(sk, ack, prior_in_flight);
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 882e0b0..ca50408 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1796,11 +1796,13 @@ static int tcp_write_xmit(struct sock *sk, unsigned int mss_now, int nonagle,
tcp_event_new_data_sent(sk, skb);
tcp_minshall_update(tp, mss_now, skb);
- sent_pkts++;
+ sent_pkts += tcp_skb_pcount(skb);
if (push_one)
break;
}
+ if (inet_csk(sk)->icsk_ca_state == TCP_CA_Recovery)
+ tp->prr_out += sent_pkts;
if (likely(sent_pkts)) {
tcp_cwnd_validate(sk);
@@ -2294,6 +2296,9 @@ begin_fwd:
return;
NET_INC_STATS_BH(sock_net(sk), mib_idx);
+ if (inet_csk(sk)->icsk_ca_state == TCP_CA_Recovery)
+ tp->prr_out += tcp_skb_pcount(skb);
+
if (skb == tcp_write_queue_head(sk))
inet_csk_reset_xmit_timer(sk, ICSK_TIME_RETRANS,
inet_csk(sk)->icsk_rto,
--
1.7.3.1
^ permalink raw reply related
* Re: KVM induced panic on 2.6.38[2367] & 2.6.39
From: Avi Kivity @ 2011-08-22 6:36 UTC (permalink / raw)
To: Brad Campbell
Cc: Eric Dumazet, CaT, Borislav Petkov, linux-kernel, kvm, netdev
In-Reply-To: <4E4FB3B7.4040501@fnarfbargle.com>
On 08/20/2011 04:16 PM, Brad Campbell wrote:
> Author: Alexander Duyck <alexander.h.duyck@intel.com>
> Date: Thu Jul 1 13:28:27 2010 +0000
>
> x86: Drop CONFIG_MCORE2 check around setting of NET_IP_ALIGN
>
> This patch removes the CONFIG_MCORE2 check from around
> NET_IP_ALIGN. It is
> based on a suggestion from Andi Kleen. The assumption is that
> there are
> not any x86 cores where unaligned access is really slow, and this
> change
> would allow for a performance improvement to still exist on
> configurations
> that are not necessarily optimized for Core 2.
>
> Cc: Andi Kleen <ak@linux.intel.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: x86@kernel.org
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Acked-by: H. Peter Anvin <hpa@zytor.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
>
> :040000 040000 5a15867789080a2f67a74b17c4422f85b7a9fb4a
> b98769348bd765731ca3ff03b33764257e23226c M arch
>
> I can confirm this bug exists in the 3.0 kernel, however I'm unable to
> reproduce it on todays git.
>
> So anyone using netfilter, kvm and bridge on kernels between
> 2.6.36-rc1 and 3.0 may hit this bug, but it looks like it is fixed in
> the current 3.1-rc kernels.
>
Thanks for this effort. I don't think this patch is buggy in itself, it
merely exposed another bug which was fixed later on.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
^ permalink raw reply
* Re: KVM induced panic on 2.6.38[2367] & 2.6.39
From: Eric Dumazet @ 2011-08-22 6:45 UTC (permalink / raw)
To: Avi Kivity; +Cc: Brad Campbell, CaT, Borislav Petkov, linux-kernel, kvm, netdev
In-Reply-To: <4E51F8D4.5070804@redhat.com>
Le lundi 22 août 2011 à 09:36 +0300, Avi Kivity a écrit :
> On 08/20/2011 04:16 PM, Brad Campbell wrote:
> > Author: Alexander Duyck <alexander.h.duyck@intel.com>
> > Date: Thu Jul 1 13:28:27 2010 +0000
> >
> > x86: Drop CONFIG_MCORE2 check around setting of NET_IP_ALIGN
> >
> > This patch removes the CONFIG_MCORE2 check from around
> > NET_IP_ALIGN. It is
> > based on a suggestion from Andi Kleen. The assumption is that
> > there are
> > not any x86 cores where unaligned access is really slow, and this
> > change
> > would allow for a performance improvement to still exist on
> > configurations
> > that are not necessarily optimized for Core 2.
> >
> > Cc: Andi Kleen <ak@linux.intel.com>
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> > Cc: Ingo Molnar <mingo@redhat.com>
> > Cc: "H. Peter Anvin" <hpa@zytor.com>
> > Cc: x86@kernel.org
> > Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> > Acked-by: H. Peter Anvin <hpa@zytor.com>
> > Signed-off-by: David S. Miller <davem@davemloft.net>
> >
> > :040000 040000 5a15867789080a2f67a74b17c4422f85b7a9fb4a
> > b98769348bd765731ca3ff03b33764257e23226c M arch
> >
> > I can confirm this bug exists in the 3.0 kernel, however I'm unable to
> > reproduce it on todays git.
> >
> > So anyone using netfilter, kvm and bridge on kernels between
> > 2.6.36-rc1 and 3.0 may hit this bug, but it looks like it is fixed in
> > the current 3.1-rc kernels.
> >
>
> Thanks for this effort. I don't think this patch is buggy in itself, it
> merely exposed another bug which was fixed later on.
>
Some piece of hardware has a 2-byte offset requirement, and driver
incorrectly assumed NET_IP_ALIGN was 2 on x86.
Brad, could you post your config (lsmod, dmesg) again ?
tg3.c code for example uses a private value, not related to NET_IP_ALIGN
#define TG3_RAW_IP_ALIGN 2
^ permalink raw reply
* [PATCH] fix pushed_seq in keepalive / zero window probe timer
From: Li Yu @ 2011-08-22 6:57 UTC (permalink / raw)
Cc: netdev@vger.kernel.org, davem, ilpo.jarvinen
In tcp_write_wakeup(), we may split the probe segment since send window or mss is larger than it.
so I think that we should update tp->pushed_seq after tcp_fragment(), is it right? thanks.
Signed-off-by: Li Yu <raise.sail@gmail.com>
CC: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
CC: David S. Miller <davem@davemloft.net>
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 882e0b0..659a71f 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -2784,9 +2784,6 @@ int tcp_write_wakeup(struct sock *sk)
unsigned int mss = tcp_current_mss(sk);
unsigned int seg_size = tcp_wnd_end(tp) - TCP_SKB_CB(skb)->seq;
- if (before(tp->pushed_seq, TCP_SKB_CB(skb)->end_seq))
- tp->pushed_seq = TCP_SKB_CB(skb)->end_seq;
-
/* We are probing the opening of a window
* but the window size is != 0
* must have been a result SWS avoidance ( sender )
@@ -2803,8 +2800,11 @@ int tcp_write_wakeup(struct sock *sk)
TCP_SKB_CB(skb)->flags |= TCPHDR_PSH;
TCP_SKB_CB(skb)->when = tcp_time_stamp;
err = tcp_transmit_skb(sk, skb, 1, GFP_ATOMIC);
- if (!err)
+ if (!err) {
tcp_event_new_data_sent(sk, skb);
+ if (before(tp->pushed_seq, TCP_SKB_CB(skb)->end_seq))
+ tp->pushed_seq = TCP_SKB_CB(skb)->end_seq;
+ }
return err;
} else {
if (between(tp->snd_up, tp->snd_una + 1, tp->snd_una + 0xFFFF))
^ permalink raw reply related
* Bussiness Proposal
From: KAHAL Louisa @ 2011-08-21 22:30 UTC (permalink / raw)
Good day,
I am Mr. Vincent Cheng, GBS, JP Chairman of the Hong Kong and Shanghai
Banking Corporation Limited.
i have a business proposal of Twenty Two Million, Five Hundred
Thousand United State Dollars only for you to
transact with me from my bank to your country.Having gone through a
methodical search, I decided to contact you hoping
that you will find this proposal interesting. Please on your
confirmation of this message and indicating your interest
All confirmable documents to back up the claims will be made available
to you prior to your acceptance
and as soon as I receive your return mail Via my email address:
vincentcheng209@yahoo.co.jp and I will let
you know what is required of you,your earliest response to this letter
will be appreciated.
Endeavour to let me know your decision rather than keep me waiting.
Best Regards,
Mr.Vincent Cheng.
^ permalink raw reply
* Re: BUG: rt2x00usb: Vendor Request 0x07 failed
From: Stanislaw Gruszka @ 2011-08-22 8:25 UTC (permalink / raw)
To: Marc Kleine-Budde; +Cc: linux-wireless, Netdev, Gertjan van Wingerde
In-Reply-To: <4E4F7364.2060609@pengutronix.de>
Hi
On Sat, Aug 20, 2011 at 10:42:12AM +0200, Marc Kleine-Budde wrote:
> I'm a running a sheeva plug (ARM/kirkwood) with a rt2800 USB stick in AP mode.
> Bus 001 Device 002: ID 1737:0071 Linksys WUSB600N v1 Dual-Band Wireless-N Network Adapter [Ralink RT2870]
First of all, the best way to get rt2x00 support is write to
(moderated for non-subscribers) list users@rt2x00.serialmonkey.com
> kernel is v3.0.3 +
> http://www.spinics.net/lists/linux-wireless/msg74377.html
> (see http://git.pengutronix.de/?p=mkl/linux-2.6.git;a=shortlog;h=refs/heads/wireless/rt2x00/v3.0.3)
We have now wireless-testing applied version of that fix (3 -patches):
http://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=commit;h=674db1344443204b6ce3293f2df8fd1b7665deea
http://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=commit;h=df71c9cfceea801e7e26e2c74241758ef9c042e5
http://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=commit;h=4b1bfb7d2d125af6653d6c2305356b2677f79dc6
> With the patch the oops is gone, but after a few hours it fails with:
>
> [30971.764840] phy0 -> rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed for offset 0x0438 with error -71.
Looks there is something wrong at USB bus. Perhaps this could be debugged
using CONFIG_USB_DEBUG and friends. Eventually look at vendor driver to
check if it does not do some quirks regarding usb bus could help.
> [32048.962920] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [32048.970801] hostapd D c02d85e0 0 1499 1 0x00000000
> [32048.977234] [<c02d85e0>] (schedule+0x478/0x4e8) from [<c02d9370>] (__mutex_lock_slowpath+0x64/0x88)
> [32048.986352] [<c02d9370>] (__mutex_lock_slowpath+0x64/0x88) from [<bf378f5c>] (rt2x00usb_vendor_request_buff+0x24/0xb8 [rt2x00usb])
> [32048.998185] [<bf378f5c>] (rt2x00usb_vendor_request_buff+0x24/0xb8 [rt2x00usb]) from [<bf38d034>] (rt2x00usb_register_read+0x34/0x44 [rt2800usb])
> [32049.011243] [<bf38d034>] (rt2x00usb_register_read+0x34/0x44 [rt2800usb]) from [<bf381d74>] (rt2800_config_shared_key+0xc4/0x11c [rt2800lib])
> [32049.023958] [<bf381d74>] (rt2800_config_shared_key+0xc4/0x11c [rt2800lib]) from [<bf36aac0>] (rt2x00mac_set_key+0x138/0x14c [rt2x00lib])
> [32049.036410] [<bf36aac0>] (rt2x00mac_set_key+0x138/0x14c [rt2x00lib]) from [<bf34379c>] (ieee80211_key_disable_hw_accel+0x80/0xd0 [mac80211])
> [32049.049221] [<bf34379c>] (ieee80211_key_disable_hw_accel+0x80/0xd0 [mac80211]) from [<bf343810>] (__ieee80211_key_destroy+0x24/0x6c [mac80211])
> [32049.062285] [<bf343810>] (__ieee80211_key_destroy+0x24/0x6c [mac80211]) from [<bf343bf4>] (ieee80211_key_link+0x10c/0x134 [mac80211])
> [32049.074471] [<bf343bf4>] (ieee80211_key_link+0x10c/0x134 [mac80211]) from [<bf33c3f8>] (ieee80211_add_key+0x104/0x130 [mac80211])
> [32049.086392] [<bf33c3f8>] (ieee80211_add_key+0x104/0x130 [mac80211]) from [<bf306cc8>] (nl80211_new_key+0xec/0x110 [cfg80211])
> [32049.097834] [<bf306cc8>] (nl80211_new_key+0xec/0x110 [cfg80211]) from [<c027542c>] (genl_rcv_msg+0x1bc/0x204)
As workaround I would try nohwcrypt module option.
Stanislaw
^ permalink raw reply
* Re: [PATCH] virtio-net: Read MAC only after initializing MSI-X
From: Michael S. Tsirkin @ 2011-08-22 8:36 UTC (permalink / raw)
To: Rusty Russell; +Cc: Sasha Levin, linux-kernel, virtualization, netdev, kvm
In-Reply-To: <87hb5a5m3x.fsf@rustcorp.com.au>
On Mon, Aug 22, 2011 at 09:54:50AM +0930, Rusty Russell wrote:
> On Fri, 19 Aug 2011 18:23:35 +0300, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > On Sat, Aug 13, 2011 at 11:51:01AM +0300, Sasha Levin wrote:
> > > The MAC of a virtio-net device is located at the first field of the device
> > > specific header. This header is located at offset 20 if the device doesn't
> > > support MSI-X or offset 24 if it does.
> > >
> > > Current code in virtnet_probe() used to probe the MAC before checking for
> > > MSI-X, which means that the read was always made from offset 20 regardless
> > > of whether MSI-X in enabled or not.
> > >
> > > This patch moves the MAC probe to after the detection of whether MSI-X is
> > > enabled. This way the MAC will be read from offset 24 if the device indeed
> > > supports MSI-X.
> > >
> > > Cc: Rusty Russell <rusty@rustcorp.com.au>
> > > Cc: Michael S. Tsirkin <mst@redhat.com>
> > > Cc: virtualization@lists.linux-foundation.org
> > > Cc: netdev@vger.kernel.org
> > > Cc: kvm@vger.kernel.org
> > > Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
> >
> > I am not sure I see a bug in virtio: the config pace layout simply
> > changes as msix is enabled and disabled (and if you look at the latest
> > draft, also on whether 64 bit features are enabled).
> > It doesn't depend on msix capability being present in device.
> >
> > The spec seems to be explicit enough:
> > If MSI-X is enabled for the device, two additional fields immediately
> > follow this header.
> >
> > So I'm guessing the bug is in kvm tools which assume
> > same layout for when msix is enabled and disabled.
> > qemu-kvm seems to do the right thing so the device
> > seems to get the correct mac.
>
> So, the config space moves once MSI-X is enabled? In which case, it
> should say "ONCE MSI-X is enabled..."
>
> Thanks,
> Rusty.
Yes. Or maybe 'WHEN' - since if MSI-X is disabled again, it moves back.
Let's update the spec to make it clearer?
--
MST
^ permalink raw reply
* Re: BUG: rt2x00usb: Vendor Request 0x07 failed
From: Marc Kleine-Budde @ 2011-08-22 9:09 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
Netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20110822082507.GB2422-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1964 bytes --]
On 08/22/2011 10:25 AM, Stanislaw Gruszka wrote:
> On Sat, Aug 20, 2011 at 10:42:12AM +0200, Marc Kleine-Budde wrote:
>> I'm a running a sheeva plug (ARM/kirkwood) with a rt2800 USB stick in AP mode.
>> Bus 001 Device 002: ID 1737:0071 Linksys WUSB600N v1 Dual-Band Wireless-N Network Adapter [Ralink RT2870]
>
> First of all, the best way to get rt2x00 support is write to
> (moderated for non-subscribers) list users-poMEt7QlJxcwIE2E9O76wjtx2kNaKg5H@public.gmane.org
Okay - will subscribe there.
>
>> kernel is v3.0.3 +
>> http://www.spinics.net/lists/linux-wireless/msg74377.html
>> (see http://git.pengutronix.de/?p=mkl/linux-2.6.git;a=shortlog;h=refs/heads/wireless/rt2x00/v3.0.3)
>
> We have now wireless-testing applied version of that fix (3 -patches):
> http://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=commit;h=674db1344443204b6ce3293f2df8fd1b7665deea
> http://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=commit;h=df71c9cfceea801e7e26e2c74241758ef9c042e5
> http://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=commit;h=4b1bfb7d2d125af6653d6c2305356b2677f79dc6
>
>> With the patch the oops is gone, but after a few hours it fails with:
>>
>> [30971.764840] phy0 -> rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed for offset 0x0438 with error -71.
>
> Looks there is something wrong at USB bus. Perhaps this could be debugged
> using CONFIG_USB_DEBUG and friends. Eventually look at vendor driver to
> check if it does not do some quirks regarding usb bus could help.
Seems the best is to try to reproduce with a different usb host controller.
thanks,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply
* [net-next PATCH] tcp: remove useless assignment statement in tcp_keepalive_timer
From: Li Yu @ 2011-08-22 10:03 UTC (permalink / raw)
To: netdev@vger.kernel.org
Remove useless assignment statement, it may be trash after refactoring?
Signed-off-by: Li Yu <raise.sail@gmail.com>
diff --git a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c
index ecd44b0..321ff2f 100644
--- a/net/ipv4/tcp_timer.c
+++ b/net/ipv4/tcp_timer.c
@@ -552,8 +552,6 @@ static void tcp_keepalive_timer (unsigned long data)
if (!sock_flag(sk, SOCK_KEEPOPEN) || sk->sk_state == TCP_CLOSE)
goto out;
- elapsed = keepalive_time_when(tp);
-
/* It is alive without keepalive 8) */
if (tp->packets_out || tcp_send_head(sk))
goto resched;
^ permalink raw reply related
* Re: [net-next PATCH] tcp: remove useless assignment statement in tcp_keepalive_timer
From: Christoph Paasch @ 2011-08-22 10:46 UTC (permalink / raw)
To: Li Yu; +Cc: netdev@vger.kernel.org
In-Reply-To: <4E52295D.8040901@gmail.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: Text/Plain; charset=gb18030, Size: 1250 bytes --]
No, if the condition afterwards evaluates to TRUE, and we go to the label
resched, inet_csk_reset_keepalive_timer(...) is called without elapsed being
set.
Cheers,
Christoph
On Monday 22 August 2011 wrote Li Yu:
> Remove useless assignment statement, it may be trash after refactoring?
>
> Signed-off-by: Li Yu <raise.sail@gmail.com>
> diff --git a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c
> index ecd44b0..321ff2f 100644
> --- a/net/ipv4/tcp_timer.c
> +++ b/net/ipv4/tcp_timer.c
> @@ -552,8 +552,6 @@ static void tcp_keepalive_timer (unsigned long data)
> if (!sock_flag(sk, SOCK_KEEPOPEN) || sk->sk_state == TCP_CLOSE)
> goto out;
>
> - elapsed = keepalive_time_when(tp);
> -
> /* It is alive without keepalive 8) */
> if (tp->packets_out || tcp_send_head(sk))
> goto resched;
>
> --
> 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
--
Christoph Paasch
PhD Student
IP Networking Lab --- http://inl.info.ucl.ac.be
MultiPath TCP in the Linux Kernel --- http://inl.info.ucl.ac.be/mptcp
Universit¨¦ Catholique de Louvain
www.rollerbulls.be
--
^ permalink raw reply
* Re: [net-next PATCH] tcp: remove useless assignment statement in tcp_keepalive_timer
From: Li Yu @ 2011-08-22 11:01 UTC (permalink / raw)
To: christoph.paasch; +Cc: netdev@vger.kernel.org
In-Reply-To: <201108221346.13210.christoph.paasch@uclouvain.be>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 1399 bytes --]
Oops, thanks for reminding !
Yu
ÓÚ 2011Äê08ÔÂ22ÈÕ 18:46, Christoph Paasch дµÀ:
> No, if the condition afterwards evaluates to TRUE, and we go to the label
> resched, inet_csk_reset_keepalive_timer(...) is called without elapsed being
> set.
>
> Cheers,
> Christoph
>
> On Monday 22 August 2011 wrote Li Yu:
>> Remove useless assignment statement, it may be trash after refactoring?
>>
>> Signed-off-by: Li Yu <raise.sail@gmail.com>
>> diff --git a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c
>> index ecd44b0..321ff2f 100644
>> --- a/net/ipv4/tcp_timer.c
>> +++ b/net/ipv4/tcp_timer.c
>> @@ -552,8 +552,6 @@ static void tcp_keepalive_timer (unsigned long data)
>> if (!sock_flag(sk, SOCK_KEEPOPEN) || sk->sk_state == TCP_CLOSE)
>> goto out;
>>
>> - elapsed = keepalive_time_when(tp);
>> -
>> /* It is alive without keepalive 8) */
>> if (tp->packets_out || tcp_send_head(sk))
>> goto resched;
>>
>> --
>> 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
>
> --
> Christoph Paasch
> PhD Student
>
> IP Networking Lab --- http://inl.info.ucl.ac.be
> MultiPath TCP in the Linux Kernel --- http://inl.info.ucl.ac.be/mptcp
> Universit¨¦ Catholique de Louvain
>
> www.rollerbulls.be
> --
>
^ permalink raw reply
* [PATCH net-next 1/5] be2net: Fix race in posting rx buffers.
From: Sathya Perla @ 2011-08-22 11:13 UTC (permalink / raw)
To: netdev
In-Reply-To: <1314011613-4519-1-git-send-email-sathya.perla@emulex.com>
There is a possibility of be_post_rx_frags() being called simultaneously from
both be_worker() (when rx_post_starved) and be_poll_rx() (when rxq->used is 0).
This can be avoided by posting rx buffers only when some completions have been
reaped.
Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
---
drivers/net/ethernet/emulex/benet/be_main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index ef62594..09eb699 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -1862,7 +1862,7 @@ loop_continue:
}
/* Refill the queue */
- if (atomic_read(&rxo->q.used) < RX_FRAGS_REFILL_WM)
+ if (work_done && atomic_read(&rxo->q.used) < RX_FRAGS_REFILL_WM)
be_post_rx_frags(rxo, GFP_ATOMIC);
/* All consumed */
--
1.7.4
^ permalink raw reply related
* [PATCH net-next 0/5] be2net: fixes
From: Sathya Perla @ 2011-08-22 11:13 UTC (permalink / raw)
To: netdev
Pls apply.
Sathya Perla (5):
be2net: Fix race in posting rx buffers.
be2net: get rid of memory mapped pci-cfg space address
be2net: fix erx->rx_drops_no_frags wrap around
be2net: increase FW update completion timeout
be2net: remove unused variable
drivers/net/ethernet/emulex/benet/be.h | 2 -
drivers/net/ethernet/emulex/benet/be_cmds.c | 2 +-
drivers/net/ethernet/emulex/benet/be_main.c | 50 ++++++++++++++------------
3 files changed, 28 insertions(+), 26 deletions(-)
--
1.7.4
^ permalink raw reply
* [PATCH net-next 2/5] be2net: get rid of memory mapped pci-cfg space address
From: Sathya Perla @ 2011-08-22 11:13 UTC (permalink / raw)
To: netdev
In-Reply-To: <1314011613-4519-1-git-send-email-sathya.perla@emulex.com>
Get rid of adapter->pcicfg and its use. Use pci_config_read/write_dword()
instead.
Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
---
drivers/net/ethernet/emulex/benet/be.h | 1 -
drivers/net/ethernet/emulex/benet/be_main.c | 27 ++++++++-------------------
2 files changed, 8 insertions(+), 20 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be.h b/drivers/net/ethernet/emulex/benet/be.h
index 12b5b51..868d7f4 100644
--- a/drivers/net/ethernet/emulex/benet/be.h
+++ b/drivers/net/ethernet/emulex/benet/be.h
@@ -298,7 +298,6 @@ struct be_adapter {
u8 __iomem *csr;
u8 __iomem *db; /* Door Bell */
- u8 __iomem *pcicfg; /* PCI config space */
struct mutex mbox_lock; /* For serializing mbox cmds to BE card */
struct be_dma_mem mbox_mem;
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index 09eb699..2375c0c 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -141,13 +141,15 @@ static int be_queue_alloc(struct be_adapter *adapter, struct be_queue_info *q,
static void be_intr_set(struct be_adapter *adapter, bool enable)
{
- u8 __iomem *addr = adapter->pcicfg + PCICFG_MEMBAR_CTRL_INT_CTRL_OFFSET;
- u32 reg = ioread32(addr);
- u32 enabled = reg & MEMBAR_CTRL_INT_CTRL_HOSTINTR_MASK;
+ u32 reg, enabled;
if (adapter->eeh_err)
return;
+ pci_read_config_dword(adapter->pdev, PCICFG_MEMBAR_CTRL_INT_CTRL_OFFSET,
+ ®);
+ enabled = reg & MEMBAR_CTRL_INT_CTRL_HOSTINTR_MASK;
+
if (!enabled && enable)
reg |= MEMBAR_CTRL_INT_CTRL_HOSTINTR_MASK;
else if (enabled && !enable)
@@ -155,7 +157,8 @@ static void be_intr_set(struct be_adapter *adapter, bool enable)
else
return;
- iowrite32(reg, addr);
+ pci_write_config_dword(adapter->pdev,
+ PCICFG_MEMBAR_CTRL_INT_CTRL_OFFSET, reg);
}
static void be_rxq_notify(struct be_adapter *adapter, u16 qid, u16 posted)
@@ -2951,14 +2954,12 @@ static void be_unmap_pci_bars(struct be_adapter *adapter)
iounmap(adapter->csr);
if (adapter->db)
iounmap(adapter->db);
- if (adapter->pcicfg && be_physfn(adapter))
- iounmap(adapter->pcicfg);
}
static int be_map_pci_bars(struct be_adapter *adapter)
{
u8 __iomem *addr;
- int pcicfg_reg, db_reg;
+ int db_reg;
if (lancer_chip(adapter)) {
addr = ioremap_nocache(pci_resource_start(adapter->pdev, 0),
@@ -2978,10 +2979,8 @@ static int be_map_pci_bars(struct be_adapter *adapter)
}
if (adapter->generation == BE_GEN2) {
- pcicfg_reg = 1;
db_reg = 4;
} else {
- pcicfg_reg = 0;
if (be_physfn(adapter))
db_reg = 4;
else
@@ -2993,16 +2992,6 @@ static int be_map_pci_bars(struct be_adapter *adapter)
goto pci_map_err;
adapter->db = addr;
- if (be_physfn(adapter)) {
- addr = ioremap_nocache(
- pci_resource_start(adapter->pdev, pcicfg_reg),
- pci_resource_len(adapter->pdev, pcicfg_reg));
- if (addr == NULL)
- goto pci_map_err;
- adapter->pcicfg = addr;
- } else
- adapter->pcicfg = adapter->db + SRIOV_VF_PCICFG_OFFSET;
-
return 0;
pci_map_err:
be_unmap_pci_bars(adapter);
--
1.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox