* Re: [RFC v2 1/7] hashtable: introduce a small and naive hashtable
From: Tejun Heo @ 2012-08-04 0:05 UTC (permalink / raw)
To: Linus Torvalds
Cc: Sasha Levin, akpm, linux-kernel, linux-mm, paul.gortmaker, davem,
rostedt, mingo, ebiederm, aarcange, ericvh, netdev
In-Reply-To: <CA+55aFwTa_kYgmFwoWa6hwAAM6=2xTgQQf-vEx_gCzpEMnxodQ@mail.gmail.com>
Hello,
On Fri, Aug 03, 2012 at 04:47:47PM -0700, Linus Torvalds wrote:
> On Fri, Aug 3, 2012 at 3:36 PM, Tejun Heo <tj@kernel.org> wrote:
> >
> > I suppose you mean unsized. I remember this working. Maybe I'm
> > confusing it with zero-sized array. Hmm... gcc doesn't complain about
> > the following. --std=c99 seems happy too.
>
> Ok, I'm surprised, but maybe it's supposed to work if you do it inside
> another struct like that, exactly so that you can preallocate things..
Yeah, I think the rule is var array should be the last member of any
given struct definition. Once a struct is defined, its alignment and
size are fixed and it behaves like any other struct.
> Or maybe it's just a gcc bug. I do think this all is way hackier than
> Sasha's original simple code that didn't need these kinds of games,
> and didn't need a size member at all.
>
> I really think all the extra complexity and overhead is just *bad*.
> The first simple version was much nicer and likely generated better
> code too.
The size member could have performance impact in extreme cases. If
we're looking for something simple & fast, maybe just pass in @size as
argument and be done with it?
Thanks.
--
tejun
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [RFC v2 1/7] hashtable: introduce a small and naive hashtable
From: Linus Torvalds @ 2012-08-04 0:05 UTC (permalink / raw)
To: Sasha Levin
Cc: Tejun Heo, akpm, linux-kernel, linux-mm, paul.gortmaker, davem,
rostedt, mingo, ebiederm, aarcange, ericvh, netdev
In-Reply-To: <501C66C2.2020706@gmail.com>
On Fri, Aug 3, 2012 at 5:03 PM, Sasha Levin <levinsasha928@gmail.com> wrote:
>
> The problem with that code was that it doesn't work with dynamically allocated hashtables, or hashtables that grow/shrink.
Sure. But once you have that kind of complexity, why would you care
about the trivial cases?
Linus
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH V2 09/12] net/eipoib: Add main driver functionality
From: David Miller @ 2012-08-04 0:05 UTC (permalink / raw)
To: ali; +Cc: ebiederm, ogerlitz, roland, netdev, sean.hefty, erezsh
In-Reply-To: <501C669B.2030303@mellanox.com>
From: Ali Ayoub <ali@mellanox.com>
Date: Fri, 03 Aug 2012 17:02:35 -0700
> On 8/3/2012 3:39 PM, Ali Ayoub wrote:
>> On 8/3/2012 2:33 PM, David Miller wrote:
>>> From: Ali Ayoub <ali@mellanox.com>
>>> Date: Fri, 03 Aug 2012 13:31:35 -0700
>>>
>>>> With eIPoIB architecture, the VM sees standard Ethernet emulator,
>>>> allowing the administrator to enslave eIPoIB PIF to the vSwitch/vBridge
>>>> as if it was standard Ethernet. Other approaches that exposes IB QP to
>>>> the VM (with w/o bypassing the kernel) won't be possible with the
>>>> current emulators and management tools.
>>>
>>> So then fix the emulators and management tools to handle IB instead
>>> of adding this bogus new protocol?
>>>
>>> This new protocol seems to exist only because you don't want to have
>>> to enhance the emulators and tools, and I'm sorry that isn't a valid
>>> reason to do something like this.
>>
>> This driver exists to allow the user to have an Ethernet interface on
>> top of a high-speed InfiniBand (IB) interconnect.
>> Users would like to use sockets API from the VM without re-writing their
>> applications on top of IB verbs, this driver meant to allow such a user
>> to do so.
>>
>> Exposing IB emulators and having IB support in the management tools for
>> the VM/Hypervisor won't address the usecases that this driver meant for.
>>
>> With this driver, existing VMs, and their existing IP applications, can
>> run as-is on InfiniBand network.
>
> This driver exists to allow the user to have an Ethernet interface on
> top of a high-speed InfiniBand (IB) interconnect.
> Users would like to use sockets API from the VM without re-writing their
> applications on top of IB verbs, this driver meant to allow such a user
> to do so.
>
> Exposing IB emulators and having IB support in the management tools for
> the VM/Hypervisor won't address the usecases that this driver meant for.
>
> With this driver, existing VMs, and their existing IP applications, can
> run as-is on InfiniBand network.
Just saying the same thing twice doesn't make your argument stronger.
^ permalink raw reply
* Re: [RFC v2 1/7] hashtable: introduce a small and naive hashtable
From: Sasha Levin @ 2012-08-04 0:33 UTC (permalink / raw)
To: Linus Torvalds
Cc: Tejun Heo, akpm, linux-kernel, linux-mm, paul.gortmaker, davem,
rostedt, mingo, ebiederm, aarcange, ericvh, netdev
In-Reply-To: <CA+55aFziVRRBoTnm2zASGR39W1AB+0=4Sa7qO8e6_hN06ZY8wg@mail.gmail.com>
On 08/04/2012 02:05 AM, Linus Torvalds wrote:
> On Fri, Aug 3, 2012 at 5:03 PM, Sasha Levin <levinsasha928@gmail.com> wrote:
>>
>> The problem with that code was that it doesn't work with dynamically allocated hashtables, or hashtables that grow/shrink.
>
> Sure. But once you have that kind of complexity, why would you care
> about the trivial cases?
Because there are far more trivial cases than complex ones - I've counted 50+ of these "trivial" cases.
None of them need the complexity we're trying to deal with at the moment.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [PATCH] cris: fix eth_v10.c build error
From: Randy Dunlap @ 2012-08-04 0:38 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-kernel, Mikael Starvik, Jesper Nilsson, linux-cris-kernel,
netdev, David Miller
In-Reply-To: <1344002771-21072-1-git-send-email-geert@linux-m68k.org>
From: Randy Dunlap <rdunlap@xenotime.net>
Fix build error on cris (not tested, no toolchain here):
drivers/net/cris/eth_v10.c: error: too many arguments to function 'e100rxtx_interrupt'
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Cc: Mikael Starvik <starvik@axis.com>
Cc: Jesper Nilsson <jesper.nilsson@axis.com>
Cc: linux-cris-kernel@axis.com
---
drivers/net/cris/eth_v10.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- lnx-36-rc1.orig/drivers/net/cris/eth_v10.c
+++ lnx-36-rc1/drivers/net/cris/eth_v10.c
@@ -1712,7 +1712,7 @@ e100_set_network_leds(int active)
static void
e100_netpoll(struct net_device* netdev)
{
- e100rxtx_interrupt(NETWORK_DMA_TX_IRQ_NBR, netdev, NULL);
+ e100rxtx_interrupt(NETWORK_DMA_TX_IRQ_NBR, netdev);
}
#endif
^ permalink raw reply
* Re: [PATCH V2 09/12] net/eipoib: Add main driver functionality
From: Eric W. Biederman @ 2012-08-04 1:34 UTC (permalink / raw)
To: Ali Ayoub, David Miller; +Cc: ogerlitz, roland, netdev, sean.hefty, erezsh
In-Reply-To: <501C669B.2030303@mellanox.com>
Ali Ayoub <ali@mellanox.com> wrote:
>
>With this driver, existing VMs, and their existing IP applications, can
>run as-is on InfiniBand network.
Actually it doesn't work like that.
If my application really needs ethernet it will not work with your driver. I can not run decnet or appletalk or ATAoE or PPPoE or LACP or use VLANs or any of a thousand other things that require real live ethernet to function.
Most VMs will talk to linux with a tap interface, and the output of a tap interface can be routed just fine, and that works with existing tools, and existing already deployed kernels.
Alternatively if you are silly you can implement a tap interface on top of IPoIB and have the same interface you do now, and it works with existing already deployed kernels.
So eIPoIB does not make sense from a time to market perspective.
Similarly eIPoIB does not make sense from a performance standpoint because the best performance requires the applications and hypervisors are infiniband and teaching the apps to cope.
eIPoIB also has considerable maintenance overhead as it is complex code doing some crazy things.
Now personally NAPT44 just about made the internet unusable for peer to peer appications. NAT66 aka network prefix translation introduces much less breakage but it still requires someone to run STUN on IPv6 to keep applications working, ick. NATEIB aka eIPoIB just looks complex and already breaks most of ethernet and history says that kind of breakage actually matters a lot. I think everyone who suggests any kind of NAT is a good idea should have to implement RFC 5245 Interacive Connectivity Establishment. It takes 2 100+ page rfcs to come up with a way that allows applications to with the address munging over the open internet. That way takes 3000+ lines of code in each application. That is the kind of complexity you are asking people up stream of you to deal with your NATTing o
f ethernet to infiniband. So I totally think eIPoIB stinks, and that it does not at all let existing applications work without modification.
Eric
^ permalink raw reply
* Re: [PATCH] cdc-ncm: tag Ericsson WWAN devices (eg F5521gw) with FLAG_WWAN
From: David Miller @ 2012-08-04 3:32 UTC (permalink / raw)
To: meiser-rJBqYz9TEJZKTQ5g00o1eQ
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <501A72DC.7070306-rJBqYz9TEJZKTQ5g00o1eQ@public.gmane.org>
From: Peter Meiser <meiser-rJBqYz9TEJZKTQ5g00o1eQ@public.gmane.org>
Date: Thu, 02 Aug 2012 14:30:20 +0200
> looking at http://sourceforge.net/apps/mediawiki/mbm/index.php?title=Main_Page#Supported_devices, there are branded Ericsson devices from Dell and Toshiba.
>
> The to-be-added vendor IDs are 0x413c for Dell and 0x0930 for Toshiba.
>
> Please find attached a patch to add these vendor IDs.
>
> Signed-off-by: Peter Meiser <meiser-rJBqYz9TEJZKTQ5g00o1eQ@public.gmane.org>
Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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
* Re: [PATCH] cris: fix eth_v10.c build error
From: David Miller @ 2012-08-04 3:33 UTC (permalink / raw)
To: rdunlap
Cc: geert, linux-kernel, starvik, jesper.nilsson, linux-cris-kernel,
netdev
In-Reply-To: <501C6EEF.3030100@xenotime.net>
From: Randy Dunlap <rdunlap@xenotime.net>
Date: Fri, 03 Aug 2012 17:38:07 -0700
> From: Randy Dunlap <rdunlap@xenotime.net>
>
> Fix build error on cris (not tested, no toolchain here):
>
> drivers/net/cris/eth_v10.c: error: too many arguments to function 'e100rxtx_interrupt'
>
> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Applied, thanks Randy.
^ permalink raw reply
* Re: [PATCH] firmware: Remove obsolete Chelsio cxgb3 firmware
From: David Miller @ 2012-08-04 3:41 UTC (permalink / raw)
To: tim.gardner
Cc: linux-kernel, paul.gortmaker, ben, JBottomley, dan.j.williams,
divy, netdev
In-Reply-To: <501A728A.2070905@canonical.com>
From: Tim Gardner <tim.gardner@canonical.com>
Date: Thu, 02 Aug 2012 06:28:58 -0600
> git://kernel.ubuntu.com/rtg/net-next.git master
>
> for you to fetch changes up to 044b722f36a17bc5f7f472cc3246cb15a430bb0e:
>
> firmware: Remove obsolete Chelsio cxgb3 firmware (2012-08-02 06:23:25
> -0600)
Pulled, thanks.
^ permalink raw reply
* Re: [patch net-next 0/4] add support for queue override by setting queue_id for port
From: David Miller @ 2012-08-04 3:41 UTC (permalink / raw)
To: jiri; +Cc: netdev, edumazet
In-Reply-To: <1343406535-22388-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Fri, 27 Jul 2012 18:28:51 +0200
> Jiri Pirko (4):
> netlink: add signed types
> team: add signed 32-bit team option type
> team: add per port priority option
> team: add support for queue override by setting queue_id for port
All applied, thanks.
^ permalink raw reply
* Re: [PATCH v2] ppp: add 64 bit stats
From: David Miller @ 2012-08-04 3:41 UTC (permalink / raw)
To: eric.dumazet; +Cc: kgroeneveld, netdev
In-Reply-To: <1343461141.2626.13122.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 28 Jul 2012 09:39:01 +0200
> On Fri, 2012-07-27 at 23:38 -0400, Kevin Groeneveld wrote:
>> Add 64 bit stats to ppp driver. The 64 bit stats include tx_bytes,
>> rx_bytes, tx_packets and rx_packets. Other stats are still 32 bit.
>> The 64 bit stats can be retrieved via the ndo_get_stats operation. The
>> SIOCGPPPSTATS ioctl is still 32 bit stats only.
>>
>> Signed-off-by: Kevin Groeneveld <kgroeneveld@gmail.com>
>> ---
>> v2: - do not use percpu variables for stats
>> - use ppp_recv_lock/ppp_xmit_lock when reading 64 bit stats
>>
>
> Seems fine to me this time ;)
>
> Acked-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH 0/2] Add device tree support and resolving SOC dependency to cpsw driver
From: David Miller @ 2012-08-04 3:42 UTC (permalink / raw)
To: mugunthanvnm; +Cc: netdev
In-Reply-To: <1343679434-2369-1-git-send-email-mugunthanvnm@ti.com>
From: Mugunthan V N <mugunthanvnm@ti.com>
Date: Tue, 31 Jul 2012 01:47:12 +0530
> This patch set adds SOC dependency for CPSW dependent modules and adds support
> for device tree for CPSW driver
>
> Mugunthan V N (2):
> drivers: net: ethernet: cpsw: Add SOC dependency support for cpsw
> dependent modules
> drivers: net: ethernet: cpsw: Add device tree support to CPSW
Both applied to net-next, thanks.
^ permalink raw reply
* (unknown),
From: Yeung Lap Ming @ 2012-08-04 3:41 UTC (permalink / raw)
I have a deal. Reply for details.
^ permalink raw reply
* Re: TCP stalls with 802.3ad + bridge + kvm guest
From: Jesse Brandeburg @ 2012-08-04 5:04 UTC (permalink / raw)
To: Peter Samuelson; +Cc: Jay Vosburgh, netdev, jgoerzen
In-Reply-To: <20120801144104.GN17572@p12n.org>
On Wed, Aug 1, 2012 at 7:41 AM, Peter Samuelson <psamuelson@efolder.net> wrote:
>
> [Peter Samuelson]
>> > ixgbe [10 Gbit port] -- bonding [802.3ad] -- bridge -- KVM guest
>> >
>> >It all works, except that with some flows in the KVM guest - I
>> >can reproduce using smbclient - transfers keep stalling, such that I'm
>> >averaging well under 1 MB/s. Should be more like 100 MB/s.
>> >
>> >Oddly, this only occurs when both the 802.3ad and KVM are used:
is it because offloads are enabled? I had to disable several of them
to get my virtual machines to work on both igb and ixgbe interfaces, I
haven't gone any further to isolate why.
try
# ethtool -K ethx tso off gso off lro off
^ permalink raw reply
* [PATCH net-next] net: skb_share_check() should use consume_skb()
From: Eric Dumazet @ 2012-08-04 6:54 UTC (permalink / raw)
To: David Miller; +Cc: netdev
From: Eric Dumazet <edumazet@google.com>
In order to avoid false drop_monitor indications, we should
call consume_skb() if skb_clone() was successful.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
include/linux/skbuff.h | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 7632c87..b33a3a1 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -846,13 +846,16 @@ static inline int skb_shared(const struct sk_buff *skb)
*
* NULL is returned on a memory allocation failure.
*/
-static inline struct sk_buff *skb_share_check(struct sk_buff *skb,
- gfp_t pri)
+static inline struct sk_buff *skb_share_check(struct sk_buff *skb, gfp_t pri)
{
might_sleep_if(pri & __GFP_WAIT);
if (skb_shared(skb)) {
struct sk_buff *nskb = skb_clone(skb, pri);
- kfree_skb(skb);
+
+ if (likely(nskb))
+ consume_skb(skb);
+ else
+ kfree_skb(skb);
skb = nskb;
}
return skb;
^ permalink raw reply related
* [PATCH net-next] ipv4: change inet_addr_hash()
From: Eric Dumazet @ 2012-08-04 7:06 UTC (permalink / raw)
To: David Miller; +Cc: netdev
From: Eric Dumazet <edumazet@google.com>
Use net_hash_mix(net) instead of hash_ptr(net, 8), and use
hash_32() instead of using a serie of XOR
Define IN4_ADDR_HSIZE_SHIFT for clarity
__ip_dev_find() can perform the net_eq() call only if ifa_local
matches the key, to avoid unneeded dereferences.
remove inline attributes
# size net/ipv4/devinet.o.before net/ipv4/devinet.o
text data bss dec hex filename
17471 2545 2048 22064 5630 net/ipv4/devinet.o.before
17335 2545 2048 21928 55a8 net/ipv4/devinet.o
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/ipv4/devinet.c | 39 ++++++++++++++++++---------------------
1 file changed, 18 insertions(+), 21 deletions(-)
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index 44bf82e..adf273f 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -94,25 +94,22 @@ static const struct nla_policy ifa_ipv4_policy[IFA_MAX+1] = {
[IFA_LABEL] = { .type = NLA_STRING, .len = IFNAMSIZ - 1 },
};
-/* inet_addr_hash's shifting is dependent upon this IN4_ADDR_HSIZE
- * value. So if you change this define, make appropriate changes to
- * inet_addr_hash as well.
- */
-#define IN4_ADDR_HSIZE 256
+#define IN4_ADDR_HSIZE_SHIFT 8
+#define IN4_ADDR_HSIZE (1U << IN4_ADDR_HSIZE_SHIFT)
+
static struct hlist_head inet_addr_lst[IN4_ADDR_HSIZE];
static DEFINE_SPINLOCK(inet_addr_hash_lock);
-static inline unsigned int inet_addr_hash(struct net *net, __be32 addr)
+static u32 inet_addr_hash(struct net *net, __be32 addr)
{
- u32 val = (__force u32) addr ^ hash_ptr(net, 8);
+ u32 val = (__force u32) addr ^ net_hash_mix(net);
- return ((val ^ (val >> 8) ^ (val >> 16) ^ (val >> 24)) &
- (IN4_ADDR_HSIZE - 1));
+ return hash_32(val, IN4_ADDR_HSIZE_SHIFT);
}
static void inet_hash_insert(struct net *net, struct in_ifaddr *ifa)
{
- unsigned int hash = inet_addr_hash(net, ifa->ifa_local);
+ u32 hash = inet_addr_hash(net, ifa->ifa_local);
spin_lock(&inet_addr_hash_lock);
hlist_add_head_rcu(&ifa->hash, &inet_addr_lst[hash]);
@@ -136,18 +133,18 @@ static void inet_hash_remove(struct in_ifaddr *ifa)
*/
struct net_device *__ip_dev_find(struct net *net, __be32 addr, bool devref)
{
- unsigned int hash = inet_addr_hash(net, addr);
+ u32 hash = inet_addr_hash(net, addr);
struct net_device *result = NULL;
struct in_ifaddr *ifa;
struct hlist_node *node;
rcu_read_lock();
hlist_for_each_entry_rcu(ifa, node, &inet_addr_lst[hash], hash) {
- struct net_device *dev = ifa->ifa_dev->dev;
-
- if (!net_eq(dev_net(dev), net))
- continue;
if (ifa->ifa_local == addr) {
+ struct net_device *dev = ifa->ifa_dev->dev;
+
+ if (!net_eq(dev_net(dev), net))
+ continue;
result = dev;
break;
}
@@ -182,10 +179,10 @@ static void inet_del_ifa(struct in_device *in_dev, struct in_ifaddr **ifap,
static void devinet_sysctl_register(struct in_device *idev);
static void devinet_sysctl_unregister(struct in_device *idev);
#else
-static inline void devinet_sysctl_register(struct in_device *idev)
+static void devinet_sysctl_register(struct in_device *idev)
{
}
-static inline void devinet_sysctl_unregister(struct in_device *idev)
+static void devinet_sysctl_unregister(struct in_device *idev)
{
}
#endif
@@ -205,7 +202,7 @@ static void inet_rcu_free_ifa(struct rcu_head *head)
kfree(ifa);
}
-static inline void inet_free_ifa(struct in_ifaddr *ifa)
+static void inet_free_ifa(struct in_ifaddr *ifa)
{
call_rcu(&ifa->rcu_head, inet_rcu_free_ifa);
}
@@ -659,7 +656,7 @@ static int inet_rtm_newaddr(struct sk_buff *skb, struct nlmsghdr *nlh, void *arg
* Determine a default network mask, based on the IP address.
*/
-static inline int inet_abc_len(__be32 addr)
+static int inet_abc_len(__be32 addr)
{
int rc = -1; /* Something else, probably a multicast. */
@@ -1124,7 +1121,7 @@ skip:
}
}
-static inline bool inetdev_valid_mtu(unsigned int mtu)
+static bool inetdev_valid_mtu(unsigned int mtu)
{
return mtu >= 68;
}
@@ -1239,7 +1236,7 @@ static struct notifier_block ip_netdev_notifier = {
.notifier_call = inetdev_event,
};
-static inline size_t inet_nlmsg_size(void)
+static size_t inet_nlmsg_size(void)
{
return NLMSG_ALIGN(sizeof(struct ifaddrmsg))
+ nla_total_size(4) /* IFA_ADDRESS */
^ permalink raw reply related
* Re: [PATCH 1/2] net: Allow to create links with given ifindex
From: Eric Dumazet @ 2012-08-04 7:10 UTC (permalink / raw)
To: David Miller; +Cc: ebiederm, xemul, netdev
In-Reply-To: <20120803.165611.1832423445730269834.davem@davemloft.net>
On Fri, 2012-08-03 at 16:56 -0700, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Fri, 03 Aug 2012 07:45:29 +0200
>
> > @@ -1587,13 +1587,11 @@ static int ip_route_input_slow(struct sk_buff *skb, __be32 daddr, __be32 saddr,
> > if (ipv4_is_zeronet(daddr))
> > goto martian_destination;
> >
> > - if (likely(!IN_DEV_ROUTE_LOCALNET(in_dev))) {
> > - if (ipv4_is_loopback(daddr))
> > - goto martian_destination;
> > + if (ipv4_is_loopback(daddr) && !IN_DEV_NET_ROUTE_LOCALNET(in_dev, net))
> > + goto martian_destination;
> >
> > - if (ipv4_is_loopback(saddr))
> > - goto martian_source;
> > - }
> > + if (ipv4_is_loopback(saddr) && !IN_DEV_NET_ROUTE_LOCALNET(in_dev, net))
> > + goto martian_source;
>
> Maybe clearer as:
>
> if ((ipv4_is_loopback(daddr) || ipv4_is_loopback(saddr)) &&
> !IN_DEV_NET_ROUTE_LOCALNET(in_dev, net))
> goto martian_source;
Clearer, but handling of a martian destination is different of the
martian source ;)
^ permalink raw reply
* [PATCH net-next] ipv4: Introduce IN_DEV_NET_ROUTE_LOCALNET
From: Eric Dumazet @ 2012-08-04 7:27 UTC (permalink / raw)
To: David Miller; +Cc: netdev
From: Eric Dumazet <edumazet@google.com>
performance profiles show a high cost in the IN_DEV_ROUTE_LOCALNET()
call done in ip_route_input_slow(), because of multiple dereferences,
even if cache lines are clean and available in cpu caches.
Since we already have the 'net' pointer, introduce
IN_DEV_NET_ROUTE_LOCALNET() macro avoiding two dereferences
(dev_net(in_dev->dev))
Also change the tests to use IN_DEV_NET_ROUTE_LOCALNET() only if saddr
or/and daddr are loopback addresse.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
include/linux/inetdevice.h | 11 +++++++++--
net/ipv4/route.c | 11 +++++++----
2 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/include/linux/inetdevice.h b/include/linux/inetdevice.h
index 67f9dda..d032780 100644
--- a/include/linux/inetdevice.h
+++ b/include/linux/inetdevice.h
@@ -104,9 +104,14 @@ static inline void ipv4_devconf_setall(struct in_device *in_dev)
#define IN_DEV_ANDCONF(in_dev, attr) \
(IPV4_DEVCONF_ALL(dev_net(in_dev->dev), attr) && \
IN_DEV_CONF_GET((in_dev), attr))
-#define IN_DEV_ORCONF(in_dev, attr) \
- (IPV4_DEVCONF_ALL(dev_net(in_dev->dev), attr) || \
+
+#define IN_DEV_NET_ORCONF(in_dev, net, attr) \
+ (IPV4_DEVCONF_ALL(net, attr) || \
IN_DEV_CONF_GET((in_dev), attr))
+
+#define IN_DEV_ORCONF(in_dev, attr) \
+ IN_DEV_NET_ORCONF(in_dev, dev_net(in_dev->dev), attr)
+
#define IN_DEV_MAXCONF(in_dev, attr) \
(max(IPV4_DEVCONF_ALL(dev_net(in_dev->dev), attr), \
IN_DEV_CONF_GET((in_dev), attr)))
@@ -133,6 +138,8 @@ static inline void ipv4_devconf_setall(struct in_device *in_dev)
IN_DEV_ORCONF((in_dev), \
PROMOTE_SECONDARIES)
#define IN_DEV_ROUTE_LOCALNET(in_dev) IN_DEV_ORCONF(in_dev, ROUTE_LOCALNET)
+#define IN_DEV_NET_ROUTE_LOCALNET(in_dev, net) \
+ IN_DEV_NET_ORCONF(in_dev, net, ROUTE_LOCALNET)
#define IN_DEV_RX_REDIRECTS(in_dev) \
((IN_DEV_FORWARD(in_dev) && \
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index e4ba974..21ad369 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1587,11 +1587,14 @@ static int ip_route_input_slow(struct sk_buff *skb, __be32 daddr, __be32 saddr,
if (ipv4_is_zeronet(daddr))
goto martian_destination;
- if (likely(!IN_DEV_ROUTE_LOCALNET(in_dev))) {
- if (ipv4_is_loopback(daddr))
+ /* Following code try to avoid calling IN_DEV_NET_ROUTE_LOCALNET(),
+ * and call it once if daddr or/and saddr are loopback addresses
+ */
+ if (ipv4_is_loopback(daddr)) {
+ if (!IN_DEV_NET_ROUTE_LOCALNET(in_dev, net))
goto martian_destination;
-
- if (ipv4_is_loopback(saddr))
+ } else if (ipv4_is_loopback(saddr)) {
+ if (!IN_DEV_NET_ROUTE_LOCALNET(in_dev, net))
goto martian_source;
}
^ permalink raw reply related
* Re: [PATCH 1/2] net: Allow to create links with given ifindex
From: David Miller @ 2012-08-04 8:25 UTC (permalink / raw)
To: eric.dumazet; +Cc: ebiederm, xemul, netdev
In-Reply-To: <1344064240.9299.1470.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 04 Aug 2012 09:10:40 +0200
> On Fri, 2012-08-03 at 16:56 -0700, David Miller wrote:
>> From: Eric Dumazet <eric.dumazet@gmail.com>
>> Date: Fri, 03 Aug 2012 07:45:29 +0200
>>
>> > @@ -1587,13 +1587,11 @@ static int ip_route_input_slow(struct sk_buff *skb, __be32 daddr, __be32 saddr,
>> > if (ipv4_is_zeronet(daddr))
>> > goto martian_destination;
>> >
>> > - if (likely(!IN_DEV_ROUTE_LOCALNET(in_dev))) {
>> > - if (ipv4_is_loopback(daddr))
>> > - goto martian_destination;
>> > + if (ipv4_is_loopback(daddr) && !IN_DEV_NET_ROUTE_LOCALNET(in_dev, net))
>> > + goto martian_destination;
>> >
>> > - if (ipv4_is_loopback(saddr))
>> > - goto martian_source;
>> > - }
>> > + if (ipv4_is_loopback(saddr) && !IN_DEV_NET_ROUTE_LOCALNET(in_dev, net))
>> > + goto martian_source;
>>
>> Maybe clearer as:
>>
>> if ((ipv4_is_loopback(daddr) || ipv4_is_loopback(saddr)) &&
>> !IN_DEV_NET_ROUTE_LOCALNET(in_dev, net))
>> goto martian_source;
>
> Clearer, but handling of a martian destination is different of the
> martian source ;)
Duh, I missed that, too many martians :-)
^ permalink raw reply
* Re: [PATCH net-next] net: skb_share_check() should use consume_skb()
From: David Miller @ 2012-08-04 8:28 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1344063255.9299.1457.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 04 Aug 2012 08:54:15 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> In order to avoid false drop_monitor indications, we should
> call consume_skb() if skb_clone() was successful.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] ipv4: change inet_addr_hash()
From: David Miller @ 2012-08-04 8:28 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1344064010.9299.1468.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 04 Aug 2012 09:06:50 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> Use net_hash_mix(net) instead of hash_ptr(net, 8), and use
> hash_32() instead of using a serie of XOR
>
> Define IN4_ADDR_HSIZE_SHIFT for clarity
>
> __ip_dev_find() can perform the net_eq() call only if ifa_local
> matches the key, to avoid unneeded dereferences.
>
> remove inline attributes
>
> # size net/ipv4/devinet.o.before net/ipv4/devinet.o
> text data bss dec hex filename
> 17471 2545 2048 22064 5630 net/ipv4/devinet.o.before
> 17335 2545 2048 21928 55a8 net/ipv4/devinet.o
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] ipv4: Introduce IN_DEV_NET_ROUTE_LOCALNET
From: David Miller @ 2012-08-04 8:28 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1344065245.9299.1477.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 04 Aug 2012 09:27:25 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> performance profiles show a high cost in the IN_DEV_ROUTE_LOCALNET()
> call done in ip_route_input_slow(), because of multiple dereferences,
> even if cache lines are clean and available in cpu caches.
>
> Since we already have the 'net' pointer, introduce
> IN_DEV_NET_ROUTE_LOCALNET() macro avoiding two dereferences
> (dev_net(in_dev->dev))
>
> Also change the tests to use IN_DEV_NET_ROUTE_LOCALNET() only if saddr
> or/and daddr are loopback addresse.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* [PATCH] mISDN: Bugfix for layer2 fixed TEI mode
From: Karsten Keil @ 2012-08-04 10:14 UTC (permalink / raw)
To: netdev; +Cc: davem, stable, isdn4linux
If a fixed TEI is used, the initial state of the layer 2 statmachine need to be
4 (TEI assigned). This was true only for Point to Point connections, but not
for the other fixed TEIs. It was not found before, because usually only the
TEI 0 is used as fixed TEI for PtP mode, but if you try X31 packet mode
connections with SAPI 16, TEI 1, it did fail.
Signed-off-by: Karsten Keil <keil@b1-systems.de>
Cc: <stable@vger.kernel.org> # 3.5.x
---
drivers/isdn/mISDN/layer2.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/isdn/mISDN/layer2.c b/drivers/isdn/mISDN/layer2.c
index 0dc8abc..949cabb 100644
--- a/drivers/isdn/mISDN/layer2.c
+++ b/drivers/isdn/mISDN/layer2.c
@@ -2222,7 +2222,7 @@ create_l2(struct mISDNchannel *ch, u_int protocol, u_long options, int tei,
InitWin(l2);
l2->l2m.fsm = &l2fsm;
if (test_bit(FLG_LAPB, &l2->flag) ||
- test_bit(FLG_PTP, &l2->flag) ||
+ test_bit(FLG_FIXED_TEI, &l2->flag) ||
test_bit(FLG_LAPD_NET, &l2->flag))
l2->l2m.state = ST_L2_4;
else
--
1.7.7
^ permalink raw reply related
* [net 0/3][pull request] Intel Wired LAN Driver Updates
From: Peter P Waskiewicz Jr @ 2012-08-04 10:25 UTC (permalink / raw)
To: davem; +Cc: Peter P Waskiewicz Jr, netdev, gospo, sassmann
This series contains various fixes to the igb driver.
The following are changes since commit ff6e1225957cce9e93b8d84dc240e5a44094d0ec:
cris: fix eth_v10.c build error
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ppwaskie/net master
Carolyn Wyborny (1):
igb: Fix for failure to init on some 82576 devices.
Jesper Juhl (2):
igb: correct hardware type (i210/i211) check in igb_loopback_test()
igb: don't break user visible strings over multiple lines in
igb_ethtool.c
drivers/net/ethernet/intel/igb/e1000_82575.c | 16 ++++++++--------
drivers/net/ethernet/intel/igb/igb_ethtool.c | 25 ++++++++++++-------------
2 files changed, 20 insertions(+), 21 deletions(-)
--
1.7.10.4
^ permalink raw reply
* [net 1/3] igb: Fix for failure to init on some 82576 devices.
From: Peter P Waskiewicz Jr @ 2012-08-04 10:25 UTC (permalink / raw)
To: davem; +Cc: Carolyn Wyborny, netdev, gospo, sassmann, Peter P Waskiewicz Jr
In-Reply-To: <1344075952-4198-1-git-send-email-peter.p.waskiewicz.jr@intel.com>
From: Carolyn Wyborny <carolyn.wyborny@intel.com>
Move nvm invalid size check to before size assigned by mac_type for
82575 and later parts in get_invariants function. This fixes a problem
found on some 82576 devices where the part will not initialize because
the nvm_read function pointer ends up getting assigned to the incorrect
function.
Reported By: Stefan Assmann <sassmann@redhat.com>
Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
---
drivers/net/ethernet/intel/igb/e1000_82575.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/e1000_82575.c b/drivers/net/ethernet/intel/igb/e1000_82575.c
index 5e84eaa..ba994fb 100644
--- a/drivers/net/ethernet/intel/igb/e1000_82575.c
+++ b/drivers/net/ethernet/intel/igb/e1000_82575.c
@@ -254,6 +254,14 @@ static s32 igb_get_invariants_82575(struct e1000_hw *hw)
*/
size += NVM_WORD_SIZE_BASE_SHIFT;
+ /*
+ * Check for invalid size
+ */
+ if ((hw->mac.type == e1000_82576) && (size > 15)) {
+ pr_notice("The NVM size is not valid, defaulting to 32K\n");
+ size = 15;
+ }
+
nvm->word_size = 1 << size;
if (hw->mac.type < e1000_i210) {
nvm->opcode_bits = 8;
@@ -281,14 +289,6 @@ static s32 igb_get_invariants_82575(struct e1000_hw *hw)
} else
nvm->type = e1000_nvm_flash_hw;
- /*
- * Check for invalid size
- */
- if ((hw->mac.type == e1000_82576) && (size > 15)) {
- pr_notice("The NVM size is not valid, defaulting to 32K\n");
- size = 15;
- }
-
/* NVM Function Pointers */
switch (hw->mac.type) {
case e1000_82580:
--
1.7.10.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