* Re: [PATCH] pktgen node allocation
From: Eric Dumazet @ 2010-03-19 9:28 UTC (permalink / raw)
To: Robert Olsson; +Cc: David Miller, netdev
In-Reply-To: <19363.14702.909265.380669@gargle.gargle.HOWL>
Le vendredi 19 mars 2010 à 09:44 +0100, Robert Olsson a écrit :
>
> Hi,
> Here is patch to manipulate packet node allocation and implicitly
> how packets are DMA'd etc.
>
> The flag NODE_ALLOC enables the function and numa_node_id();
> when enabled it can also be explicitly controlled via a new
> node parameter
>
> Tested this with 10 Intel 82599 ports w. TYAN S7025 E5520 CPU's.
> Was able to TX/DMA ~80 Gbit/s to Ethernet wires.
>
> Cheers
> --ro
>
I cannot understand how this can help.
__netdev_alloc_skb() is supposed to already take into account NUMA
properties :
int node = dev->dev.parent ? dev_to_node(dev->dev.parent) : -1;
If this doesnt work, we should correct core stack, not only pktgen :)
Are you allocating memory in the node where pktgen CPU is running or the
node close to the NIC ?
Thanks
^ permalink raw reply
* Re: [PATCH] xfrm: cache bundle lookup results in flow cache
From: Herbert Xu @ 2010-03-19 9:32 UTC (permalink / raw)
To: Timo Teräs; +Cc: netdev
In-Reply-To: <4BA33FF5.8010104@iki.fi>
On Fri, Mar 19, 2010 at 11:12:21AM +0200, Timo Teräs wrote:
>
>> That would be better but it's still hacky. Proper reference
>> counting like we had before would be my preference.
>
> Well, the cache entry is still referenced only very shortly,
> I don't see why keeping bh disabled why doing it is considered
> a hack. Refcounting the cache entries is trickier. Though,
> it could be used to optimize the update process: we could safely
> update it instead of doing now lookup later.
Well we had a nicely type-agnostic cache which is self-contained,
but your patch is bleeding generic code into xfrm_policy.c, that's
why I felt it to be hacky :)
Anyway I see how your scheme works now as far as object life
is concerned, and I agree that it is safe.
However, I wonder if we could do it while still leaving all the
object life-cycle management stuff (and the BH disabling bits)
in flow.c
The crux of the issue is that you now have two objects to track
instead of one. As the direction is a key in the lookup, we're
really only worried about the outbound case here.
So how about going back to what I suggested earlier, and keeping
a back-pointer from xfrm_dst to the policy? Of course xfrm_dst
would also hold a ref count on the policy. You'd only have to
do it for the top-level xfrm_dst.
It does mean that you'll need to write a different resolver for
outbound vs. inbound/forward, but that makes sense because we
only use bundles for outbound policies.
What do you think?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Handling receive packets with limited buffer space
From: Amit Uttamchandani @ 2010-03-19 9:41 UTC (permalink / raw)
To: netdev
In my modified ethoc.c driver, I am using only one receive buffer
descriptor due to limited space. This works fairly well for small
packets (arp, pings, etc.).
However, doing a 'wget' and downloading a file causes lots of drops and
thus results in a terminated connection.
How do I go about dealing with this? I tried stopping the queue
(netif_stop_queue) while I'm processing the rx skb and then resuming it
once I'm done, but this did not seem to help.
Any ideas on this?
Thanks for any help.
Amit
^ permalink raw reply
* Re: [PATCH] xfrm: cache bundle lookup results in flow cache
From: Timo Teräs @ 2010-03-19 9:53 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev
In-Reply-To: <20100319093210.GA23895@gondor.apana.org.au>
Herbert Xu wrote:
> On Fri, Mar 19, 2010 at 11:12:21AM +0200, Timo Teräs wrote:
>>> That would be better but it's still hacky. Proper reference
>>> counting like we had before would be my preference.
>> Well, the cache entry is still referenced only very shortly,
>> I don't see why keeping bh disabled why doing it is considered
>> a hack. Refcounting the cache entries is trickier. Though,
>> it could be used to optimize the update process: we could safely
>> update it instead of doing now lookup later.
>
> Well we had a nicely type-agnostic cache which is self-contained,
> but your patch is bleeding generic code into xfrm_policy.c, that's
> why I felt it to be hacky :)
>
> Anyway I see how your scheme works now as far as object life
> is concerned, and I agree that it is safe.
>
> However, I wonder if we could do it while still leaving all the
> object life-cycle management stuff (and the BH disabling bits)
> in flow.c
>
> The crux of the issue is that you now have two objects to track
> instead of one. As the direction is a key in the lookup, we're
> really only worried about the outbound case here.
>
> So how about going back to what I suggested earlier, and keeping
> a back-pointer from xfrm_dst to the policy? Of course xfrm_dst
> would also hold a ref count on the policy. You'd only have to
> do it for the top-level xfrm_dst.
>
> It does mean that you'll need to write a different resolver for
> outbound vs. inbound/forward, but that makes sense because we
> only use bundles for outbound policies.
>
> What do you think?
When I first started reading the code, I got confused slightly
on how the garbage collection is happening. What I did not like
in current is the atomic_dec() in flow.c that does not check if
it was turned to zero. Because on policy objects it means you
need to delete it (which would a bug if it happened in flow.c;
the policy gc calls flush before releasing it's own reference),
but on xfrm_dst it's perfectly ok to do atomic_dec() and the
dst core will garbage collect items.
But now, thinking more, it would probably make more sense to
just cache xfrm_dst's and keep ref to the policy on them. So
in general I agree with your recommendation. The only immediate
problem I can think now is that the resolved would need to
atomically check if xfrm_dst is valid, if not, resolve new one.
But creating new xfrm_dst involves taking locks and can sleep
so it cannot be inside the main resolver.
Alternatively, we'd need to:
a) still expose flow cache entry structs and do locking or
refcounting on them
b) have two version of flow lookup: one that calls resolver
with bh disabled and can atomically lookup and update entry
and a second version that lookups, calls validation, if
not-valid it calls resolver with bh enabled and does a new
flow cache lookup to update cache
Also, relatedly. Is there way to release xfrm_dst's child and
route refs when xfrm_bundle_ok fails? This would improve GC
collection of the ipv4 rtable entries they referenced.
- Timo
^ permalink raw reply
* [PATCH net-next-2.6 0/2] can: sja1000: sja1000_platform.c fixes
From: Yegor Yefremov @ 2010-03-19 10:47 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA; +Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w
Here are two sja1000_platform.c related fixes:
SJA1000: allow shared interrupt definition
SJA1000: add read/write routines for 8, 16 and 32-bit register access
Best regards,
Yegor
^ permalink raw reply
* Re: [PATCH net-next-2.6 1/2] can: sja1000: allow shared interrupt definition
From: Yegor Yefremov @ 2010-03-19 10:49 UTC (permalink / raw)
To: netdev; +Cc: socketcan-core
In-Reply-To: <4BA3565F.6040907@visionsystems.de>
SJA1000: allow shared interrupt definition
extend the AND mask, so that IRQF_SHARED flag remains
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
diff --git a/drivers/net/can/sja1000/sja1000_platform.c b/drivers/net/can/sja1000/sja1000_platform.c
index 628374c..bec0d3d 100644
--- a/drivers/net/can/sja1000/sja1000_platform.c
+++ b/drivers/net/can/sja1000/sja1000_platform.c
@@ -90,7 +90,7 @@ static int sp_probe(struct platform_device *pdev)
priv = netdev_priv(dev);
dev->irq = res_irq->start;
- priv->irq_flags = res_irq->flags & IRQF_TRIGGER_MASK;
+ priv->irq_flags = res_irq->flags & (IRQF_TRIGGER_MASK | IRQF_SHARED);
priv->reg_base = addr;
priv->read_reg = sp_read_reg;
priv->write_reg = sp_write_reg;
^ permalink raw reply related
* Re: [PATCH net-next-2.6 2/2] can: sja1000: add read/write routines for 8, 16 and 32-bit register access
From: Yegor Yefremov @ 2010-03-19 10:50 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA; +Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w
In-Reply-To: <4BA356A4.5040205-ZJVcf1zZPRSebONBosFW4Q@public.gmane.org>
SJA1000: add read/write routines for 8, 16 and 32-bit register access
add routines for 8, 16 and 32-bit access like in
drivers/i2c/busses/i2c-pca-platform.c
Signed-off-by: Yegor Yefremov <yegorslists-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
Index: net-next-2.6/drivers/net/can/sja1000/sja1000_platform.c
===================================================================
--- net-next-2.6.orig/drivers/net/can/sja1000/sja1000_platform.c
+++ net-next-2.6/drivers/net/can/sja1000/sja1000_platform.c
@@ -37,16 +37,36 @@ MODULE_AUTHOR("Sascha Hauer <s.hauer@pen
MODULE_DESCRIPTION("Socket-CAN driver for SJA1000 on the platform bus");
MODULE_LICENSE("GPL v2");
-static u8 sp_read_reg(const struct sja1000_priv *priv, int reg)
+static u8 sp_read_reg8(const struct sja1000_priv *priv, int reg)
{
return ioread8(priv->reg_base + reg);
}
-static void sp_write_reg(const struct sja1000_priv *priv, int reg, u8 val)
+static void sp_write_reg8(const struct sja1000_priv *priv, int reg, u8 val)
{
iowrite8(val, priv->reg_base + reg);
}
+static u8 sp_read_reg16(const struct sja1000_priv *priv, int reg)
+{
+ return ioread8(priv->reg_base + reg * 2);
+}
+
+static void sp_write_reg16(const struct sja1000_priv *priv, int reg, u8 val)
+{
+ iowrite8(val, priv->reg_base + reg * 2);
+}
+
+static u8 sp_read_reg32(const struct sja1000_priv *priv, int reg)
+{
+ return ioread8(priv->reg_base + reg * 4);
+}
+
+static void sp_write_reg32(const struct sja1000_priv *priv, int reg, u8 val)
+{
+ iowrite8(val, priv->reg_base + reg * 4);
+}
+
static int sp_probe(struct platform_device *pdev)
{
int err;
@@ -92,12 +112,26 @@ static int sp_probe(struct platform_devi
dev->irq = res_irq->start;
priv->irq_flags = res_irq->flags & (IRQF_TRIGGER_MASK | IRQF_SHARED);
priv->reg_base = addr;
- priv->read_reg = sp_read_reg;
- priv->write_reg = sp_write_reg;
priv->can.clock.freq = pdata->clock;
priv->ocr = pdata->ocr;
priv->cdr = pdata->cdr;
+ switch (res_mem->flags & IORESOURCE_MEM_TYPE_MASK) {
+ case IORESOURCE_MEM_32BIT:
+ priv->read_reg = sp_read_reg32;
+ priv->write_reg = sp_write_reg32;
+ break;
+ case IORESOURCE_MEM_16BIT:
+ priv->read_reg = sp_read_reg16;
+ priv->write_reg = sp_write_reg16;
+ break;
+ case IORESOURCE_MEM_8BIT:
+ default:
+ priv->read_reg = sp_read_reg8;
+ priv->write_reg = sp_write_reg8;
+ break;
+ }
+
dev_set_drvdata(&pdev->dev, dev);
SET_NETDEV_DEV(dev, &pdev->dev);
^ permalink raw reply
* Re: Help: the 82577 network driver can't work
From: yucheng.wang @ 2010-03-19 11:10 UTC (permalink / raw)
To: Allan, Bruce W; +Cc: e1000-devel@lists.sourceforge.net, netdev@vger.kernel.org
In-Reply-To: <8DD2590731AB5D4C9DBF71A877482A90619CAAC4@orsmsx509.amr.corp.intel.com>
Allan, Bruce W wrote:
> On Wednesday, March 17, 2010 10:40 PM, yucheng.wang wrote:
>> Hi all,
>>
>> I need some help for intel 82577 network card driver, named
>> CONFIG_E1000E in the kernel config.
>>
>> In the kernel 2.6.31 and 2.6.32, the patch works well, but in the
>> kernel
>> 2.6.33 and 2.6.34-rc1 the dmesg shows some problem below,and the
>> network card can't work.
>> **********************************************************************
>> e1000e: Intel(R) PRO/1000 Network Driver - 1.0.2-k2
>> e1000e: Copyright (c) 1999 - 2009 Intel Corporation.
>> e1000e 0000:00:19.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
>> 0000:00:19.0: 0000:00:19.0: Write-protect NVM Disabled
>> 0000:00:19.0: 0000:00:19.0: Failed to initialize MSI interrupts.
>> Falling back to legacy interrupts.
>> ata4: SATA link down (SStatus 0 SControl 300)
>> ata3: SATA link down (SStatus 0 SControl 300)
>> ata2.00: SATA link down (SStatus 0 SControl 300)
>> ata2.01: SATA link down (SStatus 0 SControl 300)
>> ata1.00: SATA link down (SStatus 0 SControl 0)
>> ata1.01: SATA link down (SStatus 0 SControl 300)
>> e1000e 0000:00:19.0: PCI INT A disabled
>> e1000e: probe of 0000:00:19.0 failed with error -3
>> ********************************************************************
>> I read the source code using 2.6.34-rc-1 kernel.
>> When calling e1000e_git_phy_id(), the function returns a wrong value
>> "-3". The kernel 2.6.31 and 2.6.32 ignores this error, and the kernel
>> run well. The function e1000_acquire_swflag_ich8lan( ), called by
>> e1000e_get_phy_id(), return "-3".
>> ************************** The code
>> ********************************* extcnf_ctrl |=
>> E1000_EXTCNF_CTRL_SWFLAG; ew32(EXTCNF_CTRL, extcnf_ctrl);
>>
>> while (timeout) {
>> extcnf_ctrl = er32(EXTCNF_CTRL);
>> if (extcnf_ctrl& E1000_EXTCNF_CTRL_SWFLAG)
>> break;
>>
>> mdelay(1);
>> timeout--;
>> }
>>
>> if (!timeout) {
>> e_dbg("Failed to acquire the semaphore.\n");
>> extcnf_ctrl&= ~E1000_EXTCNF_CTRL_SWFLAG;
>> ew32(EXTCNF_CTRL, extcnf_ctrl);
>> ret_val = -E1000_ERR_CONFIG;
>> goto out;
>> }
>> ************************** The code
>> ********************************* The kernel can't set the bit
>> E1000_EXTCNF_CTRL_SWFLAG of the register EXTCNF_CTRL.
>>
>> We found the information in the 82577 user manual:
>> In the Extended Configuration Control Register.
>> Software Semaphore FLAG (SWFLAG). This bit is set by the device
>> driver to gain access permission to shared CSR registers with the
>> firmware and hardware. The bit is initialized on power up PCI reset
>> and software reset. and the default value when Reset is "0b".
>>
>> I don't know why the bit E1000_EXTCNF_CTRL_SWFLAG is not right, and
>> not find any information about writing the bit. Due to the bit
>> returns 0 when reset the controller, we wrote the patch below.
>> *****************************The
>> patch********************************** diff --git
>> a/drivers/net/e1000e/ich8lan.c b/drivers/net/e1000e/ich8lan.c index
>> 8b6ecd1..b3e20f4 100644 --- a/drivers/net/e1000e/ich8lan.c
>> +++ b/drivers/net/e1000e/ich8lan.c
>> @@ -224,6 +224,7 @@ static void
>> e1000_power_down_phy_copper_ich8lan(struct e1000_hw *hw);
>> static void e1000_lan_init_done_ich8lan(struct e1000_hw *hw);
>> static s32 e1000_k1_gig_workaround_hv(struct e1000_hw *hw, bool
>> link); static s32 e1000_set_mdio_slow_mode_hv(struct e1000_hw *hw);
>> +static s32 e1000_reset_hw_ich8lan(struct e1000_hw *hw);
>>
>> static inline u16 __er16flash(struct e1000_hw *hw, unsigned long
>> reg) {
>> @@ -276,8 +277,12 @@ static s32 e1000_init_phy_params_pchlan(struct
>> e1000_hw *hw)
>>
>> phy->id = e1000_phy_unknown;
>> ret_val = e1000e_get_phy_id(hw);
>> - if (ret_val)
>> - goto out;
>> + if (ret_val) {
>> + e1000_reset_hw_ich8lan(hw);
>> + ret_val = e1000e_get_phy_id(hw);
>> + if (ret_val)
>> + goto out;
>> + }
>> if ((phy->id == 0) || (phy->id == PHY_REVISION_MASK)) {
>> /*
>> * In case the PHY needs to be in mdio slow mode (eg.
>> 82577),
>> ****************************************************************************
>> I'm not sure it's right, but using the patch, 82577 network can work
>> well.I need more eyes about this, how can I make the patch better?
>> Any suggestion would be helped me make the patch better.
>>
>> By the way, we find 3 patches make it not well.
>>
>> From 0be8401051c716be4533272e983b7eed3d83946d Mon Sep 17 00:00:00
>> 2001 From: Bruce Allan <bruce.w.allan@intel.com>
>> Date: Wed, 2 Dec 2009 17:03:18 +0000
>> Subject: e1000e: correct ICH/PCH PHY operations function pointers
>>
>> From fddaa1aff881c98f524221236af98ce70dcd04cf Mon Sep 17 00:00:00
>> 2001
>>
>> From: Bruce Allan <bruce.w.allan@intel.com>
>> Date: Wed, 13 Jan 2010 01:52:49 +0000
>> Subject: e1000e: MDIO slow mode should always be done for 82577
>>
>> From baf86c9d36826fab0160251bbc87dfab3af48a21 Mon Sep 17 00:00:00
>> 2001
>>
>> From: Bruce Allan <bruce.w.allan@intel.com>
>> Date: Wed, 13 Jan 2010 01:53:08 +0000
>> Subject: e1000e: workaround link issues on busy hub in half duplex on
>> 82577/82578
>>
>> thanks,
>> Yucheng.Wang
>
> [Adding e1000-devel@lists.sf.net (the mailing list for Intel wired GbE drivers)]
>
> Thanks for reporting the issue. The 3 patches you list that appear to break e1000e on 82577 are necessary. The patch you suggest to resolve the issue is almost exactly the same as one we have been working on in-house here at Intel and will be pushed upstream shortly. There are still a couple unresolved issues with it however so it will be another couple days.
Thanks for giving me the info. but there are some problems I want to
understand it for the issue. Would you like to telling me why? All the
problems happens in the kenel 2.6.34-rc-1.
1. When I insmod the module e1000e, the network card can work well. But
when I build the driver in the kernel the "-3" error happens.
theoretically, there is no difference of driver between in the kernel
and modules. The problem is strange to me, so I'm interested to know who
did this?
2. If I use my patch to resolve the issue, which problem would happens
when reset the hardware of network like me to do? And the e1000e problem
is not only support 82577, so the workaround would impact other card
using e1000e, which time and when to reset the hardware is best?
3. I read the source code, and find the function "e1000_read_phy_reg_hv"
cannot return the correct value when execute "file:ich8lan.c,line:290
ret_val = e1000_set_mdio_slow_mode_hv(hw);", so which register
impact this?
4. If the patch from Intel finished, about when I can read the patch?
5. The version of e1000e is "e1000e: Intel(R) PRO/1000 Network Driver -
1.0.2-k2" in the official kernel 2.6.34-rc-1, but in the Intel's
website, the version is "1.1.2.1a", the webpage is
http://downloadcenter.intel.com/SearchResult.aspx?lang=eng&keyword=%22e1000e%22
which difference between the two version of e1000e driver? And I noticed
that in the sourceforge's maillist, the intel's e1000e driver 1.1.2.1a
has some problem when build in 2.6.34-rc-1, which I have been encountered.
I think you were crazy when you see so many questions, and cost you too
much time to answer it. But I'm still want to know the answer of these
questions. Hope you can reply me to understand the e100e network.
Thanks a lot.
yucheng.wang
>
> Thanks again,
> Bruce.
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [Bugme-new] [Bug 15507] New: kernel misses 3rd part of tcp handshake (ACK), stays in SYN_RECV state
From: Joshua Roys @ 2010-03-19 11:53 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Andrew Morton, netdev, bugzilla-daemon, bugme-daemon
In-Reply-To: <1268953951.2894.194.camel@edumazet-laptop>
On 03/18/2010 07:12 PM, Eric Dumazet wrote:
>
> I would say this is expected if httpd server set DEFER_ACCEPT socket
> option.
>
>
>
Gah! You've got to be kidding :) If that's what it is, close the
bug... and I'll go read some man-pages!
Josh
^ permalink raw reply
* Re: [PATCH] net: dev_getfirstbyhwtype() optimization
From: Paul E. McKenney @ 2010-03-19 11:54 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1268975642.2894.218.camel@edumazet-laptop>
On Fri, Mar 19, 2010 at 06:14:02AM +0100, Eric Dumazet wrote:
> Le jeudi 18 mars 2010 à 19:32 -0700, Paul E. McKenney a écrit :
> > On Thu, Mar 18, 2010 at 10:27:25PM +0100, Eric Dumazet wrote:
> > > Use RCU to avoid RTNL use in dev_getfirstbyhwtype()
> > >
> > > Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> > > ---
> > > diff --git a/net/core/dev.c b/net/core/dev.c
> > > index 17b1686..0f2e9fc 100644
> > > --- a/net/core/dev.c
> > > +++ b/net/core/dev.c
> > > @@ -772,14 +772,17 @@ EXPORT_SYMBOL(__dev_getfirstbyhwtype);
> > >
> > > struct net_device *dev_getfirstbyhwtype(struct net *net, unsigned short type)
> > > {
> > > - struct net_device *dev;
> > > + struct net_device *dev, *ret = NULL;
> > >
> > > - rtnl_lock();
> > > - dev = __dev_getfirstbyhwtype(net, type);
> > > - if (dev)
> > > - dev_hold(dev);
> > > - rtnl_unlock();
> > > - return dev;
> > > + rcu_read_lock();
> > > + for_each_netdev_rcu(net, dev)
> > > + if (dev->type == type) {
> > > + dev_hold(dev);
> > > + ret = dev;
> > > + break;
> > > + }
> > > + rcu_read_unlock();
> > > + return ret;
> >
> > Looks good, but I don't understand how it helps to introduce the
> > local variable "ret".
> >
>
> Thanks for reviewing Paul !
>
> Not only it helps, its necessary :)
>
> for_each_netdev_rcu(net, dev) {
> if (cond) {
> dev_hold(dev);
> break;
> }
> }
> makes no guarantee dev is NULL if we hit the list end :
>
>
> /**
> * list_for_each_entry_rcu - iterate over rcu list of given type
> * @pos: the type * to use as a loop cursor.
> * @head: the head for your list.
> * @member: the name of the list_struct within the struct.
> *
> * This list-traversal primitive may safely run concurrently with
> * the _rcu list-mutation primitives such as list_add_rcu()
> * as long as the traversal is guarded by rcu_read_lock().
> */
> #define list_for_each_entry_rcu(pos, head, member) \
> for (pos = list_entry_rcu((head)->next, typeof(*pos), member); \
> prefetch(pos->member.next), &pos->member != (head); \
> pos = list_entry_rcu(pos->member.next, typeof(*pos), member))
Right! Got it, thank you!
Thanx, Paul
^ permalink raw reply
* RE: [PATCH] netxen: The driver doesn't work on NX_P3_B1 so cause probe to fail.
From: Amit Salecha @ 2010-03-19 12:03 UTC (permalink / raw)
To: David Miller, ebiederm@xmission.com; +Cc: netdev@vger.kernel.org, Ameen Rahman
In-Reply-To: <20100318.222126.27823381.davem@davemloft.net>
David,
Eric's initial problem got resolved by using newer firmware (link problem).
He is facing another problem, mac address are all ff:ff:ff.
Though this problem goes away with driver reload.
We had asked for fw dump to analyze this problem in detail.
-Amit Salecha
-----Original Message-----
From: Amit Salecha
Sent: Friday, March 19, 2010 11:07 AM
To: 'David Miller'; ebiederm@xmission.com
Cc: netdev@vger.kernel.org; Ameen Rahman
Subject: RE: [PATCH] netxen: The driver doesn't work on NX_P3_B1 so cause probe to fail.
We are working on this problem, will let you know our decision by end of day.
-Thanks
-----Original Message-----
From: David Miller [mailto:davem@davemloft.net]
Sent: Friday, March 19, 2010 10:51 AM
To: ebiederm@xmission.com
Cc: Amit Salecha; netdev@vger.kernel.org; Ameen Rahman
Subject: Re: [PATCH] netxen: The driver doesn't work on NX_P3_B1 so cause probe to fail.
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Thu, 18 Mar 2010 02:43:39 -0700
> Amit Salecha <amit.salecha@qlogic.com> writes:
>
>> Sorry for all the problem you faced.
>>
>> But you shouldn't add support of device which is not supported.
>> Netxen is now owned by Qlogic. You should first contact Qlogic to solve your problem.
>> Qlogic will take needed action based on problem.
>
> I'm not adding support. I am sending a patch removing support for cards
> that do not work with the current driver and have not worked since 2.6.31.
You qlogic folks better resolve this _FAST_ or else I'll
make an executive decision about how to handle this and
I guarentee I'll make a decision that you will not like.
Thanks. :-)
^ permalink raw reply
* [net-2.6 PATCH 1/3] ixgbevf: Fix VF Stats accounting after reset
From: Jeff Kirsher @ 2010-03-19 12:59 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Greg Rose, Jeff Kirsher
From: Greg Rose <gregory.v.rose@intel.com>
The counters in the 82599 Virtual Function are not clear on read. They
accumulate to the maximum value and then roll over. They are also not
cleared when the VF executes a soft reset, so it is possible they are
non-zero when the driver loads and starts. This has all been accounted
for in the code that keeps the stats up to date but there is one case
that is not. When the PF driver is reset the counters in the VF are
all reset to zero. This adds an additional accounting overhead into
the VF driver when the PF is reset under its feet. This patch adds
additional counters that are used by the VF driver to accumulate and
save stats after a PF reset has been detected. Prior to this patch
displaying the stats in the VF after the PF has reset would show
bogus data.
Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ixgbevf/ethtool.c | 42 +++++++++++++++-------
drivers/net/ixgbevf/ixgbevf_main.c | 68 +++++++++++++++++++++++-------------
drivers/net/ixgbevf/vf.h | 6 +++
3 files changed, 78 insertions(+), 38 deletions(-)
diff --git a/drivers/net/ixgbevf/ethtool.c b/drivers/net/ixgbevf/ethtool.c
index 399be0c..6fdd651 100644
--- a/drivers/net/ixgbevf/ethtool.c
+++ b/drivers/net/ixgbevf/ethtool.c
@@ -46,22 +46,32 @@ struct ixgbe_stats {
int sizeof_stat;
int stat_offset;
int base_stat_offset;
+ int saved_reset_offset;
};
-#define IXGBEVF_STAT(m, b) sizeof(((struct ixgbevf_adapter *)0)->m), \
- offsetof(struct ixgbevf_adapter, m), \
- offsetof(struct ixgbevf_adapter, b)
+#define IXGBEVF_STAT(m, b, r) sizeof(((struct ixgbevf_adapter *)0)->m), \
+ offsetof(struct ixgbevf_adapter, m), \
+ offsetof(struct ixgbevf_adapter, b), \
+ offsetof(struct ixgbevf_adapter, r)
static struct ixgbe_stats ixgbe_gstrings_stats[] = {
- {"rx_packets", IXGBEVF_STAT(stats.vfgprc, stats.base_vfgprc)},
- {"tx_packets", IXGBEVF_STAT(stats.vfgptc, stats.base_vfgptc)},
- {"rx_bytes", IXGBEVF_STAT(stats.vfgorc, stats.base_vfgorc)},
- {"tx_bytes", IXGBEVF_STAT(stats.vfgotc, stats.base_vfgotc)},
- {"tx_busy", IXGBEVF_STAT(tx_busy, zero_base)},
- {"multicast", IXGBEVF_STAT(stats.vfmprc, stats.base_vfmprc)},
- {"rx_csum_offload_good", IXGBEVF_STAT(hw_csum_rx_good, zero_base)},
- {"rx_csum_offload_errors", IXGBEVF_STAT(hw_csum_rx_error, zero_base)},
- {"tx_csum_offload_ctxt", IXGBEVF_STAT(hw_csum_tx_good, zero_base)},
- {"rx_header_split", IXGBEVF_STAT(rx_hdr_split, zero_base)},
+ {"rx_packets", IXGBEVF_STAT(stats.vfgprc, stats.base_vfgprc,
+ stats.saved_reset_vfgprc)},
+ {"tx_packets", IXGBEVF_STAT(stats.vfgptc, stats.base_vfgptc,
+ stats.saved_reset_vfgptc)},
+ {"rx_bytes", IXGBEVF_STAT(stats.vfgorc, stats.base_vfgorc,
+ stats.saved_reset_vfgorc)},
+ {"tx_bytes", IXGBEVF_STAT(stats.vfgotc, stats.base_vfgotc,
+ stats.saved_reset_vfgotc)},
+ {"tx_busy", IXGBEVF_STAT(tx_busy, zero_base, zero_base)},
+ {"multicast", IXGBEVF_STAT(stats.vfmprc, stats.base_vfmprc,
+ stats.saved_reset_vfmprc)},
+ {"rx_csum_offload_good", IXGBEVF_STAT(hw_csum_rx_good, zero_base,
+ zero_base)},
+ {"rx_csum_offload_errors", IXGBEVF_STAT(hw_csum_rx_error, zero_base,
+ zero_base)},
+ {"tx_csum_offload_ctxt", IXGBEVF_STAT(hw_csum_tx_good, zero_base,
+ zero_base)},
+ {"rx_header_split", IXGBEVF_STAT(rx_hdr_split, zero_base, zero_base)},
};
#define IXGBE_QUEUE_STATS_LEN 0
@@ -455,10 +465,14 @@ static void ixgbevf_get_ethtool_stats(struct net_device *netdev,
ixgbe_gstrings_stats[i].stat_offset;
char *b = (char *)adapter +
ixgbe_gstrings_stats[i].base_stat_offset;
+ char *r = (char *)adapter +
+ ixgbe_gstrings_stats[i].saved_reset_offset;
data[i] = ((ixgbe_gstrings_stats[i].sizeof_stat ==
sizeof(u64)) ? *(u64 *)p : *(u32 *)p) -
((ixgbe_gstrings_stats[i].sizeof_stat ==
- sizeof(u64)) ? *(u64 *)b : *(u32 *)b);
+ sizeof(u64)) ? *(u64 *)b : *(u32 *)b) +
+ ((ixgbe_gstrings_stats[i].sizeof_stat ==
+ sizeof(u64)) ? *(u64 *)r : *(u32 *)r);
}
}
diff --git a/drivers/net/ixgbevf/ixgbevf_main.c b/drivers/net/ixgbevf/ixgbevf_main.c
index ca653c4..43927e1 100644
--- a/drivers/net/ixgbevf/ixgbevf_main.c
+++ b/drivers/net/ixgbevf/ixgbevf_main.c
@@ -1610,6 +1610,44 @@ static inline void ixgbevf_rx_desc_queue_enable(struct ixgbevf_adapter *adapter,
(adapter->rx_ring[rxr].count - 1));
}
+static void ixgbevf_save_reset_stats(struct ixgbevf_adapter *adapter)
+{
+ /* Only save pre-reset stats if there are some */
+ if (adapter->stats.vfgprc || adapter->stats.vfgptc) {
+ adapter->stats.saved_reset_vfgprc += adapter->stats.vfgprc -
+ adapter->stats.base_vfgprc;
+ adapter->stats.saved_reset_vfgptc += adapter->stats.vfgptc -
+ adapter->stats.base_vfgptc;
+ adapter->stats.saved_reset_vfgorc += adapter->stats.vfgorc -
+ adapter->stats.base_vfgorc;
+ adapter->stats.saved_reset_vfgotc += adapter->stats.vfgotc -
+ adapter->stats.base_vfgotc;
+ adapter->stats.saved_reset_vfmprc += adapter->stats.vfmprc -
+ adapter->stats.base_vfmprc;
+ }
+}
+
+static void ixgbevf_init_last_counter_stats(struct ixgbevf_adapter *adapter)
+{
+ struct ixgbe_hw *hw = &adapter->hw;
+
+ adapter->stats.last_vfgprc = IXGBE_READ_REG(hw, IXGBE_VFGPRC);
+ adapter->stats.last_vfgorc = IXGBE_READ_REG(hw, IXGBE_VFGORC_LSB);
+ adapter->stats.last_vfgorc |=
+ (((u64)(IXGBE_READ_REG(hw, IXGBE_VFGORC_MSB))) << 32);
+ adapter->stats.last_vfgptc = IXGBE_READ_REG(hw, IXGBE_VFGPTC);
+ adapter->stats.last_vfgotc = IXGBE_READ_REG(hw, IXGBE_VFGOTC_LSB);
+ adapter->stats.last_vfgotc |=
+ (((u64)(IXGBE_READ_REG(hw, IXGBE_VFGOTC_MSB))) << 32);
+ adapter->stats.last_vfmprc = IXGBE_READ_REG(hw, IXGBE_VFMPRC);
+
+ adapter->stats.base_vfgprc = adapter->stats.last_vfgprc;
+ adapter->stats.base_vfgorc = adapter->stats.last_vfgorc;
+ adapter->stats.base_vfgptc = adapter->stats.last_vfgptc;
+ adapter->stats.base_vfgotc = adapter->stats.last_vfgotc;
+ adapter->stats.base_vfmprc = adapter->stats.last_vfmprc;
+}
+
static int ixgbevf_up_complete(struct ixgbevf_adapter *adapter)
{
struct net_device *netdev = adapter->netdev;
@@ -1656,6 +1694,9 @@ static int ixgbevf_up_complete(struct ixgbevf_adapter *adapter)
/* enable transmits */
netif_tx_start_all_queues(netdev);
+ ixgbevf_save_reset_stats(adapter);
+ ixgbevf_init_last_counter_stats(adapter);
+
/* bring the link up in the watchdog, this could race with our first
* link up interrupt but shouldn't be a problem */
adapter->flags |= IXGBE_FLAG_NEED_LINK_UPDATE;
@@ -2228,27 +2269,6 @@ out:
return err;
}
-static void ixgbevf_init_last_counter_stats(struct ixgbevf_adapter *adapter)
-{
- struct ixgbe_hw *hw = &adapter->hw;
-
- adapter->stats.last_vfgprc = IXGBE_READ_REG(hw, IXGBE_VFGPRC);
- adapter->stats.last_vfgorc = IXGBE_READ_REG(hw, IXGBE_VFGORC_LSB);
- adapter->stats.last_vfgorc |=
- (((u64)(IXGBE_READ_REG(hw, IXGBE_VFGORC_MSB))) << 32);
- adapter->stats.last_vfgptc = IXGBE_READ_REG(hw, IXGBE_VFGPTC);
- adapter->stats.last_vfgotc = IXGBE_READ_REG(hw, IXGBE_VFGOTC_LSB);
- adapter->stats.last_vfgotc |=
- (((u64)(IXGBE_READ_REG(hw, IXGBE_VFGOTC_MSB))) << 32);
- adapter->stats.last_vfmprc = IXGBE_READ_REG(hw, IXGBE_VFMPRC);
-
- adapter->stats.base_vfgprc = adapter->stats.last_vfgprc;
- adapter->stats.base_vfgorc = adapter->stats.last_vfgorc;
- adapter->stats.base_vfgptc = adapter->stats.last_vfgptc;
- adapter->stats.base_vfgotc = adapter->stats.last_vfgotc;
- adapter->stats.base_vfmprc = adapter->stats.last_vfmprc;
-}
-
#define UPDATE_VF_COUNTER_32bit(reg, last_counter, counter) \
{ \
u32 current_counter = IXGBE_READ_REG(hw, reg); \
@@ -2416,9 +2436,9 @@ static void ixgbevf_watchdog_task(struct work_struct *work)
}
}
-pf_has_reset:
ixgbevf_update_stats(adapter);
+pf_has_reset:
/* Force detection of hung controller every watchdog period */
adapter->detect_tx_hung = true;
@@ -3390,8 +3410,6 @@ static int __devinit ixgbevf_probe(struct pci_dev *pdev,
/* setup the private structure */
err = ixgbevf_sw_init(adapter);
- ixgbevf_init_last_counter_stats(adapter);
-
#ifdef MAX_SKB_FRAGS
netdev->features = NETIF_F_SG |
NETIF_F_IP_CSUM |
@@ -3449,6 +3467,8 @@ static int __devinit ixgbevf_probe(struct pci_dev *pdev,
adapter->netdev_registered = true;
+ ixgbevf_init_last_counter_stats(adapter);
+
/* print the MAC address */
hw_dbg(hw, "%2.2x:%2.2x:%2.2x:%2.2x:%2.2x:%2.2x\n",
netdev->dev_addr[0],
diff --git a/drivers/net/ixgbevf/vf.h b/drivers/net/ixgbevf/vf.h
index 799600e..1f31b05 100644
--- a/drivers/net/ixgbevf/vf.h
+++ b/drivers/net/ixgbevf/vf.h
@@ -157,6 +157,12 @@ struct ixgbevf_hw_stats {
u64 vfgorc;
u64 vfgotc;
u64 vfmprc;
+
+ u64 saved_reset_vfgprc;
+ u64 saved_reset_vfgptc;
+ u64 saved_reset_vfgorc;
+ u64 saved_reset_vfgotc;
+ u64 saved_reset_vfmprc;
};
struct ixgbevf_info {
^ permalink raw reply related
* [net-2.6 PATCH 2/3] ixgbevf: Shorten up delay timer for watchdog task
From: Jeff Kirsher @ 2010-03-19 13:00 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Greg Rose, Jeff Kirsher
In-Reply-To: <20100319125950.9799.70157.stgit@localhost.localdomain>
From: Greg Rose <gregory.v.rose@intel.com>
The recovery from PF reset works better when you shorten up the delay
until the watchdog task executes.
Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ixgbevf/ixgbevf_main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ixgbevf/ixgbevf_main.c b/drivers/net/ixgbevf/ixgbevf_main.c
index 43927e1..3de93ae 100644
--- a/drivers/net/ixgbevf/ixgbevf_main.c
+++ b/drivers/net/ixgbevf/ixgbevf_main.c
@@ -965,7 +965,7 @@ static irqreturn_t ixgbevf_msix_mbx(int irq, void *data)
if ((msg & IXGBE_MBVFICR_VFREQ_MASK) == IXGBE_PF_CONTROL_MSG)
mod_timer(&adapter->watchdog_timer,
- round_jiffies(jiffies + 10));
+ round_jiffies(jiffies + 1));
return IRQ_HANDLED;
}
^ permalink raw reply related
* [net-2.6 PATCH 3/3] ixgbevf: Message formatting cleanups
From: Jeff Kirsher @ 2010-03-19 13:00 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Greg Rose, Jeff Kirsher
In-Reply-To: <20100319125950.9799.70157.stgit@localhost.localdomain>
From: Greg Rose <gregory.v.rose@intel.com>
Clean up some text output formatting.
Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ixgbevf/ixgbevf_main.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ixgbevf/ixgbevf_main.c b/drivers/net/ixgbevf/ixgbevf_main.c
index 3de93ae..d6cbd94 100644
--- a/drivers/net/ixgbevf/ixgbevf_main.c
+++ b/drivers/net/ixgbevf/ixgbevf_main.c
@@ -2419,7 +2419,7 @@ static void ixgbevf_watchdog_task(struct work_struct *work)
if (!netif_carrier_ok(netdev)) {
hw_dbg(&adapter->hw, "NIC Link is Up %s, ",
((link_speed == IXGBE_LINK_SPEED_10GB_FULL) ?
- "10 Gbps" : "1 Gbps"));
+ "10 Gbps\n" : "1 Gbps\n"));
netif_carrier_on(netdev);
netif_tx_wake_all_queues(netdev);
} else {
@@ -2695,7 +2695,7 @@ static int ixgbevf_open(struct net_device *netdev)
if (hw->adapter_stopped) {
err = IXGBE_ERR_MBX;
printk(KERN_ERR "Unable to start - perhaps the PF"
- "Driver isn't up yet\n");
+ " Driver isn't up yet\n");
goto err_setup_reset;
}
}
^ permalink raw reply related
* Re: [PATCH net-next-2.6 1/2] can: sja1000: allow shared interrupt definition
From: Wolfgang Grandegger @ 2010-03-19 13:13 UTC (permalink / raw)
To: yegor_sub1-ZJVcf1zZPRSebONBosFW4Q
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4BA356A4.5040205-ZJVcf1zZPRSebONBosFW4Q@public.gmane.org>
Yegor Yefremov wrote:
> SJA1000: allow shared interrupt definition
>
> extend the AND mask, so that IRQF_SHARED flag remains
>
> Signed-off-by: Yegor Yefremov <yegorslists-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
Acked-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
Thanks,
Wolfgang.
^ permalink raw reply
* Re: [PATCH net-next-2.6 2/2] can: sja1000: add read/write routines for 8, 16 and 32-bit register access
From: Wolfgang Grandegger @ 2010-03-19 13:14 UTC (permalink / raw)
To: yegor_sub1-ZJVcf1zZPRSebONBosFW4Q
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4BA35704.2060909-ZJVcf1zZPRSebONBosFW4Q@public.gmane.org>
Yegor Yefremov wrote:
> SJA1000: add read/write routines for 8, 16 and 32-bit register access
>
> add routines for 8, 16 and 32-bit access like in
> drivers/i2c/busses/i2c-pca-platform.c
>
> Signed-off-by: Yegor Yefremov <yegorslists-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
Acked-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
Thanks,
Wolfgang.
^ permalink raw reply
* Re: [PATCH] pktgen node allocation
From: robert @ 2010-03-19 13:35 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Robert Olsson, David Miller, netdev
In-Reply-To: <1268990933.3048.15.camel@edumazet-laptop>
Eric Dumazet writes:
> Le vendredi 19 mars 2010 à 09:44 +0100, Robert Olsson a écrit :
>
> I cannot understand how this can help.
>
> __netdev_alloc_skb() is supposed to already take into account NUMA
> properties :
>
> int node = dev->dev.parent ? dev_to_node(dev->dev.parent) : -1;
>
> If this doesnt work, we should correct core stack, not only pktgen :)
>
> Are you allocating memory in the node where pktgen CPU is running or the
> node close to the NIC ?
I didn't say it should help the idea was to give some hooks to
experiment and see effects with different node memory allocations.
There are many degrees of freedom wrt buses(device)/CPU/menory.
Cheers
--ro
^ permalink raw reply
* Re: [Bugme-new] [Bug 15507] New: kernel misses 3rd part of tcp handshake (ACK), stays in SYN_RECV state
From: Eric Dumazet @ 2010-03-19 13:42 UTC (permalink / raw)
To: Joshua Roys; +Cc: Andrew Morton, netdev, bugzilla-daemon, bugme-daemon
In-Reply-To: <4BA365BA.4040309@gmail.com>
Le vendredi 19 mars 2010 à 07:53 -0400, Joshua Roys a écrit :
> On 03/18/2010 07:12 PM, Eric Dumazet wrote:
> >
> > I would say this is expected if httpd server set DEFER_ACCEPT socket
> > option.
> >
> >
> >
>
> Gah! You've got to be kidding :) If that's what it is, close the
> bug... and I'll go read some man-pages!
>
So you _confirm_ DEFER_ACCEPT is not used, its _important_ for us.
I dont believe my comment was trivial at all :)
I gave a hint to myself and other network guys, because we did some
changes in this area lately (commit b103cf34 tcp: fix TCP_DEFER_ACCEPT
retrans calculation) from Julian Anastasov.
git describe b103cf34
v2.6.31-9056-gb103cf3
Please boot a fresh vm, then try exactly 10 'bad connects', please make
each attempt last at least 2 minutes. (you can start all these in
parallel)
And report :
netstat -s
(My FC12 copy doesnt exhibit this problem)
Thanks
^ permalink raw reply
* Re: [PATCH] pktgen node allocation
From: Eric Dumazet @ 2010-03-19 13:47 UTC (permalink / raw)
To: robert; +Cc: David Miller, netdev
In-Reply-To: <19363.32154.39665.185451@gargle.gargle.HOWL>
Le vendredi 19 mars 2010 à 14:35 +0100, robert@herjulf.net a écrit :
> Eric Dumazet writes:
> > Le vendredi 19 mars 2010 à 09:44 +0100, Robert Olsson a écrit :
> >
> > I cannot understand how this can help.
> >
> > __netdev_alloc_skb() is supposed to already take into account NUMA
> > properties :
> >
> > int node = dev->dev.parent ? dev_to_node(dev->dev.parent) : -1;
> >
> > If this doesnt work, we should correct core stack, not only pktgen :)
> >
> > Are you allocating memory in the node where pktgen CPU is running or the
> > node close to the NIC ?
>
> I didn't say it should help the idea was to give some hooks to
> experiment and see effects with different node memory allocations.
> There are many degrees of freedom wrt buses(device)/CPU/menory.
>
Well, you said "Tested this with 10 Intel 82599 ports w. TYAN S7025
E5520 CPU's. Was able to TX/DMA ~80 Gbit/s to Ethernet wires."
I am interested to know what particular setup you did to maximize
throughput then, or are you saing you managed to reduce it ? :)
^ permalink raw reply
* [net-next-2.6 PATCH] bonding: flush unicast and multicast lists when changing type
From: Jiri Pirko @ 2010-03-19 14:00 UTC (permalink / raw)
To: netdev; +Cc: fubar, bonding-devel, davem
After the type change, addresses in unicast and multicast lists wouldn't make
sense, not to mention possible different lenghts. So flush both lists here.
Note "dev_addr_discard" will be very soon replaced by "dev_mc_flush" (once
mc_list conversion will be done).
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
---
drivers/net/bonding/bond_main.c | 4 ++++
include/linux/netdevice.h | 2 ++
net/core/dev.c | 6 ++++--
3 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index cbe9e35..c2aceaa 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1490,6 +1490,10 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
goto err_undo_flags;
}
+ /* Flush unicast and multicast addresses */
+ dev_unicast_flush(bond_dev);
+ dev_addr_discard(bond_dev);
+
if (slave_dev->type != ARPHRD_ETHER)
bond_setup_by_slave(bond_dev, slave_dev);
else
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 813bed7..3cff4ba 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1994,10 +1994,12 @@ extern int dev_unicast_delete(struct net_device *dev, void *addr);
extern int dev_unicast_add(struct net_device *dev, void *addr);
extern int dev_unicast_sync(struct net_device *to, struct net_device *from);
extern void dev_unicast_unsync(struct net_device *to, struct net_device *from);
+extern void dev_unicast_flush(struct net_device *dev);
extern int dev_mc_delete(struct net_device *dev, void *addr, int alen, int all);
extern int dev_mc_add(struct net_device *dev, void *addr, int alen, int newonly);
extern int dev_mc_sync(struct net_device *to, struct net_device *from);
extern void dev_mc_unsync(struct net_device *to, struct net_device *from);
+extern void dev_addr_discard(struct net_device *dev);
extern int __dev_addr_delete(struct dev_addr_list **list, int *count, void *addr, int alen, int all);
extern int __dev_addr_add(struct dev_addr_list **list, int *count, void *addr, int alen, int newonly);
extern int __dev_addr_sync(struct dev_addr_list **to, int *to_count, struct dev_addr_list **from, int *from_count);
diff --git a/net/core/dev.c b/net/core/dev.c
index d1f027c..80a0608 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4455,12 +4455,13 @@ void dev_unicast_unsync(struct net_device *to, struct net_device *from)
}
EXPORT_SYMBOL(dev_unicast_unsync);
-static void dev_unicast_flush(struct net_device *dev)
+void dev_unicast_flush(struct net_device *dev)
{
netif_addr_lock_bh(dev);
__hw_addr_flush(&dev->uc);
netif_addr_unlock_bh(dev);
}
+EXPORT_SYMBOL(dev_unicast_flush);
static void dev_unicast_init(struct net_device *dev)
{
@@ -4482,7 +4483,7 @@ static void __dev_addr_discard(struct dev_addr_list **list)
}
}
-static void dev_addr_discard(struct net_device *dev)
+void dev_addr_discard(struct net_device *dev)
{
netif_addr_lock_bh(dev);
@@ -4491,6 +4492,7 @@ static void dev_addr_discard(struct net_device *dev)
netif_addr_unlock_bh(dev);
}
+EXPORT_SYMBOL(dev_addr_discard);
/**
* dev_get_flags - get flags reported to userspace
--
1.6.6.1
^ permalink raw reply related
* [net-2.6 PATCH] ixgbe: fix for real_num_tx_queues update issue
From: Jeff Kirsher @ 2010-03-19 14:33 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Vasu Dev, Jeff Kirsher
From: Vasu Dev <vasu.dev@intel.com>
Currently netdev_features_change is called before fcoe tx queues
setup is done, so this patch moves calling of netdev_features_change
after tx queues setup is done in ixgbe_init_interrupt_scheme, so
that real_num_tx_queues is updated correctly on each fcoe enable
or disable.
This allows additional fcoe queues updated correctly in vlan driver
for their correct queue selection.
Signed-off-by: Vasu Dev <vasu.dev@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ixgbe/ixgbe_fcoe.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_fcoe.c b/drivers/net/ixgbe/ixgbe_fcoe.c
index 4123dec..700cfc0 100644
--- a/drivers/net/ixgbe/ixgbe_fcoe.c
+++ b/drivers/net/ixgbe/ixgbe_fcoe.c
@@ -614,9 +614,9 @@ int ixgbe_fcoe_enable(struct net_device *netdev)
netdev->vlan_features |= NETIF_F_FSO;
netdev->vlan_features |= NETIF_F_FCOE_MTU;
netdev->fcoe_ddp_xid = IXGBE_FCOE_DDP_MAX - 1;
- netdev_features_change(netdev);
ixgbe_init_interrupt_scheme(adapter);
+ netdev_features_change(netdev);
if (netif_running(netdev))
netdev->netdev_ops->ndo_open(netdev);
@@ -660,11 +660,11 @@ int ixgbe_fcoe_disable(struct net_device *netdev)
netdev->vlan_features &= ~NETIF_F_FSO;
netdev->vlan_features &= ~NETIF_F_FCOE_MTU;
netdev->fcoe_ddp_xid = 0;
- netdev_features_change(netdev);
ixgbe_cleanup_fcoe(adapter);
-
ixgbe_init_interrupt_scheme(adapter);
+ netdev_features_change(netdev);
+
if (netif_running(netdev))
netdev->netdev_ops->ndo_open(netdev);
rc = 0;
^ permalink raw reply related
* [PATCH] net: Don't drop route cache entry in ipv4_negative_advice unless PTMU expired
From: Guenter Roeck @ 2010-03-19 14:41 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Al Viro, Denis V. Lunev, Guenter Roeck
TCP sessions over IPv4 can get stuck if routers between endpoints
do not fragment packets but implement PMTU instead.
Setup is as follows
MTU1 MTU2 MTU1
A--------B------C------D
with MTU1 > MTU2. A and D are endpoints, B and C are routers. B and C
implement PMTU and drop packets larger than MTU2 (for example because
DF is set on all packets). TCP sessions are initiated between A and D.
There is packet loss between A and D, causing frequent TCP retransmits.
After the number of retransmits on a TCP session reaches tcp_retries1,
tcp calls dst_negative_advice() prior to each retransmit. This results
in route cache entries for the peer to be deleted in ipv4_negative_advice()
if the Path MTU is set.
If the outstanding data on an affected TCP session is larger than MTU2, packets
sent from the endpoints will be dropped by B or C, and ICMP NEEDFRAG will be
returned. A and D receive NEEDFRAG messages and update PMTU.
Before the next retransmit, tcp will again call dst_negative_advice(), causing
the route cache entry (with correct PMTU) to be deleted. The retransmitted
packet will be larger than MTU2, causing it to be dropped again.
This sequence repeats until the TCP session aborts or is terminated.
Problem is fixed by removing route cache entries in ipv4_negative_advice()
only if the PMTU is expired.
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
---
net/ipv4/route.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index d9b4024..7e1c9e4 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1512,7 +1512,8 @@ static struct dst_entry *ipv4_negative_advice(struct dst_entry *dst)
ip_rt_put(rt);
ret = NULL;
} else if ((rt->rt_flags & RTCF_REDIRECTED) ||
- rt->u.dst.expires) {
+ (rt->u.dst.expires &&
+ time_after_eq(jiffies, rt->u.dst.expires))) {
unsigned hash = rt_hash(rt->fl.fl4_dst, rt->fl.fl4_src,
rt->fl.oif,
rt_genid(dev_net(dst->dev)));
--
1.6.0.4
^ permalink raw reply related
* [net-2.6 PATCH] ixgbe: Set IXGBE_RSC_CB(skb)->DMA field to zero after unmapping the address
From: Jeff Kirsher @ 2010-03-19 14:41 UTC (permalink / raw)
To: davem
Cc: netdev, gospo, Mallikarjuna R Chilakala, Peter P Waskiewicz Jr,
Jeff Kirsher
From: Mallikarjuna R Chilakala <mallikarjuna.chilakala@intel.com>
As per Simon Horman's feedback set IXGBE_RSC_CB(skb)->dma to zero
after unmapping HWRSC DMA address to avoid double freeing.
Signed-off-by: Mallikarjuna R Chilakala <mallikarjuna.chilakala@intel.com>
Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ixgbe/ixgbe_main.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
index 18b5b21..d75c46f 100644
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -935,10 +935,12 @@ static bool ixgbe_clean_rx_irq(struct ixgbe_q_vector *q_vector,
if (skb->prev)
skb = ixgbe_transform_rsc_queue(skb, &(rx_ring->rsc_count));
if (adapter->flags2 & IXGBE_FLAG2_RSC_ENABLED) {
- if (IXGBE_RSC_CB(skb)->dma)
+ if (IXGBE_RSC_CB(skb)->dma) {
pci_unmap_single(pdev, IXGBE_RSC_CB(skb)->dma,
rx_ring->rx_buf_len,
PCI_DMA_FROMDEVICE);
+ IXGBE_RSC_CB(skb)->dma = 0;
+ }
if (rx_ring->flags & IXGBE_RING_RX_PS_ENABLED)
rx_ring->rsc_count += skb_shinfo(skb)->nr_frags;
else
@@ -3126,10 +3128,12 @@ static void ixgbe_clean_rx_ring(struct ixgbe_adapter *adapter,
rx_buffer_info->skb = NULL;
do {
struct sk_buff *this = skb;
- if (IXGBE_RSC_CB(this)->dma)
+ if (IXGBE_RSC_CB(this)->dma) {
pci_unmap_single(pdev, IXGBE_RSC_CB(this)->dma,
rx_ring->rx_buf_len,
PCI_DMA_FROMDEVICE);
+ IXGBE_RSC_CB(this)->dma = 0;
+ }
skb = skb->prev;
dev_kfree_skb(this);
} while (skb);
^ permalink raw reply related
* [PATCH] net: rtnetlink: ignore NETDEV_PRE_TYPE_CHANGE in rtnetlink_event()
From: Patrick McHardy @ 2010-03-19 14:42 UTC (permalink / raw)
To: David Miller; +Cc: jpirko, Linux Netdev List
[-- Attachment #1: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: 01.diff --]
[-- Type: text/x-diff, Size: 1560 bytes --]
Ignore the new NETDEV_PRE_TYPE_CHANGE event in rtnetlink_event() since
there have been no changes userspace needs to be notified of.
Also add a comment to the netdev notifier event definitions to remind
people to update the exclusion list when adding new event types.
Signed-off-by: Patrick McHardy <kaber@trash.net>
---
include/linux/notifier.h | 5 ++++-
net/core/rtnetlink.c | 1 +
2 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/include/linux/notifier.h b/include/linux/notifier.h
index f3635fc..9c5d3fa 100644
--- a/include/linux/notifier.h
+++ b/include/linux/notifier.h
@@ -182,7 +182,10 @@ static inline int notifier_to_errno(int ret)
* VC switch chains (for loadable kernel svgalib VC switch helpers) etc...
*/
-/* netdevice notifier chain */
+/* netdevice notifier chain. Please remember to update the rtnetlink
+ * notification exclusion list in rtnetlink_event() when adding new
+ * types.
+ */
#define NETDEV_UP 0x0001 /* For now you can't veto a device up/down */
#define NETDEV_DOWN 0x0002
#define NETDEV_REBOOT 0x0003 /* Tell a protocol stack a network interface
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index e1121f0..ffc6cf3 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -1513,6 +1513,7 @@ static int rtnetlink_event(struct notifier_block *this, unsigned long event, voi
case NETDEV_POST_INIT:
case NETDEV_REGISTER:
case NETDEV_CHANGE:
+ case NETDEV_PRE_TYPE_CHANGE:
case NETDEV_GOING_DOWN:
case NETDEV_UNREGISTER:
case NETDEV_UNREGISTER_BATCH:
--
1.6.5.7
^ permalink raw reply related
* Re: [Bugme-new] [Bug 15507] New: kernel misses 3rd part of tcp handshake (ACK), stays in SYN_RECV state
From: Eric Dumazet @ 2010-03-19 14:46 UTC (permalink / raw)
To: Joshua Roys; +Cc: Andrew Morton, netdev, bugzilla-daemon, bugme-daemon
In-Reply-To: <4BA365BA.4040309@gmail.com>
Le vendredi 19 mars 2010 à 07:53 -0400, Joshua Roys a écrit :
>
> Gah! You've got to be kidding :) If that's what it is, close the
> bug... and I'll go read some man-pages!
So I checked FC12 httpd and yes, it does use DEFER_ACCEPT (setting val
to 1 second).
So you hit a problem that was corrected by following commit.
Time to bug RedHat I suppose...
commit d1b99ba41d6c5aa1ed2fc634323449dd656899e9
Author: Julian Anastasov <ja@ssi.bg>
Date: Mon Oct 19 10:01:56 2009 +0000
tcp: accept socket after TCP_DEFER_ACCEPT period
Willy Tarreau and many other folks in recent years
were concerned what happens when the TCP_DEFER_ACCEPT period
expires for clients which sent ACK packet. They prefer clients
that actively resend ACK on our SYN-ACK retransmissions to be
converted from open requests to sockets and queued to the
listener for accepting after the deferring period is finished.
Then application server can decide to wait longer for data
or to properly terminate the connection with FIN if read()
returns EAGAIN which is an indication for accepting after
the deferring period. This change still can have side effects
for applications that expect always to see data on the accepted
socket. Others can be prepared to work in both modes (with or
without TCP_DEFER_ACCEPT period) and their data processing can
ignore the read=EAGAIN notification and to allocate resources for
clients which proved to have no data to send during the deferring
period. OTOH, servers that use TCP_DEFER_ACCEPT=1 as flag (not
as a timeout) to wait for data will notice clients that didn't
send data for 3 seconds but that still resend ACKs.
Thanks to Willy Tarreau for the initial idea and to
Eric Dumazet for the review and testing the change.
Signed-off-by: Julian Anastasov <ja@ssi.bg>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
diff --git a/net/ipv4/tcp_minisocks.c b/net/ipv4/tcp_minisocks.c
index 624c3c9..4c03598 100644
--- a/net/ipv4/tcp_minisocks.c
+++ b/net/ipv4/tcp_minisocks.c
@@ -641,8 +641,8 @@ struct sock *tcp_check_req(struct sock *sk, struct sk_buff *skb,
if (!(flg & TCP_FLAG_ACK))
return NULL;
- /* If TCP_DEFER_ACCEPT is set, drop bare ACK. */
- if (inet_csk(sk)->icsk_accept_queue.rskq_defer_accept &&
+ /* While TCP_DEFER_ACCEPT is active, drop bare ACK. */
+ if (req->retrans < inet_csk(sk)->icsk_accept_queue.rskq_defer_accept &&
TCP_SKB_CB(skb)->end_seq == tcp_rsk(req)->rcv_isn + 1) {
inet_rsk(req)->acked = 1;
return NULL;
^ 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