* Re: [PATCH] Phonet: Correct header retrieval after pskb_may_pull
From: David Miller @ 2010-09-30 2:42 UTC (permalink / raw)
To: remi.denis-courmont
Cc: kumar.sanghvi, netdev, eric.dumazet, gulshan.karmani,
linus.walleij
In-Reply-To: <201009290023.44717.remi.denis-courmont@nokia.com>
From: "Rémi Denis-Courmont" <remi.denis-courmont@nokia.com>
Date: Wed, 29 Sep 2010 00:23:44 +0300
> On Tuesday 28 September 2010 12:10:42 ext Kumar A Sanghvi, you wrote:
>> From: Kumar Sanghvi <kumar.sanghvi@stericsson.com>
>>
>> Retrieve the header after doing pskb_may_pull since, pskb_may_pull
>> could change the buffer structure.
>>
>> This is based on the comment given by Eric Dumazet on Phonet
>> Pipe controller patch for a similar problem.
>>
>> Signed-off-by: Kumar Sanghvi <kumar.sanghvi@stericsson.com>
>> Acked-by: Linus Walleij <linus.walleij@stericsson.com>
...
> Acked-by: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH net-next] arp: remove unnecessary export of arp_broken_ops
From: David Miller @ 2010-09-30 2:46 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20100929120802.2f642d0d@s6510>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Wed, 29 Sep 2010 12:08:02 +0900
> arp_broken_ops is only used in arp.c
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] tcp: tcp_enter_quickack_mode can be static
From: David Miller @ 2010-09-30 2:46 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20100929143014.7f32cec3@s6510>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Wed, 29 Sep 2010 14:30:14 +0900
> Function only used in tcp_input.c
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied.
^ permalink raw reply
* Re: [PATCH] de2104x: disable media debug messages by default
From: David Miller @ 2010-09-30 2:47 UTC (permalink / raw)
To: jgarzik; +Cc: linux, netdev, linux-kernel
In-Reply-To: <4CA23941.2050803@pobox.com>
From: Jeff Garzik <jgarzik@pobox.com>
Date: Tue, 28 Sep 2010 14:51:45 -0400
> On 09/28/2010 02:18 PM, Ondrej Zary wrote:
>> Print media debug messages only when HW debug is enabled.
>>
>> Signed-off-by: Ondrej Zary<linux@rainbow-software.org>
>>
>> --- linux-2.6.36-rc3-/drivers/net/tulip/de2104x.c 2010-09-28
>> --- 19:50:51.000000000 +0200
>> +++ linux-2.6.36-rc3/drivers/net/tulip/de2104x.c 2010-09-28
>> 20:05:34.000000000 +0200
>> @@ -948,8 +948,9 @@ static void de_set_media (struct de_priv
>> else
>> macmode&= ~FullDuplex;
>>
>> - if (netif_msg_link(de)) {
>> + if (netif_msg_link(de))
>> dev_info(&de->dev->dev, "set link %s\n", media_name[media]);
>> + if (netif_msg_hw(de)) {
>> dev_info(&de->dev->dev, "mode 0x%x, sia 0x%x,0x%x,0x%x,0x%x\n",
>> dr32(MacMode), dr32(SIAStatus),
>> dr32(CSR13), dr32(CSR14), dr32(CSR15));
>
> Acked-by: Jeff Garzik <jgarzik@redhat.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH] de2104x: remove experimental status
From: David Miller @ 2010-09-30 2:48 UTC (permalink / raw)
To: jgarzik; +Cc: linux, netdev, linux-kernel
In-Reply-To: <4CA23963.8040409@pobox.com>
From: Jeff Garzik <jgarzik@pobox.com>
Date: Tue, 28 Sep 2010 14:52:19 -0400
> On 09/28/2010 02:46 PM, Ondrej Zary wrote:
>> It should be ready after 8 years...remove the experimental dependency.
>>
>> Signed-off-by: Ondrej Zary<linux@rainbow-software.org>
>>
>> --- linux-2.6.36-rc3-/drivers/net/tulip/Kconfig 2010-08-29
>> --- 17:36:04.000000000 +0200
>> +++ linux-2.6.36-rc3/drivers/net/tulip/Kconfig 2010-09-28
>> 19:49:46.000000000 +0200
>> @@ -11,8 +11,8 @@ menuconfig NET_TULIP
>> if NET_TULIP
>>
>> config DE2104X
>> - tristate "Early DECchip Tulip (dc2104x) PCI support (EXPERIMENTAL)"
>> - depends on PCI&& EXPERIMENTAL
>> + tristate "Early DECchip Tulip (dc2104x) PCI support"
>> + depends on PCI
>> select CRC32
>> ---help---
>> This driver is developed for the SMC EtherPower series Ethernet
>
> Well... it's not the years, it's the quality... which I think has
> been sufficiently increased.
>
> Acked-by: Jeff Garzik <jgarzik@redhat.com>
Also applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: [PATCH net-next] bnx2x: Moved enabling of MSI to the bnx2x_set_num_queues()
From: David Miller @ 2010-09-30 2:48 UTC (permalink / raw)
To: dmitry; +Cc: netdev, vladz, eilong
In-Reply-To: <1285758337.7908.7.camel@lb-tlvb-dmitry>
From: "Dmitry Kravkov" <dmitry@broadcom.com>
Date: Wed, 29 Sep 2010 13:05:37 +0200
> Moved enabling of MSI to the bnx2x_set_num_queues() - the same functions that
> handles the initialization of the MSI-X.
>
> From: Vladislav Zolotarov <vladz@broadcom.com>
> Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
> Signed-off-by: Vladislav Zolotarov <vladz@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
> ---
> Respin of the patch originally prepared by Vladislav Zolotarov.
> This patch is required for the integration of Ben Hutchings bnx2x patch from
> the "netif_set_real_num_{rx,tx}_queues" patch series. Since falling from MSI-X
> to MSI mode due to lack of memory is broken.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 2.6] myri10ge: DCA update (resubmit)
From: David Miller @ 2010-09-30 2:49 UTC (permalink / raw)
To: gallatin; +Cc: netdev, loic
In-Reply-To: <4CA23038.3030808@myri.com>
From: Andrew Gallatin <gallatin@myri.com>
Date: Tue, 28 Sep 2010 14:13:12 -0400
> This patch contains the following DCA improvements to myri10ge:
>
> 1) Finally move myri10ge to use dca3 API
>
> 2) Disable PCIe relaxed ordering when enabling DCA on
> myri10ge. This provides a performance boost on Nehalem
> based Xeons
>
> 3) Make sure to properly initialize NIC's DCA state when it is
> enabled,
> rather than giving the NIC a bogus tag (0) and waiting for
> the first received packet to trigger an update. Not using a
> real tag can cause hardware exceptions on some motherboards
> when a CPU socket is empty.
>
> 3) Always update the cached CPU when our interrupt affinity changes
> so as to avoid excessive calls to dca3_get_tag()
>
> Signed-off-by: Andrew Gallatin <gallatin@myri.com>
> Signed-off-by: Loic Prylli <loic@myri.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: code cleanups
From: Joe Perches @ 2010-09-30 2:49 UTC (permalink / raw)
To: Changli Gao
Cc: David S. Miller, Alexey Kuznetsov, Pekka Savola (ipv6),
James Morris, Hideaki YOSHIFUJI, Patrick McHardy, netdev
In-Reply-To: <1285813497-7384-1-git-send-email-xiaosuo@gmail.com>
On Thu, 2010-09-30 at 10:24 +0800, Changli Gao wrote:
> Compare operations are more readable, and compilers generate the same code
> for the both.
As far as I know, not all supported versions of gcc
generate the same code.
Also, you could probably now remove the (__force u32) casts.
> Use the macros fl4_* to shrink the length of the lines.
>
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
> ---
> net/ipv4/af_inet.c | 7 +++----
> net/ipv4/route.c | 27 ++++++++++++---------------
> 2 files changed, 15 insertions(+), 19 deletions(-)
> diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
> index f581f77..ef26640 100644
> --- a/net/ipv4/af_inet.c
> +++ b/net/ipv4/af_inet.c
> @@ -1338,10 +1338,9 @@ static struct sk_buff **inet_gro_receive(struct sk_buff **head,
>
> iph2 = ip_hdr(p);
>
> - if ((iph->protocol ^ iph2->protocol) |
> - (iph->tos ^ iph2->tos) |
> - ((__force u32)iph->saddr ^ (__force u32)iph2->saddr) |
> - ((__force u32)iph->daddr ^ (__force u32)iph2->daddr)) {
> + if (iph->protocol != iph2->protocol || iph->tos != iph2->tos ||
> + (__force u32)iph->saddr != (__force u32)iph2->saddr ||
> + (__force u32)iph->daddr != (__force u32)iph2->daddr) {
> NAPI_GRO_CB(p)->same_flow = 0;
> continue;
> }
> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> index 98beda4..6b00fde 100644
> --- a/net/ipv4/route.c
> +++ b/net/ipv4/route.c
> @@ -683,19 +683,18 @@ static inline bool rt_caching(const struct net *net)
> static inline bool compare_hash_inputs(const struct flowi *fl1,
> const struct flowi *fl2)
> {
> - return ((((__force u32)fl1->nl_u.ip4_u.daddr ^ (__force u32)fl2->nl_u.ip4_u.daddr) |
> - ((__force u32)fl1->nl_u.ip4_u.saddr ^ (__force u32)fl2->nl_u.ip4_u.saddr) |
> - (fl1->iif ^ fl2->iif)) == 0);
> + return (__force u32)fl1->fl4_dst == (__force u32)fl2->fl4_dst &&
> + (__force u32)fl1->fl4_src == (__force u32)fl2->fl4_src &&
> + fl1->iif == fl2->iif;
> }
>
> static inline int compare_keys(struct flowi *fl1, struct flowi *fl2)
> {
> - return (((__force u32)fl1->nl_u.ip4_u.daddr ^ (__force u32)fl2->nl_u.ip4_u.daddr) |
> - ((__force u32)fl1->nl_u.ip4_u.saddr ^ (__force u32)fl2->nl_u.ip4_u.saddr) |
> - (fl1->mark ^ fl2->mark) |
> - (*(u16 *)&fl1->nl_u.ip4_u.tos ^ *(u16 *)&fl2->nl_u.ip4_u.tos) |
> - (fl1->oif ^ fl2->oif) |
> - (fl1->iif ^ fl2->iif)) == 0;
> + return (__force u32)fl1->fl4_dst == (__force u32)fl2->fl4_dst &&
> + (__force u32)fl1->fl4_src == (__force u32)fl2->fl4_src &&
> + fl1->mark == fl2->mark &&
> + *(u16 *)&fl1->fl4_tos == *(u16 *)&fl2->fl4_tos &&
> + fl1->oif == fl2->oif && fl1->iif == fl2->iif;
> }
>
> static inline int compare_netns(struct rtable *rt1, struct rtable *rt2)
> @@ -2286,12 +2285,10 @@ int ip_route_input_common(struct sk_buff *skb, __be32 daddr, __be32 saddr,
>
> for (rth = rcu_dereference(rt_hash_table[hash].chain); rth;
> rth = rcu_dereference(rth->dst.rt_next)) {
> - if ((((__force u32)rth->fl.fl4_dst ^ (__force u32)daddr) |
> - ((__force u32)rth->fl.fl4_src ^ (__force u32)saddr) |
> - (rth->fl.iif ^ iif) |
> - rth->fl.oif |
> - (rth->fl.fl4_tos ^ tos)) == 0 &&
> - rth->fl.mark == skb->mark &&
> + if ((__force u32)rth->fl.fl4_dst == (__force u32)daddr &&
> + (__force u32)rth->fl.fl4_src == (__force u32)saddr &&
> + rth->fl.iif == iif && rth->fl.oif == 0 &&
> + rth->fl.fl4_tos == tos && rth->fl.mark == skb->mark &&
> net_eq(dev_net(rth->dst.dev), net) &&
> !rt_is_expired(rth)) {
> if (noref) {
^ permalink raw reply
* Re: [PATCH net-next 1/2] enic: remove dead code
From: Stephen Hemminger @ 2010-09-30 2:49 UTC (permalink / raw)
To: Vasanthy Kolluri (vkolluri)
Cc: netdev, Scott Feldman (scofeldm), Roopa Prabhu (roprabhu),
David Miller
In-Reply-To: <212AA327A3557741A058E787E0618873042E0BC6@xmb-sjc-219.amer.cisco.com>
On Wed, 29 Sep 2010 17:10:00 -0700
"Vasanthy Kolluri (vkolluri)" <vkolluri@cisco.com> wrote:
> Hi Stephen,
>
>
>
> Thanks a lot for submitting this patch. However, I have got few
> concerns:
>
>
>
> 1. Need to retain vnic_dev_soft_reset and vnic_dev_soft_reset_done
> as they are used in vnic_dev_hang_reset and vnic_dev_hang_reset_done
> respectively
>
> 2. Want to retain enic_set_rss_key and enic_set_rss_cpu as we will
> be using those in the near future for adding multi rq functionality to
> enic.
>
> 3. Additional cleanup in vnic_rss.h. FYI, the struct defines in
> vnic_rss.h are currently not in use. But I retained them for the same
> reason as in #2.
Ok, but Linux tree is not the repository for "possible future enhancements".
Do it or remove it.
^ permalink raw reply
* Re: [PATCH net-next 1/2] enic: remove dead code
From: David Miller @ 2010-09-30 2:57 UTC (permalink / raw)
To: shemminger; +Cc: vkolluri, netdev, scofeldm, roprabhu
In-Reply-To: <20100930114958.59c438d7@s6510>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Thu, 30 Sep 2010 11:49:58 +0900
> Ok, but Linux tree is not the repository for "possible future enhancements".
> Do it or remove it.
Agreed, remove it now and add it back when you submit the patches that
use the code.
The code is in the repository history so it's not like it's lost.
^ permalink raw reply
* Re: [PATCH] net: code cleanups
From: Changli Gao @ 2010-09-30 3:07 UTC (permalink / raw)
To: Joe Perches, Eric Dumazet
Cc: David S. Miller, Alexey Kuznetsov, Pekka Savola (ipv6),
James Morris, Hideaki YOSHIFUJI, Patrick McHardy, netdev
In-Reply-To: <1285814979.1866.229.camel@Joe-Laptop>
On Thu, Sep 30, 2010 at 10:49 AM, Joe Perches <joe@perches.com> wrote:
> On Thu, 2010-09-30 at 10:24 +0800, Changli Gao wrote:
>> Compare operations are more readable, and compilers generate the same code
>> for the both.
>
> As far as I know, not all supported versions of gcc
> generate the same code.
Is the former better for the compilers?
>
> Also, you could probably now remove the (__force u32) casts.
>
Maybe Eric doesn't think so.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [PATCH] net: code cleanups
From: Joe Perches @ 2010-09-30 3:13 UTC (permalink / raw)
To: Changli Gao
Cc: Eric Dumazet, David S. Miller, Alexey Kuznetsov,
Pekka Savola (ipv6), James Morris, Hideaki YOSHIFUJI,
Patrick McHardy, netdev
In-Reply-To: <AANLkTinRm7dB=n7KG8+TU0_=gf-19LUPV+40_m2YxbU2@mail.gmail.com>
On Thu, 2010-09-30 at 11:07 +0800, Changli Gao wrote:
> On Thu, Sep 30, 2010 at 10:49 AM, Joe Perches <joe@perches.com> wrote:
> > On Thu, 2010-09-30 at 10:24 +0800, Changli Gao wrote:
> >> Compare operations are more readable, and compilers generate the same code
> >> for the both.
> > As far as I know, not all supported versions of gcc
> > generate the same code.
> Is the former better for the compilers?
Yes. I don't know how much it matters though.
> > Also, you could probably now remove the (__force u32) casts.
> Maybe Eric doesn't think so.
Comparisons of equal types don't need (__force u32) casts.
They needed to be cast to u32 for the bitwise or's to avoid
compiler warnings.
^ permalink raw reply
* Re: [PATCHv3 net-next-2.6 3/5] XFRM,IPv6: Add IRO src/dst address remapping XFRM types and i/o handlers
From: David Miller @ 2010-09-30 3:16 UTC (permalink / raw)
To: arno; +Cc: eric.dumazet, herbert, yoshfuji, netdev
In-Reply-To: <fd4eec3c9486c46b535e89ceed479c7536f51fb9.1285749610.git.arno@natisbad.org>
From: Arnaud Ebalard <arno@natisbad.org>
Date: Wed, 29 Sep 2010 11:05:47 +0200
> +static int mip6_iro_src_reject(struct xfrm_state *x, struct sk_buff *skb, struct flowi *fl)
> +{
> + int err = 0;
> +
> + /* XXX We may need some reject handler at some point but it is not
> + * critical yet: see xfrm_secpath_reject() in net/xfrm/xfrm_policy.c
> + * and aslo what mip6_destopt_reject() implements */
> +
> + printk("XXX FIXME: mip6_iro_src_reject() called\n");
pr_debug() or pr_err() or get rid of it altogher and use WARN_ON() or
similar.
> + spin_lock(&x->lock);
> + if (!ipv6_addr_equal(&iph->daddr, (struct in6_addr *)x->coaddr) &&
> + !ipv6_addr_any((struct in6_addr *)x->coaddr))
> + err = -ENOENT;
> + spin_unlock(&x->lock);
What are you actually protecting with this lock? The moment you drop
it the x->coaddr can change which changes the result you should return
here.
I suspect you either don't need the lock, or you need to lock at a higher
level.
> + printk(KERN_INFO "%s: spi is not 0: %u\n", __func__,
pr_info()
> + printk(KERN_INFO "%s: state's mode is not %u: %u\n",
pr_info()
> + __func__, XFRM_MODE_ROUTEOPTIMIZATION,
Printing decimal values for CPP macro constants does not make log
messages very readable.
^ permalink raw reply
* Re: [PATCHv3 net-next-2.6 4/5] XFRM,IPv6: Add IRO remapping hook in xfrm_input()
From: David Miller @ 2010-09-30 3:17 UTC (permalink / raw)
To: arno; +Cc: eric.dumazet, herbert, yoshfuji, netdev
In-Reply-To: <cc9aa9a5b238d27701140d0d9230593954e53a39.1285749610.git.arno@natisbad.org>
From: Arnaud Ebalard <arno@natisbad.org>
Date: Wed, 29 Sep 2010 11:05:59 +0200
> +EXPORT_SYMBOL(xfrm4_input_addr_check);
> +EXPORT_SYMBOL(xfrm6_input_addr_check);
net/ipv{4,6}/xfrm{4,6}_{state,input}.c will be built together as a
group, so there is no need to export the address check symbol to
modules.
^ permalink raw reply
* Re: [PATCH v6 0/8] ptp: IEEE 1588 hardware clock support
From: Christian Riesch @ 2010-09-30 3:50 UTC (permalink / raw)
To: Christoph Lameter
Cc: Rodolfo Giometti, Arnd Bergmann, Peter Zijlstra, john stultz,
devicetree-discuss, linux-kernel, David Miller, netdev,
linux-arm-kernel, linux-api, Thomas Gleixner, linuxppc-dev,
Richard Cochran, Alan Cox, Krzysztof Halasa
In-Reply-To: <alpine.DEB.2.00.1009271035110.9258@router.home>
Quoting Christoph Lameter <cl@linux.com>:
> On Thu, 23 Sep 2010, Christian Riesch wrote:
>
>> > > It implies clock tuning in userspace for a potential sub microsecond
>> > > accurate clock. The clock accuracy will be limited by user space
>> > > latencies and noise. You wont be able to discipline the system clock
>> > > accurately.
>> >
>> > Noise matters, latency doesn't.
>>
>> Well put! That's why we need hardware support for PTP timestamping to reduce
>> the noise, but get along well with the clock servo that is steering
>> the PHC in
>> user space.
>
> Even if I buy into the catch phrase above: User space is subject to noise
> that the in kernel code is not. If you do the tuning over long intervals
> then it hopefully averages out but it still causes jitter effects that
> affects the degree of accuracy (or sync) that you can reach. And the noise
> varies with the load on the system.
Yes and no. If you regard it as a control system: The latencies of the
operating system are a dead time in the control system. The sampling
time is quite large, one second, maybe around 100ms or 10ms in
telecommunication applications, but that is still large compared to
the latencies you expect to have in the operating system. Hence, this
latencies (=dead time) can be neglected and the important thing that
remains is the noise that you introduce in the measurements of the
time stamps, which is therefore done in hardware.
I admit that my short statement above is not completely correct, I
should have mentioned the rather large sampling time we are dealing
with here.
Christian
^ permalink raw reply
* RE: [PATCH net-next 1/2] enic: remove dead code
From: Vasanthy Kolluri (vkolluri) @ 2010-09-30 5:16 UTC (permalink / raw)
To: David Miller, shemminger
Cc: netdev, Scott Feldman (scofeldm), Roopa Prabhu (roprabhu)
In-Reply-To: <20100929.195720.241921649.davem@davemloft.net>
Thanks. I'll remove it.
-Vasanthy
-----Original Message-----
From: David Miller [mailto:davem@davemloft.net]
Sent: Wednesday, September 29, 2010 7:57 PM
To: shemminger@vyatta.com
Cc: Vasanthy Kolluri (vkolluri); netdev@vger.kernel.org; Scott Feldman
(scofeldm); Roopa Prabhu (roprabhu)
Subject: Re: [PATCH net-next 1/2] enic: remove dead code
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Thu, 30 Sep 2010 11:49:58 +0900
> Ok, but Linux tree is not the repository for "possible future
enhancements".
> Do it or remove it.
Agreed, remove it now and add it back when you submit the patches that
use the code.
The code is in the repository history so it's not like it's lost.
^ permalink raw reply
* Re: [PATCH] net: code cleanups
From: Eric Dumazet @ 2010-09-30 5:16 UTC (permalink / raw)
To: Changli Gao
Cc: David S. Miller, Alexey Kuznetsov, Pekka Savola (ipv6),
James Morris, Hideaki YOSHIFUJI, Patrick McHardy, netdev
In-Reply-To: <1285813497-7384-1-git-send-email-xiaosuo@gmail.com>
Le jeudi 30 septembre 2010 à 10:24 +0800, Changli Gao a écrit :
> Compare operations are more readable, and compilers generate the same code
> for the both.
>
You have a buggy compiler then.
I know this code is ugly, but please keep it as is, dont add conditional
branches on hot paths.
Thanks
> Use the macros fl4_* to shrink the length of the lines.
>
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
> ---
> net/ipv4/af_inet.c | 7 +++----
> net/ipv4/route.c | 27 ++++++++++++---------------
> 2 files changed, 15 insertions(+), 19 deletions(-)
> diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
> index f581f77..ef26640 100644
> --- a/net/ipv4/af_inet.c
> +++ b/net/ipv4/af_inet.c
> @@ -1338,10 +1338,9 @@ static struct sk_buff **inet_gro_receive(struct sk_buff **head,
>
> iph2 = ip_hdr(p);
>
> - if ((iph->protocol ^ iph2->protocol) |
> - (iph->tos ^ iph2->tos) |
> - ((__force u32)iph->saddr ^ (__force u32)iph2->saddr) |
> - ((__force u32)iph->daddr ^ (__force u32)iph2->daddr)) {
> + if (iph->protocol != iph2->protocol || iph->tos != iph2->tos ||
> + (__force u32)iph->saddr != (__force u32)iph2->saddr ||
> + (__force u32)iph->daddr != (__force u32)iph2->daddr) {
> NAPI_GRO_CB(p)->same_flow = 0;
> continue;
> }
> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> index 98beda4..6b00fde 100644
> --- a/net/ipv4/route.c
> +++ b/net/ipv4/route.c
> @@ -683,19 +683,18 @@ static inline bool rt_caching(const struct net *net)
> static inline bool compare_hash_inputs(const struct flowi *fl1,
> const struct flowi *fl2)
> {
> - return ((((__force u32)fl1->nl_u.ip4_u.daddr ^ (__force u32)fl2->nl_u.ip4_u.daddr) |
> - ((__force u32)fl1->nl_u.ip4_u.saddr ^ (__force u32)fl2->nl_u.ip4_u.saddr) |
> - (fl1->iif ^ fl2->iif)) == 0);
> + return (__force u32)fl1->fl4_dst == (__force u32)fl2->fl4_dst &&
> + (__force u32)fl1->fl4_src == (__force u32)fl2->fl4_src &&
> + fl1->iif == fl2->iif;
> }
>
> static inline int compare_keys(struct flowi *fl1, struct flowi *fl2)
> {
> - return (((__force u32)fl1->nl_u.ip4_u.daddr ^ (__force u32)fl2->nl_u.ip4_u.daddr) |
> - ((__force u32)fl1->nl_u.ip4_u.saddr ^ (__force u32)fl2->nl_u.ip4_u.saddr) |
> - (fl1->mark ^ fl2->mark) |
> - (*(u16 *)&fl1->nl_u.ip4_u.tos ^ *(u16 *)&fl2->nl_u.ip4_u.tos) |
> - (fl1->oif ^ fl2->oif) |
> - (fl1->iif ^ fl2->iif)) == 0;
> + return (__force u32)fl1->fl4_dst == (__force u32)fl2->fl4_dst &&
> + (__force u32)fl1->fl4_src == (__force u32)fl2->fl4_src &&
> + fl1->mark == fl2->mark &&
> + *(u16 *)&fl1->fl4_tos == *(u16 *)&fl2->fl4_tos &&
> + fl1->oif == fl2->oif && fl1->iif == fl2->iif;
> }
>
> static inline int compare_netns(struct rtable *rt1, struct rtable *rt2)
> @@ -2286,12 +2285,10 @@ int ip_route_input_common(struct sk_buff *skb, __be32 daddr, __be32 saddr,
>
> for (rth = rcu_dereference(rt_hash_table[hash].chain); rth;
> rth = rcu_dereference(rth->dst.rt_next)) {
> - if ((((__force u32)rth->fl.fl4_dst ^ (__force u32)daddr) |
> - ((__force u32)rth->fl.fl4_src ^ (__force u32)saddr) |
> - (rth->fl.iif ^ iif) |
> - rth->fl.oif |
> - (rth->fl.fl4_tos ^ tos)) == 0 &&
> - rth->fl.mark == skb->mark &&
> + if ((__force u32)rth->fl.fl4_dst == (__force u32)daddr &&
> + (__force u32)rth->fl.fl4_src == (__force u32)saddr &&
> + rth->fl.iif == iif && rth->fl.oif == 0 &&
> + rth->fl.fl4_tos == tos && rth->fl.mark == skb->mark &&
> net_eq(dev_net(rth->dst.dev), net) &&
> !rt_is_expired(rth)) {
> if (noref) {
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH net-next] ip_gre: comments change
From: Eric Dumazet @ 2010-09-30 5:32 UTC (permalink / raw)
To: David Miller; +Cc: netdev
HARD_TX_LOCK no longer protects tunnels from dead loops,
but xmit_recursion percpu counter.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/ipv4/ip_gre.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 035db63..fbe2c47 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -64,13 +64,13 @@
We cannot track such dead loops during route installation,
it is infeasible task. The most general solutions would be
to keep skb->encapsulation counter (sort of local ttl),
- and silently drop packet when it expires. It is the best
+ and silently drop packet when it expires. It is a good
solution, but it supposes maintaing new variable in ALL
skb, even if no tunneling is used.
- Current solution: HARD_TX_LOCK lock breaks dead loops.
-
-
+ Current solution: xmit_recursion breaks dead loops. This is a percpu
+ counter, since when we enter the first ndo_xmit(), cpu migration is
+ forbidden. We force an exit if this counter reaches RECURSION_LIMIT
2. Networking dead loops would not kill routers, but would really
kill network. IP hop limit plays role of "t->recursion" in this case,
^ permalink raw reply related
* Re: [PATCH] net: code cleanups
From: Changli Gao @ 2010-09-30 6:09 UTC (permalink / raw)
To: Eric Dumazet
Cc: David S. Miller, Alexey Kuznetsov, Pekka Savola (ipv6),
James Morris, Hideaki YOSHIFUJI, Patrick McHardy, netdev
In-Reply-To: <1285823808.5211.627.camel@edumazet-laptop>
On Thu, Sep 30, 2010 at 1:16 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le jeudi 30 septembre 2010 à 10:24 +0800, Changli Gao a écrit :
>> Compare operations are more readable, and compilers generate the same code
>> for the both.
>>
>
> You have a buggy compiler then.
gcc version 4.4.3 (Gentoo 4.4.3-r2 p1.2)
rth = rcu_dereference(rth->dst.rt_next)) {
if ((((__force u32)rth->fl.fl4_dst ^ (__force u32)daddr) |
((__force u32)rth->fl.fl4_src ^ (__force u32)saddr) |
(rth->fl.iif ^ iif) |
2f12: 44 3b 80 dc 00 00 00 cmp 0xdc(%rax),%r8d
2f19: 0f 85 a2 00 00 00 jne 2fc1 <ip_route_input_common+0x145
>
rth->fl.oif |
2f1f: 83 b8 d8 00 00 00 00 cmpl $0x0,0xd8(%rax)
2f26: 0f 85 95 00 00 00 jne 2fc1 <ip_route_input_common+0x145
>
tos &= IPTOS_RT_MASK;
hash = rt_hash(daddr, saddr, iif, rt_genid(net));
for (rth = rcu_dereference(rt_hash_table[hash].chain); rth;
rth = rcu_dereference(rth->dst.rt_next)) {
if ((((__force u32)rth->fl.fl4_dst ^ (__force u32)daddr) |
2f2c: 44 3b b8 e4 00 00 00 cmp 0xe4(%rax),%r15d
2f33: 0f 85 88 00 00 00 jne 2fc1
<ip_route_input_common+0x145>
((__force u32)rth->fl.fl4_src ^ (__force u32)saddr) |
2f39: 44 3b b0 e8 00 00 00 cmp 0xe8(%rax),%r14d
2f40: 75 7f jne 2fc1
<ip_route_input_common+0x145>
>
> I know this code is ugly, but please keep it as is, dont add conditional
> branches on hot paths.
>
If the compiler doesn't generate conditional branches, we have to
touch every necessary field of all the cache entries in one hash
bucket. Is it better than condition branch? I think the compiler
developers know it better.
And the compiler reorders the conditional branches, is it expected?
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: Packet time delays on multi-core systems
From: Alexey Vlasov @ 2010-09-30 6:24 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Linux Kernel Mailing List, netdev
In-Reply-To: <1285796721.5211.156.camel@edumazet-laptop>
Here I found some dude with the same problem:
http://lkml.org/lkml/2010/7/9/340
On Wed, Sep 29, 2010 at 11:45:21PM +0200, Eric Dumazet wrote:
> Le mercredi 29 septembre 2010 ?? 23:18 +0400, Alexey Vlasov a ??crit :
> > Hi.
> >
> > I'm not sure actually that I should write here, may be I should ask in
> > netfilter maillist, but if is something wrong please correct me.
> >
>
> CC netdev
>
>
> > I've got rather large linux shared hosting, and on my new servers I
> > noticed some strange singularity, that this simple rule:
> >
> > # iptables -A OUTPUT -p tcp -m tcp --dport 80 --tcp-flags
> > FIN,SYN,RST,ACK SYN -j LOG --log-prefix "ipsec:SYN-OUTPUT "
> > --log-uid
> >
> > gives essential time delays simply at ping from the adjacent server
> > on a local area network. I don't know precisely what's wrong whether the
> > reason is in the bad support by a kernel of new hardware, or it concerns
> > generally the new kernel, but now it leads to the situation that even at simple
> > DDOS attacks to client sites, it becomes difficult to make something, and in
> > general all works only worse.
> >
> > It seems to me that with the increase of CPU cores' amount, it only becomes
> > worse and worse, and, obviously, iptables uses resources of only one processor,
> > which resources to it for any reason doesn't suffice.
> >
>
> Its not true. iptables can run on all cpus in //
>
> > newbox # iptables -F
> > otherbox # ping -c 100 newbox
> > ...
> > 100 packets transmitted, 100 received, 0% packet loss, time 100044ms
> > rtt min/avg/max/mdev = 0.133/2.637/17.172/3.736 ms
> >
> > OK.
> >
> > newbox # iptables -A OUTPUT -p tcp -m tcp --dport 80 --tcp-flags FIN,SYN,RST,ACK SYN
> > -j LOG --log-prefix "ipsec:SYN-OUTPUT " --log-uid
> > otherbox # ping -c 100 newbox
> > ...
> > 64 bytes from (newbox): icmp_seq=3 ttl=64 time=1.58 ms
> > 64 bytes from (newbox): icmp_seq=4 ttl=64 time=98.7 ms
> > 64 bytes from (newbox): icmp_seq=5 ttl=64 time=18.2 ms
> > 64 bytes from (newbox): icmp_seq=6 ttl=64 time=6.13 ms
> > 64 bytes from (newbox): icmp_seq=7 ttl=64 time=108 ms
> > ...
> > 64 bytes from (newbox): icmp_seq=55 ttl=64 time=2.30 ms
> > 64 bytes from (newbox): icmp_seq=56 ttl=64 time=59.9 ms
> > 64 bytes from (newbox): icmp_seq=57 ttl=64 time=0.155 ms
> > ...
> > 64 bytes from (newbox): icmp_seq=61 ttl=64 time=13.4 ms
> > 64 bytes from (newbox): icmp_seq=62 ttl=64 time=55.0 ms
> > 64 bytes from (newbox): icmp_seq=63 ttl=64 time=0.233 ms
> > ...
> > 100 packets transmitted, 100 received, 0% packet loss, time 99957ms
> > rtt min/avg/max/mdev = 0.111/7.519/108.061/18.478 ms
> >
> > newbox # iptables -L -v -n
> > Chain INPUT (policy ACCEPT 346K packets, 213M bytes)
> > pkts bytes target prot opt in out source destination
> >
> > Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
> > pkts bytes target prot opt in out source destination
> >
> > Chain OUTPUT (policy ACCEPT 296K packets, 290M bytes)
> > pkts bytes target prot opt in out source destination
> > 234 14040 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0
> > tcp dpt:80 flags:0x17/0x02 LOG flags 8 level 4 prefix `ipsec:SYN-OUTPUT- '
> >
> > My old server: Intel SR1500, Xeon 5430, kernel 2.6.24 - 2.6.28
> > Newbox: SR1620UR, 5650, kernel 2.6.32
> >
> > Thanks in advance.
> >
>
> Seems strange indeed, since the LOG you add should not slowdown icmp
> trafic that much.
>
> But if you send SYN packets in the same time, (logged), this might slow
> down the reception (and answers) of ICMP frames. LOG target can be quite
> expensive...
>
> Is using other rules gives same problem ?
>
> iptables -A OUTPUT -p tcp -m tcp --dport 80 --tcp-flags FIN,SYN,RST,ACK SYN
> iptables -A OUTPUT -p tcp -m tcp --dport 80 --tcp-flags FIN,SYN,RST,ACK SYN
> iptables -A OUTPUT -p tcp -m tcp --dport 80 --tcp-flags FIN,SYN,RST,ACK SYN
> iptables -A OUTPUT -p tcp -m tcp --dport 80 --tcp-flags FIN,SYN,RST,ACK SYN
>
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
BRGDS. Alexey Vlasov.
^ permalink raw reply
* Re: [PATCH] net: code cleanups
From: Eric Dumazet @ 2010-09-30 6:31 UTC (permalink / raw)
To: Changli Gao
Cc: David S. Miller, Alexey Kuznetsov, Pekka Savola (ipv6),
James Morris, Hideaki YOSHIFUJI, Patrick McHardy, netdev
In-Reply-To: <AANLkTimVngrNU+PLbaf8r42J3HrvURpY8KUPa+--KvLC@mail.gmail.com>
Le jeudi 30 septembre 2010 à 14:09 +0800, Changli Gao a écrit :
> On Thu, Sep 30, 2010 at 1:16 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > Le jeudi 30 septembre 2010 à 10:24 +0800, Changli Gao a écrit :
> >> Compare operations are more readable, and compilers generate the same code
> >> for the both.
> >>
> >
> > You have a buggy compiler then.
>
> gcc version 4.4.3 (Gentoo 4.4.3-r2 p1.2)
>
> rth = rcu_dereference(rth->dst.rt_next)) {
> if ((((__force u32)rth->fl.fl4_dst ^ (__force u32)daddr) |
> ((__force u32)rth->fl.fl4_src ^ (__force u32)saddr) |
> (rth->fl.iif ^ iif) |
> 2f12: 44 3b 80 dc 00 00 00 cmp 0xdc(%rax),%r8d
> 2f19: 0f 85 a2 00 00 00 jne 2fc1 <ip_route_input_common+0x145
> >
> rth->fl.oif |
> 2f1f: 83 b8 d8 00 00 00 00 cmpl $0x0,0xd8(%rax)
> 2f26: 0f 85 95 00 00 00 jne 2fc1 <ip_route_input_common+0x145
> >
> tos &= IPTOS_RT_MASK;
> hash = rt_hash(daddr, saddr, iif, rt_genid(net));
>
> for (rth = rcu_dereference(rt_hash_table[hash].chain); rth;
> rth = rcu_dereference(rth->dst.rt_next)) {
> if ((((__force u32)rth->fl.fl4_dst ^ (__force u32)daddr) |
> 2f2c: 44 3b b8 e4 00 00 00 cmp 0xe4(%rax),%r15d
> 2f33: 0f 85 88 00 00 00 jne 2fc1
> <ip_route_input_common+0x145>
> ((__force u32)rth->fl.fl4_src ^ (__force u32)saddr) |
> 2f39: 44 3b b0 e8 00 00 00 cmp 0xe8(%rax),%r14d
> 2f40: 75 7f jne 2fc1
> <ip_route_input_common+0x145>
>
>
> >
> > I know this code is ugly, but please keep it as is, dont add conditional
> > branches on hot paths.
> >
>
> If the compiler doesn't generate conditional branches, we have to
> touch every necessary field of all the cache entries in one hash
> bucket. Is it better than condition branch? I think the compiler
> developers know it better.
Last famous words.
Are you aware of cache lines (64 bytes at least on typical cpus), and
that all fields are already in CPU L1 cache ? I (and others) worked hard
in the past.
>
> And the compiler reorders the conditional branches, is it expected?
>
Your compiler added conditional branches on a code not wanting them,
only because on _your_ cpu, these conditional branches might be cheap.
Now, try to compile for an i686 target and see the difference.
If there was no difference, your compiler would be _buggy_, because not
generating optimal assembly.
Here I get :
c141dda9: 8b 55 e8 mov -0x18(%ebp),%edx
c141ddac: 8b 81 9c 00 00 00 mov 0x9c(%ecx),%eax
c141ddb2: 33 91 a0 00 00 00 xor 0xa0(%ecx),%edx
c141ddb8: 31 f0 xor %esi,%eax
c141ddba: 09 d0 or %edx,%eax
c141ddbc: 8b 55 e0 mov -0x20(%ebp),%edx
c141ddbf: 33 91 94 00 00 00 xor 0x94(%ecx),%edx
c141ddc5: 09 d0 or %edx,%eax
c141ddc7: 0f b6 55 e7 movzbl -0x19(%ebp),%edx
c141ddcb: 0b 81 90 00 00 00 or 0x90(%ecx),%eax
c141ddd1: 32 91 a4 00 00 00 xor 0xa4(%ecx),%dl
c141ddd7: 0f b6 d2 movzbl %dl,%edx
c141ddda: 09 d0 or %edx,%eax
c141dddc: 0f 85 9d 00 00 00 jne c141de7f <ip_route_input_common+0x1b4>
As you can see, only one conditional branch.
Your patch is not welcomed, thanks.
^ permalink raw reply
* Re: Packet time delays on multi-core systems
From: Eric Dumazet @ 2010-09-30 6:33 UTC (permalink / raw)
To: Alexey Vlasov; +Cc: Linux Kernel Mailing List, netdev
In-Reply-To: <20100930062419.GD86786@beaver.vrungel.ru>
Le jeudi 30 septembre 2010 à 10:24 +0400, Alexey Vlasov a écrit :
> Here I found some dude with the same problem:
> http://lkml.org/lkml/2010/7/9/340
>
In your opinion its the same problem.
But the description you gave is completely different.
You have time skew only when activating a particular iptables rule.
No ?
^ permalink raw reply
* Re: [PATCH net-next] ip_gre: comments change
From: David Miller @ 2010-09-30 6:35 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1285824777.5211.663.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 30 Sep 2010 07:32:57 +0200
> HARD_TX_LOCK no longer protects tunnels from dead loops,
> but xmit_recursion percpu counter.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, t hanks Eric.
^ permalink raw reply
* Re: [PATCH v2 1/2] Phonet: Implement Pipe Controller to support Nokia Slim Modems
From: Kumar SANGHVI @ 2010-09-30 7:19 UTC (permalink / raw)
To: Rémi Denis-Courmont
Cc: netdev@vger.kernel.org, STEricsson_nomadik_linux,
Sudeep DIVAKARAN, Gulshan KARMANI, Linus WALLEIJ
In-Reply-To: <201009292121.18274.remi.denis-courmont@nokia.com>
Hi Rémi Denis-Courmont,
On Wed, Sep 29, 2010 at 20:21:17 +0200, Rémi Denis-Courmont wrote:
> It seems to me that you really want to implement the connect() socket call, so
> that one of the two endpoints will stand up for the missing controller.
Yes, implementing connect() socket call would be nice.
> That's
> still much cleaner than CREATE and DESTROY ioctl()'s.
I have not introduced any new ioctl()'s as part of Pipe controller
implementation.
The PIPE_CREATE/PIPE_DESTROY/PIPE_ENABLE/PIPE_DISABLE are all provided
as socket options.
So, user-space can call setsockopt for creating/enabling or
disabling/destroying pipe.
Regarding implementing connect() socket call, few queries:
1. It should carry out all the same steps which I am currently doing as part
of PIPE_CREATE socket option, right?
2. Currently, as part of Pipe controller implementation, user-space
follows below sequence:-
socket()
bind()
listen()
setsockopt(PIPE_CREATE)
accept()
In the phonet stack pipe controller logic, we wait for PEP_CONNECT_RESP
from host-pep (GPRS socket or video telephony socket is a host-pep.
pep_reply sends out the PEP_CONNECT_RESP) and remote-pep (modem),
negotiate the best flow-control to be used, and then send
PIPE_CREATED_IND, with selected flow-control to both pipe end-points.
I am not sure how the sequence would be when using the connect() socket
call.
Thanks for your inputs.
Thanks & regards,
Kumar.
^ permalink raw reply
* [net-next-2.6 PATCH] ixgbe: fix link issues and panic with shared interrupts for 82598
From: Jeff Kirsher @ 2010-09-30 7:35 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, bphilips, Emil Tantilov, Jeff Kirsher
From: Emil Tantilov <emil.s.tantilov@intel.com>
Fix possible panic/hang with shared Legacy interrupts by not enabling
interrupts when interface is down.
Also fixes an intermittent link by enabling LSC upon exit from ixgbe_intr()
This patch adds flags to ixgbe_irq_enable() to allow for some flexibility
when enabling interrupts.
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
Tested-by: Stephen Ko <stephen.s.ko@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ixgbe/ixgbe_main.c | 36 ++++++++++++++++++++++++++----------
1 files changed, 26 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
index c35185c..c35e13c 100644
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -2233,7 +2233,8 @@ static void ixgbe_set_itr(struct ixgbe_adapter *adapter)
* ixgbe_irq_enable - Enable default interrupt generation settings
* @adapter: board private structure
**/
-static inline void ixgbe_irq_enable(struct ixgbe_adapter *adapter)
+static inline void ixgbe_irq_enable(struct ixgbe_adapter *adapter, bool queues,
+ bool flush)
{
u32 mask;
@@ -2254,8 +2255,10 @@ static inline void ixgbe_irq_enable(struct ixgbe_adapter *adapter)
mask |= IXGBE_EIMS_FLOW_DIR;
IXGBE_WRITE_REG(&adapter->hw, IXGBE_EIMS, mask);
- ixgbe_irq_enable_queues(adapter, ~0);
- IXGBE_WRITE_FLUSH(&adapter->hw);
+ if (queues)
+ ixgbe_irq_enable_queues(adapter, ~0);
+ if (flush)
+ IXGBE_WRITE_FLUSH(&adapter->hw);
if (adapter->num_vfs > 32) {
u32 eitrsel = (1 << (adapter->num_vfs - 32)) - 1;
@@ -2277,7 +2280,7 @@ static irqreturn_t ixgbe_intr(int irq, void *data)
u32 eicr;
/*
- * Workaround for silicon errata. Mask the interrupts
+ * Workaround for silicon errata on 82598. Mask the interrupts
* before the read of EICR.
*/
IXGBE_WRITE_REG(hw, IXGBE_EIMC, IXGBE_IRQ_CLEAR_MASK);
@@ -2286,10 +2289,15 @@ static irqreturn_t ixgbe_intr(int irq, void *data)
* therefore no explict interrupt disable is necessary */
eicr = IXGBE_READ_REG(hw, IXGBE_EICR);
if (!eicr) {
- /* shared interrupt alert!
+ /*
+ * shared interrupt alert!
* make sure interrupts are enabled because the read will
- * have disabled interrupts due to EIAM */
- ixgbe_irq_enable(adapter);
+ * have disabled interrupts due to EIAM
+ * finish the workaround of silicon errata on 82598. Unmask
+ * the interrupt that we masked before the EICR read.
+ */
+ if (!test_bit(__IXGBE_DOWN, &adapter->state))
+ ixgbe_irq_enable(adapter, true, true);
return IRQ_NONE; /* Not our interrupt */
}
@@ -2313,6 +2321,14 @@ static irqreturn_t ixgbe_intr(int irq, void *data)
__napi_schedule(&(q_vector->napi));
}
+ /*
+ * re-enable link(maybe) and non-queue interrupts, no flush.
+ * ixgbe_poll will re-enable the queue interrupts
+ */
+
+ if (!test_bit(__IXGBE_DOWN, &adapter->state))
+ ixgbe_irq_enable(adapter, false, false);
+
return IRQ_HANDLED;
}
@@ -3048,7 +3064,7 @@ static void ixgbe_vlan_rx_kill_vid(struct net_device *netdev, u16 vid)
vlan_group_set_device(adapter->vlgrp, vid, NULL);
if (!test_bit(__IXGBE_DOWN, &adapter->state))
- ixgbe_irq_enable(adapter);
+ ixgbe_irq_enable(adapter, true, true);
/* remove VID from filter table */
hw->mac.ops.set_vfta(&adapter->hw, vid, pool_ndx, false);
@@ -3145,7 +3161,7 @@ static void ixgbe_vlan_rx_register(struct net_device *netdev,
ixgbe_vlan_rx_add_vid(netdev, 0);
if (!test_bit(__IXGBE_DOWN, &adapter->state))
- ixgbe_irq_enable(adapter);
+ ixgbe_irq_enable(adapter, true, true);
}
static void ixgbe_restore_vlan(struct ixgbe_adapter *adapter)
@@ -3546,7 +3562,7 @@ static int ixgbe_up_complete(struct ixgbe_adapter *adapter)
/* clear any pending interrupts, may auto mask */
IXGBE_READ_REG(hw, IXGBE_EICR);
- ixgbe_irq_enable(adapter);
+ ixgbe_irq_enable(adapter, true, true);
/*
* If this adapter has a fan, check to see if we had a failure
^ 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