* Re: [PATCHv4 net-next-2.6 4/5] XFRM,IPv6: Add IRO remapping hook in xfrm_input()
From: Arnaud Ebalard @ 2010-10-06 21:42 UTC (permalink / raw)
To: Herbert Xu; +Cc: David S. Miller, Eric Dumazet, Hideaki YOSHIFUJI, netdev
In-Reply-To: <20101006012509.GA3540@gondor.apana.org.au>
Hi Herbert,
Herbert Xu <herbert@gondor.apana.org.au> writes:
> On Wed, Oct 06, 2010 at 01:28:42AM +0200, Arnaud Ebalard wrote:
>>
>> 1) First, current net-next-2.6 (no patches applied)
>> 2) then, with my patches applied and CONFIG_XFRM_SUB_POLICY enabled
>> 3) then, with my patches applied and CONFIG_XFRM_SUB_POLICY disabled
>
> To measure the effect of this properly you should use null
> encryption/hashing and look at the CPU utilisation with minimum
> packet sizes.
I did that w/ the following kernels on the receiver (same as before):
- kernel 1: w/o patches (net-next-2.6)
- kernel 2: patches applied w/ CONFIG_XFRM_SUB_POLICY
- kernel 3: patches applied w/o CONFIG_XFRM_SUB_POLICY
5 runs of sending 1073741824 bytes over TCP protected using ESP (null
enc and null auth) in transport mode, forcing small packets:
dd if=/dev/zero bs=1024 count=1048576 | nc --mtu=100 -x <v4orv6dst> 1234
5 runs for each kernel for IPv4 and IPv6. I keep only the 3 central
values provided by dd indicating the completion of the emission (remove
highest and smallest) and do an average w/ those 3 values:
IPv4 IPv6
kernel 1 70.0815s 72.4843s
kernel 2 69.8335s 72.3462s
kernel 3 69.9758s 72.3588s
I used the exact same method for the tests for the 3 cases (reboot,
started the test, nothing else running). I am unable to explain why it's
longer for the test to complete with an unpatched kernel but this is
what I get. Maybe it is just an artefact and the impact is just simply
too small to be mesured. Anyway, the whole set of results are at the end
of the email.
>> > With your remapping, would it be possible to add dummy xfrm_state
>> > objects with the remapped destination address that could then call
>> > xfrm6_input_addr?
>> >
>> > That way normal IPsec users would not be affected at all while
>> > preserving your new functionality.
>>
>> I don't think I can do that easily (at all?) with what XFRM provides,
>> can I? Or at least I don't see how it is possible because I would need
>> some kind of policy for the state to be applied and the only trigger I
>> see is the src/dst address mismatch when processing the IPsec packet.
>
> So do you know the remapped destination addresses a priori?
I have both the HoA and the CoA (this is x->coaddr in my state. '::' is
allowed if I want to allow anything), but the appplication of the state
needs to be done for traffic meant for the HoA and not blindly for all
the IPsec traffic received with the CoA (as source or destination).
it's not possible to just blindly remap things based on the on-wire
address and the fact it is IPsec traffic. For instance, if some tunnel
mode IPsec traffic between a MN and its HA is used in parallel, I cannot
remap the CoA from received packets on the MN to the HoA.
That's the reason why the lookup is done via something stable (i.e. the
HoA) which is derived from the SPI during SA lookup.
> If not then then other possibility would be to add the code hook
> in case of xfrm_state_lookup failure.
This would work for destination address. But it has the drawback of
requiring a first lookup (guaranteed to fail if destination remapping
for the feature) and then a second (somehow w/o using the destination
address). Source check would still be done in all cases.
> But more importantly you need to solve the hash collission issue
> that I mentioned earlier. Without that it won't work at all.
You are correct. The fact that the byspi hash table contains all states
(for in and out traffic) and that the state lookup does not involve the
direction but only the destination address (damn, the one I remove ;-))
is a real issue. It just makes the state lookup unreliable when I pass
NULL as daddr for incoming traffic. Thanks for pointing that.
I don't see any good solution yet (state have no direction) but I will
definitely focus on that issue and spend some time on it tomorrow.
Cheers,
a+
The full set of results for the tests:
* kernel 1
$ dd if=/dev/zero bs=1024 count=1048576 | nc --mtu=100 -x 192.168.0.14 1234
1073741824 bytes (1.1 GB) copied, 70.0393 s, 15.3 MB/s
1073741824 bytes (1.1 GB) copied, 70.2442 s, 15.3 MB/s
1073741824 bytes (1.1 GB) copied, 70.1995 s, 15.3 MB/s
1073741824 bytes (1.1 GB) copied, 70.0057 s, 15.3 MB/s
1073741824 bytes (1.1 GB) copied, 69.9887 s, 15.3 MB/s
$ dd if=/dev/zero bs=1024 count=1048576 | nc --mtu=100 -x fdff::1 1234
1073741824 bytes (1.1 GB) copied, 72.5605 s, 14.8 MB/s
1073741824 bytes (1.1 GB) copied, 72.9725 s, 14.7 MB/s
1073741824 bytes (1.1 GB) copied, 72.3099 s, 14.8 MB/s
1073741824 bytes (1.1 GB) copied, 72.435 s, 14.8 MB/s
1073741824 bytes (1.1 GB) copied, 72.4573 s, 14.8 MB/s
* kernel 2
$ dd if=/dev/zero bs=1024 count=1048576 | nc --mtu=100 -x 192.168.0.14 1234
1073741824 bytes (1.1 GB) copied, 69.6845 s, 15.4 MB/s
1073741824 bytes (1.1 GB) copied, 69.9419 s, 15.4 MB/s
1073741824 bytes (1.1 GB) copied, 69.8615 s, 15.4 MB/s
1073741824 bytes (1.1 GB) copied, 70.0142 s, 15.3 MB/s
1073741824 bytes (1.1 GB) copied, 69.6970 s, 15.4 MB/s
$ dd if=/dev/zero bs=1024 count=1048576 | nc --mtu=100 -x fdff::1 1234
1073741824 bytes (1.1 GB) copied, 72.4252 s, 14.8 MB/s
1073741824 bytes (1.1 GB) copied, 71.5411 s, 15.0 MB/s
1073741824 bytes (1.1 GB) copied, 72.2388 s, 14.9 MB/s
1073741824 bytes (1.1 GB) copied, 72.3745 s, 14.8 MB/s
1073741824 bytes (1.1 GB) copied, 72.6553 s, 14.8 MB/s
* kernel 3
$ dd if=/dev/zero bs=1024 count=1048576 | nc --mtu=100 -x 192.168.0.14 1234
1073741824 bytes (1.1 GB) copied, 69.8569 s, 15.4 MB/s
1073741824 bytes (1.1 GB) copied, 70.4445 s, 15.2 MB/s
1073741824 bytes (1.1 GB) copied, 69.8989 s, 15.4 MB/s
1073741824 bytes (1.1 GB) copied, 70.0238 s, 15.3 MB/s
1073741824 bytes (1.1 GB) copied, 70.0047 s, 15.3 MB/s
$ dd if=/dev/zero bs=1024 count=1048576 | nc --mtu=100 -x fdff::1 1234
1073741824 bytes (1.1 GB) copied, 72.4677 s, 14.8 MB/s
1073741824 bytes (1.1 GB) copied, 72.2757 s, 14.9 MB/s
1073741824 bytes (1.1 GB) copied, 72.2261 s, 14.9 MB/s
1073741824 bytes (1.1 GB) copied, 72.3331 s, 14.8 MB/s
1073741824 bytes (1.1 GB) copied, 72.8262 s, 14.7 MB/s
^ permalink raw reply
* [PATCH] Documentation/networking/ixgbevf.txt: Change file permissions to 644
From: Joe Perches @ 2010-10-06 22:09 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: netdev, Randy Dunlap, Greg Rose
Signed-off-by: Joe Perches <joe@perches.com>
---
diff --git a/Documentation/networking/ixgbevf.txt b/Documentation/networking/ixgbevf.txt
old mode 100755
new mode 100644
^ permalink raw reply
* Re: [PATCH] Documentation/networking/ixgbevf.txt: Change file permissions to 644
From: Jeff Kirsher @ 2010-10-06 22:16 UTC (permalink / raw)
To: Joe Perches; +Cc: netdev, Randy Dunlap, Greg Rose, Ben Hutchings, linux-doc
In-Reply-To: <1286402990.32241.10.camel@Joe-Laptop>
On Wed, Oct 6, 2010 at 15:09, Joe Perches <joe@perches.com> wrote:
> Signed-off-by: Joe Perches <joe@perches.com>
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com
> ---
> diff --git a/Documentation/networking/ixgbevf.txt b/Documentation/networking/ixgbevf.txt
> old mode 100755
> new mode 100644
>
FYI - Ben submitted this same patch 3 days ago to Randy and
linux-doc@vger.kernel.org.
--
Cheers,
Jeff
^ permalink raw reply
* Re: [PATCH] SIW: Module initialization
From: Stephen Hemminger @ 2010-10-06 22:26 UTC (permalink / raw)
To: Bart Van Assche
Cc: Bernard Metzler, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <AANLkTikL6u4Kzd1jibp77GMZfMebxusoDX39dPsNK3RW-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, 6 Oct 2010 18:06:52 +0200
Bart Van Assche <bvanassche-HInyCGIudOg@public.gmane.org> wrote:
> On Wed, Oct 6, 2010 at 12:02 AM, Stephen Hemminger
> <shemminger-ZtmgI6mnKB3QT0dZR+AlfA@public.gmane.org> wrote:
> > On Tue, 5 Oct 2010 12:57:21 +0200
> > Bart Van Assche <bvanassche-HInyCGIudOg@public.gmane.org> wrote:
> >
> >> > + * TODO: Dynamic device management (network device registration/removal).
> >>
> >> The current implementation is such that one siw device is created for
> >> each network device found at kernel module load time. That means that
> >> you force the user to load the siw kernel module after all other
> >> kernel modules that register a network device. I'm not sure that's a
> >> good idea.
> >
> > Then device should be controlled by a netlink (rtnl_link_ops) style
> > interface see vlan_netlink.c. Using netlink is extensible and provides
> > a cleaner interface than all these other parameterization methods.
>
> That will be a lot more work to implement than what Jason proposed:
> adding a sysfs variable per Ethernet driver, e.g.
> /sys/class/net/eth0/enable_iwarp.
But if we let code in with that API, then we have to maintain it.
Netlink is the way to go.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [net-next-2.6 PATCH v2] net: netif_set_real_num_rx_queues may cap num_rx_queues at init time
From: Jeff Kirsher @ 2010-10-07 0:05 UTC (permalink / raw)
To: davem
Cc: netdev, gospo, bphilips, Ben Hutchings, Eric Dumazet,
John Fastabend, Jeff Kirsher
From: John Fastabend <john.r.fastabend@intel.com>
Do not set num_rx_queues in netif_set_real_num_rx_queues() some
drivers will increase the real_num_rx_queues later due to a feature
changes or available interrupts increasing. By setting num_rx_queues
here this ends up creating a cap on the number of rx queues
available.
For example the ixgbe driver sets the max number of queues it intends
to use ever then sets the current number in use with the
netif_set_num_{rx|tx}_queues calls. With the current implementation
the number of rx queues gets limited so when a feature such as DCB
or FCoE is enabled the queues are no longer available.
kobjects will only be allocated for real_num_rx_queues so the waste
in memory is minimal.
CC: Ben Hutchings <bhutchings@solarflare.com>
CC: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
net/core/dev.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 7d14955..fd1b75a 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1593,8 +1593,6 @@ int netif_set_real_num_rx_queues(struct net_device *dev, unsigned int rxq)
rxq);
if (rc)
return rc;
- } else {
- dev->num_rx_queues = rxq;
}
dev->real_num_rx_queues = rxq;
^ permalink raw reply related
* Re: [PATCH] Documentation/networking/ixgbevf.txt: Change file permissions to 644
From: David Miller @ 2010-10-07 0:33 UTC (permalink / raw)
To: joe; +Cc: jeffrey.t.kirsher, netdev, rdunlap, gregory.v.rose
In-Reply-To: <1286402990.32241.10.camel@Joe-Laptop>
From: Joe Perches <joe@perches.com>
Date: Wed, 06 Oct 2010 15:09:50 -0700
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
> diff --git a/Documentation/networking/ixgbevf.txt b/Documentation/networking/ixgbevf.txt
> old mode 100755
> new mode 100644
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] neigh: RCU conversion of struct neighbour
From: David Miller @ 2010-10-07 0:49 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1286380456.9417.40.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 06 Oct 2010 17:54:16 +0200
> This is the second step for neighbour RCU conversion.
>
> (first was commit d6bf7817 : RCU conversion of neigh hash table)
>
> neigh_lookup() becomes lockless, but still take a reference on found
> neighbour. (no more read_lock()/read_unlock() on tbl->lock)
>
> struct neighbour gets an additional rcu_head field and is freed after an
> RCU grace period.
>
> Future work would need to eventually not take a reference on neighbour
> for temporary dst (DST_NOCACHE), but this would need dst->_neighbour to
> use a noref bit like we did for skb->_dst.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: Linux 2.6.36-rc7
From: Stephen Rothwell @ 2010-10-07 0:49 UTC (permalink / raw)
To: Linus Torvalds
Cc: Linux Kernel Mailing List, Russell King, James Bottomley,
David Miller, netdev, John W. Linville, Michal Marek,
Dmitry Torokhov
In-Reply-To: <AANLkTi=LsBNU+O2hqZUcM2nYM_ze6qPq3thwSZBMtY_v@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2788 bytes --]
Hi Linus,
On Wed, 6 Oct 2010 14:45:13 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> This should be the last -rc, I'm not seeing any reason to keep
> delaying a real release. There was still more changes to
> drivers/gpu/drm than I really would have hoped for, but they all look
> harmless and good. Famous last words.
I have no idea how critical any of this stuff is, but linux-next contain
the following in it's "current" trees i.e. stuff that is supposed to go
into 2.6.36. These are from the arm-current, scsi-rc-fixes, net-current,
wireless-current, kbuild-current, input-current and ide-curent trees
(contacts cc'd).
Arnaud Lacombe (1):
kconfig: delay symbol direct dependency initialization
[This one produces a lot of new warnings, but also fixes a bug ...]
Ben Hutchings (2):
Revert "ipv4: Make INET_LRO a bool instead of tristate."
netdev: Depend on INET before selecting INET_LRO
Dan Carpenter (1):
cls_u32: signedness bug
Dan Rosenberg (2):
sctp: prevent reading out-of-bounds memory
sctp: Fix out-of-bounds reading in sctp_asoc_get_hmac()
David Stevens (1):
ipv4: correct IGMP behavior on v3 query during v2-compatibility mode
Dmitry Torokhov (1):
Input: wacom - fix runtime PM related deadlock
Eric Dumazet (1):
caif: fix two caif_connect() bugs
Felix Fietkau (1):
ath9k_hw: fix regression in ANI listen time calculation
Henrik Rydberg (1):
Input: uinput - setup MT usage during device creation
Jeff Kirsher (4):
ixgbevf.txt: Update ixgbevf documentation
e1000.txt: Update e1000 documentation
e1000e.txt: Add e1000e documentation
MAINTAINERS: update Intel LAN Ethernet info
Johannes Berg (1):
mac80211: delete AddBA response timer
Kenneth Waters (1):
Input: joydev - fix JSIOCSAXMAP ioctl
Maciej Żenczykowski (1):
net: Fix IPv6 PMTU disc. w/ asymmetric routes
Martin K. Petersen (1):
[SCSI] Fix VPD inquiry page wrapper
Nagendra Tomar (1):
net: Fix the condition passed to sk_wait_event()
Neil Horman (1):
bonding: fix WARN_ON when writing to bond_master sysfs file
Santosh Shilimkar (1):
ARM: 6419/1: mmu: Fix MT_MEMORY and MT_MEMORY_NONCACHED pte flags
Sergei Shtylyov (2):
hpt366: add debounce delay to cable_detect() method
hpt366: fix clock turnaround
Stanislaw Gruszka (1):
skge: add quirk to limit DMA
Will Deacon (2):
ARM: 6416/1: errata: faulty hazard checking in the Store Buffer may lead to data corruption
ARM: 6412/1: kprobes-decode: add support for MOVW instruction
--
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
* [patch] IPVS: ip_vs_dbg_callid() is only needed for debugging
From: Simon Horman @ 2010-10-07 1:23 UTC (permalink / raw)
To: lvs-devel, netdev, netfilter-devel
Cc: Wensong Zhang, Julian Anastasov, Patrick McHardy
ip_vs_dbg_callid() and IP_VS_DEBUG_CALLID() are only needed
it CONFIG_IP_VS_DEBUG is defined.
This resolves the following build warning when CONFIG_IP_VS_DEBUG is
not defined.
net/netfilter/ipvs/ip_vs_pe_sip.c:11: warning: 'ip_vs_dbg_callid' defined but not used
Reported-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Simon Horman <horms@verge.net.au>
Index: nf-next-2.6/net/netfilter/ipvs/ip_vs_pe_sip.c
===================================================================
--- nf-next-2.6.orig/net/netfilter/ipvs/ip_vs_pe_sip.c 2010-10-07 10:17:54.000000000 +0900
+++ nf-next-2.6/net/netfilter/ipvs/ip_vs_pe_sip.c 2010-10-07 10:18:33.000000000 +0900
@@ -8,6 +8,7 @@
#include <net/netfilter/nf_conntrack.h>
#include <linux/netfilter/nf_conntrack_sip.h>
+#ifdef CONFIG_IP_VS_DEBUG
static const char *ip_vs_dbg_callid(char *buf, size_t buf_len,
const char *callid, size_t callid_len,
int *idx)
@@ -22,6 +23,7 @@ static const char *ip_vs_dbg_callid(char
#define IP_VS_DEBUG_CALLID(callid, len) \
ip_vs_dbg_callid(ip_vs_dbg_buf, sizeof(ip_vs_dbg_buf), \
callid, len, &ip_vs_dbg_idx)
+#endif
static int get_callid(const char *dptr, unsigned int dataoff,
unsigned int datalen,
^ permalink raw reply
* linux-next: manual merge of the net tree with the net-current tree
From: Stephen Rothwell @ 2010-10-07 1:31 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Eric Dumazet, David Miller, netdev,
Joe Perches
Hi all,
Today's linux-next merge of the net tree got a conflict in
net/caif/caif_socket.c between commit
79315068f4560f3f7bd6e9790190dcb43059770c ("caif: fix two caif_connect()
bugs") from the net-current tree and commit
b31fa5bad576cd8180a5ad70c648333b44320d44 ("net/caif: Use pr_fmt") from
the net tree.
I fixed it up (see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc net/caif/caif_socket.c
index 4bf28f2,abcba53..0000000
--- a/net/caif/caif_socket.c
+++ b/net/caif/caif_socket.c
@@@ -897,23 -888,14 +889,22 @@@ static int caif_connect(struct socket *
cf_sk->sk.sk_state = CAIF_DISCONNECTED;
goto out;
}
- dev = dev_get_by_index(sock_net(sk), ifindex);
+
+ err = -ENODEV;
+ rcu_read_lock();
+ dev = dev_get_by_index_rcu(sock_net(sk), ifindex);
+ if (!dev) {
+ rcu_read_unlock();
+ goto out;
+ }
cf_sk->headroom = LL_RESERVED_SPACE_EXTRA(dev, headroom);
+ mtu = dev->mtu;
+ rcu_read_unlock();
+
cf_sk->tailroom = tailroom;
- cf_sk->maxframe = dev->mtu - (headroom + tailroom);
- dev_put(dev);
+ cf_sk->maxframe = mtu - (headroom + tailroom);
if (cf_sk->maxframe < 1) {
- pr_warning("CAIF: %s(): CAIF Interface MTU too small (%u)\n",
- __func__, mtu);
- pr_warn("CAIF Interface MTU too small (%d)\n", dev->mtu);
- err = -ENODEV;
++ pr_warn("CAIF Interface MTU too small (%d)\n", mtu);
goto out;
}
^ permalink raw reply
* Re: [PATCH] Documentation/networking/ixgbevf.txt: Change file permissions to 644
From: David Miller @ 2010-10-07 1:42 UTC (permalink / raw)
To: joe; +Cc: jeffrey.t.kirsher, netdev, rdunlap, gregory.v.rose
In-Reply-To: <20101006.173353.179919967.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Wed, 06 Oct 2010 17:33:53 -0700 (PDT)
> From: Joe Perches <joe@perches.com>
> Date: Wed, 06 Oct 2010 15:09:50 -0700
>
>> Signed-off-by: Joe Perches <joe@perches.com>
>> ---
>> diff --git a/Documentation/networking/ixgbevf.txt b/Documentation/networking/ixgbevf.txt
>> old mode 100755
>> new mode 100644
>
> Applied, thanks.
Actually, only net-next-2.6 needs this and this permission issue will
end up getting fixed transparently when I merge net-2.6 into
net-next-2.6
Which I need to do right now to resolve a conflict anyways.
So I won't actually be applying this patch.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 2/3] bonding: add Speed/Duplex information to /proc/net/bonding/bond
From: David Miller @ 2010-10-07 1:44 UTC (permalink / raw)
To: ole; +Cc: fubar, bonding-devel, netdev
In-Reply-To: <4CACEADA.70009@ans.pl>
From: Krzysztof Olędzki <ole@ans.pl>
Date: Wed, 06 Oct 2010 23:32:10 +0200
> Please note however that this procfs file was recently changed ("Slave
> queue ID" was added) so if this is indeed a problem than we would
> already heard about this.
You make a good argument, therefore I have decided to apply
your patch.
Thanks.
^ permalink raw reply
* Re: [PATCH] Documentation/networking/ixgbevf.txt: Change file permissions to 644
From: Joe Perches @ 2010-10-07 1:52 UTC (permalink / raw)
To: David Miller; +Cc: jeffrey.t.kirsher, netdev, rdunlap, gregory.v.rose
In-Reply-To: <20101006.184215.35062616.davem@davemloft.net>
On Wed, 2010-10-06 at 18:42 -0700, David Miller wrote:
> So I won't actually be applying this patch.
No worries, happy it's getting resolved.
I sent a patch to checkpatch so these could be avoided
in the future. Maybe Andy W has a better idea.
^ permalink raw reply
* Re: [PATCH] Documentation/networking/ixgbevf.txt: Change file permissions to 644
From: David Miller @ 2010-10-07 1:59 UTC (permalink / raw)
To: joe; +Cc: jeffrey.t.kirsher, netdev, rdunlap, gregory.v.rose
In-Reply-To: <1286416346.3292.2.camel@Joe-Laptop>
From: Joe Perches <joe@perches.com>
Date: Wed, 06 Oct 2010 18:52:26 -0700
> On Wed, 2010-10-06 at 18:42 -0700, David Miller wrote:
>> So I won't actually be applying this patch.
>
> No worries, happy it's getting resolved.
>
> I sent a patch to checkpatch so these could be avoided
> in the future. Maybe Andy W has a better idea.
GIT would probably be a better place to detect this, even if
it's not on by default I would enable it in my own personal
.gitconfig
^ permalink raw reply
* Re: linux-next: manual merge of the net tree with the net-current tree
From: David Miller @ 2010-10-07 2:35 UTC (permalink / raw)
To: sfr; +Cc: netdev, linux-next, linux-kernel, eric.dumazet, joe
In-Reply-To: <20101007123104.bf7a9808.sfr@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 7 Oct 2010 12:31:04 +1100
> Hi all,
>
> Today's linux-next merge of the net tree got a conflict in
> net/caif/caif_socket.c between commit
> 79315068f4560f3f7bd6e9790190dcb43059770c ("caif: fix two caif_connect()
> bugs") from the net-current tree and commit
> b31fa5bad576cd8180a5ad70c648333b44320d44 ("net/caif: Use pr_fmt") from
> the net tree.
>
> I fixed it up (see below) and can carry the fix as necessary.
Thanks Stephen, I'm merging net-2.6 into net-next-2.6 right now
to resolve this.
Thanks!
^ permalink raw reply
* [PATCH] TCP: Fix setting of snd_ssthresh in tcp_mtu_probe_success
From: John Heffner @ 2010-10-07 3:41 UTC (permalink / raw)
To: davem; +Cc: netdev
This looks like a simple typo that has gone unnoticed for some time. The
impact is relatively low but it's clearly wrong.
Signed-off-by: John Heffner <johnwheffner@gmail.com>
---
net/ipv4/tcp_input.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index f6fdd72..e4fbdae 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -2874,7 +2874,7 @@ static void tcp_mtup_probe_success(struct sock *sk)
icsk->icsk_mtup.probe_size;
tp->snd_cwnd_cnt = 0;
tp->snd_cwnd_stamp = tcp_time_stamp;
- tp->rcv_ssthresh = tcp_current_ssthresh(sk);
+ tp->snd_ssthresh = tcp_current_ssthresh(sk);
icsk->icsk_mtup.search_low = icsk->icsk_mtup.probe_size;
icsk->icsk_mtup.probe_size = 0;
--
1.7.0.4
^ permalink raw reply related
* [RFC] net: allow FEC driver to not have attached PHY
From: Greg Ungerer @ 2010-10-07 3:50 UTC (permalink / raw)
To: netdev; +Cc: gerg
Hi All,
I have a board with a ColdFire SoC on it with the built-in FEC
ethernet module. On this hardware the FEC eth output is directly
attached to a RTL8305 4-port 10/100 switch. There is no conventional
PHY, the FEC output is direct into the uplink port of the switch
chip.
This setup doesn't work after the FEC code was switch to using
phylib. The driver used to have code to bypass phy detection/setup
for this particular board. The phylib probe finds nothing, and of
course sets a no-link condition.
So, what is the cleanest way to support this?
The attached patch adds a config option to do this sort of generically
for the FEC driver. But I am wondering if there isn't a better way?
Regards
Greg
---
[RFC] net: allow FEC driver to not have attached PHY
At least one board using the FEC driver does not have a conventional
PHY attached to it, it is directly connected to a somewhat simple
ethernet switch (the board is the SnapGear/LITE, and the attached
4-port ethernet switch is a RealTek RTL8305). This switch does not
present the usual register interface of a PHY, it presents nothing.
So a PHY scan will find nothing.
After the FEC driver was changed to use phylib for supporting phys
it no longer works on this particular board/switch setup.
Add a config option to allow configuring the FEC driver to not expect
a PHY to be present.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
---
drivers/net/Kconfig | 9 +++++++++
drivers/net/fec.c | 7 +++++++
2 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 93494e2..ee44728 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -1934,6 +1934,15 @@ config FEC2
Say Y here if you want to use the second built-in 10/100 Fast
ethernet controller on some Motorola ColdFire processors.
+config FEC_NOPHY
+ bool "FEC has no attached PHY"
+ depends on FEC
+ help
+ Some boards using the FEC driver may not have a PHY directly
+ attached to it. Typically in this scenario the FEC output is
+ directly connected to the input of an ethernet switch or hub.
+ Say Y here if your hardware is like this.
+
config FEC_MPC52xx
tristate "MPC52xx FEC driver"
depends on PPC_MPC52xx && PPC_BESTCOMM
diff --git a/drivers/net/fec.c b/drivers/net/fec.c
index 768b840..3637f89 100644
--- a/drivers/net/fec.c
+++ b/drivers/net/fec.c
@@ -910,6 +910,11 @@ fec_enet_open(struct net_device *dev)
if (ret)
return ret;
+#ifdef CONFIG_FEC_NOPHY
+ /* No PHY connected, assume link is always up */
+ fep->link = 1;
+ fec_restart(dev, 0);
+#else
/* Probe and connect to PHY when open the interface */
ret = fec_enet_mii_probe(dev);
if (ret) {
@@ -917,6 +922,8 @@ fec_enet_open(struct net_device *dev)
return ret;
}
phy_start(fep->phy_dev);
+#endif
+
netif_start_queue(dev);
fep->opened = 1;
return 0;
^ permalink raw reply related
* Re: [PATCH] TCP: Fix setting of snd_ssthresh in tcp_mtu_probe_success
From: David Miller @ 2010-10-07 4:18 UTC (permalink / raw)
To: johnwheffner; +Cc: netdev
In-Reply-To: <1286422913-30034-1-git-send-email-johnwheffner@gmail.com>
From: John Heffner <johnwheffner@gmail.com>
Date: Wed, 6 Oct 2010 23:41:53 -0400
> This looks like a simple typo that has gone unnoticed for some time. The
> impact is relatively low but it's clearly wrong.
>
> Signed-off-by: John Heffner <johnwheffner@gmail.com>
Amazing how long something like this can survive :-)
Applied, thanks John.
^ permalink raw reply
* Re: Segmentation fault when using ping6
From: Baruch Siach @ 2010-10-07 5:32 UTC (permalink / raw)
To: Rogerio Pimentel; +Cc: netdev, linux-arm-kernel
In-Reply-To: <4CACDBB1.9050305@freescale.com>
Hi Rogerio,
On Wed, Oct 06, 2010 at 05:27:29PM -0300, Rogerio Pimentel wrote:
> I'm having a "segmentation fault" problem when using ping6.
>
> When testing on ARM9 platforms (i.MX25 and i.MX27), it returns the error:
>
> root@freescale ~$ ping6 ::1
> PING ::1 (::1): 56 data bytes
> Segmentation fault
>
> When testing on ARM11 and ARM Cortex A8 platforms (i.MX31 and
> i.MX51), it works:
>
> root@freescale ~$ ping6 ::1
> PING ::1 (::1): 56 data bytes
> 64 bytes from ::1: seq=0 ttl=64 time=0.331 ms
> 64 bytes from ::1: seq=1 ttl=64 time=0.214 ms
> 64 bytes from ::1: seq=2 ttl=64 time=0.176 ms
> 64 bytes from ::1: seq=3 ttl=64 time=0.155 ms
>
> On all cases, I'm using Linux Kernel 2.6.35 (from Mainline) and
> Busybox 1.15.0
>
> Does anybody have any idea?
This seems to be a Busybox related issue. I'd suggests you to try the latest
version of Busybox (1.17.2), and if the problem persists, ask at the Busybox
mailing list. Don't forget to add strace output to your message.
baruch
--
~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply
* Re: [PATCH -next] sundance: Drop legacy _COMPAT_WITH_OLD_KERNEL includes
From: David Miller @ 2010-10-07 6:11 UTC (permalink / raw)
To: dkirjanov; +Cc: netdev
In-Reply-To: <20101006135956.GA5556@hera.kernel.org>
From: Denis Kirjanov <dkirjanov@kernel.org>
Date: Wed, 6 Oct 2010 13:59:56 +0000
> Drop legacy includes since 2.4.x
>
> Signed-off-by: Denis Kirjanov <dkirjanov@kernel.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] dccp:
From: David Miller @ 2010-10-07 6:12 UTC (permalink / raw)
To: shemminger; +Cc: acme, dccp, netdev
In-Reply-To: <20101005232409.61cb9412@s6510>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Tue, 5 Oct 2010 23:24:09 +0900
> Remove dead code and make some functions static.
> Compile tested only.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Looks good, applied, thanks.
^ permalink raw reply
* Re: [net-next-2.6 PATCH] net: netif_set_real_num_rx_queues may cap num_rx_queues at init time
From: Eric Dumazet @ 2010-10-07 6:16 UTC (permalink / raw)
To: John Fastabend; +Cc: bhutchings, netdev, therbert
In-Reply-To: <20101004220042.3471.92774.stgit@jf-dev1-dcblab>
Le lundi 04 octobre 2010 à 15:00 -0700, John Fastabend a écrit :
> The logic for netif_set_real_num_rx_queues is the following,
>
...
> Because netif_set_real_num_rx_queues sets num_rx_queues if the
> reg state is not NETREG_REGISTERED we end up with the incorrect
> max number of rx queues. This patch proposes to remove the else
> clause above so this does not occur. Also just reading the
> function set_real_num it seems a bit unexpected that num_rx_queues
> gets set.
>
> CC: Ben Hutchings <bhutchings@solarflare.com>
>
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
> ---
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
^ permalink raw reply
* Re: [patch] eicon: make buffer larger
From: David Miller @ 2010-10-07 6:30 UTC (permalink / raw)
To: error27; +Cc: mac, isdn, netdev, linux-kernel, kernel-janitors
In-Reply-To: <20101004192459.GE5692@bicker>
From: Dan Carpenter <error27@gmail.com>
Date: Mon, 4 Oct 2010 21:24:59 +0200
> In diva_mnt_add_xdi_adapter() we do this:
> strcpy (clients[id].drvName, tmp);
> strcpy (clients[id].Dbg.drvName, tmp);
>
> The "clients[id].drvName" is a 128 character buffer and
> "clients[id].Dbg.drvName" was originally a 16 character buffer but I've
> changed it to 128 as well. We don't actually use 128 characters but we
> do use more than 16.
>
> I've also changed the size of "tmp" to 128 characters instead of 256.
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH] net: netif_set_real_num_rx_queues may cap num_rx_queues at init time
From: David Miller @ 2010-10-07 6:35 UTC (permalink / raw)
To: eric.dumazet; +Cc: john.r.fastabend, bhutchings, netdev, therbert
In-Reply-To: <1286432199.9417.47.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 07 Oct 2010 08:16:39 +0200
> Le lundi 04 octobre 2010 à 15:00 -0700, John Fastabend a écrit :
>> The logic for netif_set_real_num_rx_queues is the following,
>>
>
>
> ...
>
>> Because netif_set_real_num_rx_queues sets num_rx_queues if the
>> reg state is not NETREG_REGISTERED we end up with the incorrect
>> max number of rx queues. This patch proposes to remove the else
>> clause above so this does not occur. Also just reading the
>> function set_real_num it seems a bit unexpected that num_rx_queues
>> gets set.
>>
>> CC: Ben Hutchings <bhutchings@solarflare.com>
>>
>> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
>> ---
>
> Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks everyone.
^ permalink raw reply
* Re: [net-next PATCH] igb: update adapter stats when reading /proc/net/dev.
From: David Miller @ 2010-10-07 6:36 UTC (permalink / raw)
To: hawk; +Cc: netdev, jeffrey.t.kirsher
In-Reply-To: <20101005141833.20929.10943.stgit@localhost>
From: Jesper Dangaard Brouer <hawk@comx.dk>
Date: Tue, 05 Oct 2010 16:18:33 +0200
> Network driver igb: Improve the accuracy of stats in /proc/net/dev, by
> updating the adapter stats when reading /proc/net/dev. Currently the
> stats are updated by the watchdog timer every 2 sec, or when getting
> stats via ethtool -S.
>
> A number of userspace apps read these /proc/net/dev stats every second,
> e.g. ifstat, which then gives a perceived very bursty traffic pattern,
> which is actually false.
>
> Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk>
I assume that the Intel folks will take care of integrating this
now that the locking is fixed.
Thanks.
^ 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