Netdev List
 help / color / mirror / Atom feed
* Re: [PATCH v3] ipv4: Early TCP socket demux.
From: Julian Anastasov @ 2012-06-20 21:10 UTC (permalink / raw)
  To: David Miller; +Cc: netdev
In-Reply-To: <20120620.023002.243497856926894946.davem@davemloft.net>


	Hello,

On Wed, 20 Jun 2012, David Miller wrote:

> > Date: Wed, 20 Jun 2012 10:00:37 +0300 (EEST)
> > 
> >> 			if (skb->dev != dst->dev)
> >> 				dst = NULL;
> > 
> > That makes the most sense.
> 
> Doesn't work, dst->dev is &net->loopback_dev for these locally
> destined input routes.

	I see, correct.

> We have to instead check rt->rt_iif or similar.

	Yes, rt_iif should be valid for packets with
skb->dst = NULL. It is incorrect only on loopback
traffic diverted to "lo", i.e. when skb->dst != NULL.
But it concerns UDP which is not handled by GRO yet.

	When UDP support for GRO is implemented
dev_gro_receive() should additionally check skb_dst
to ignore local copy of b-m/cast traffic sent via
ip_mc_output -> ip_dev_loopback_xmit because
in this case dst->dev and skb->dst can be eth0
where NETIF_F_GRO can be set.

Regards

--
Julian Anastasov <ja@ssi.bg>

^ permalink raw reply

* Re: [patch net-next 0/2] team: two RCU fixups
From: David Miller @ 2012-06-20 21:05 UTC (permalink / raw)
  To: jpirko; +Cc: netdev, eric.dumazet, jbrouer, paulmck, wfg
In-Reply-To: <1340206321-5986-1-git-send-email-jpirko@redhat.com>

From: Jiri Pirko <jpirko@redhat.com>
Date: Wed, 20 Jun 2012 17:31:59 +0200

> Jiri Pirko (2):
>   team: use rcu_access_pointer to access RCU pointer by writer
>   team: use RCU_INIT_POINTER for NULL assignment of RCU pointer

Applied, but this makes your subsequent patch not apply.

^ permalink raw reply

* Re: [PATCH v2] ipv4: Early TCP socket demux.
From: Eric Dumazet @ 2012-06-20 21:17 UTC (permalink / raw)
  To: Stephen Hemminger; +Cc: David Miller, bhutchings, netdev
In-Reply-To: <20120620140454.36847c65@s6510.linuxnetplumber.net>

On Wed, 2012-06-20 at 14:04 -0700, Stephen Hemminger wrote:
> On Wed, 20 Jun 2012 14:01:21 -0700 (PDT)
> David Miller <davem@davemloft.net> wrote:
> 
> > From: Eric Dumazet <eric.dumazet@gmail.com>
> > Date: Wed, 20 Jun 2012 20:40:04 +0200
> > 
> > > If someone wants to tune its linux router, he probably already disables
> > > GRO because of various issues with too big packets.
> > > 
> > > GRO adds a significant cost to forwarding path.
> > 
> > No, Ben is right Eric.  GRO decreases the costs, because it means we
> > only need to make one forwarding/netfilter/classification decision for
> > N packets instead of 1.
> 
> GRO is also important for routers that interact with VM's.
> It helps reduce the per-packet wakeup of the guest VM's.

I spoke of mere routers, I was _not_ saying GRO is useless.

In most routers setups I used, I had to disable GRO, because 64Kbytes
packets on output path broke the tc setups (SFQ)

netfilter cost was hardly a problem, once correctly done.

^ permalink raw reply

* Re: [patch net-next 0/2] team: two RCU fixups
From: Eric Dumazet @ 2012-06-20 21:19 UTC (permalink / raw)
  To: David Miller; +Cc: jpirko, netdev, jbrouer, paulmck, wfg
In-Reply-To: <20120620.140516.2004640533824596305.davem@davemloft.net>

On Wed, 2012-06-20 at 14:05 -0700, David Miller wrote:
> From: Jiri Pirko <jpirko@redhat.com>
> Date: Wed, 20 Jun 2012 17:31:59 +0200
> 
> > Jiri Pirko (2):
> >   team: use rcu_access_pointer to access RCU pointer by writer
> >   team: use RCU_INIT_POINTER for NULL assignment of RCU pointer
> 
> Applied, but this makes your subsequent patch not apply.

I reviewed them and spotted problems, and you applied them...

Then Jiri sent an update.

^ permalink raw reply

* Re: [PATCH v2] ipv4: Early TCP socket demux.
From: David Miller @ 2012-06-20 21:26 UTC (permalink / raw)
  To: eric.dumazet; +Cc: shemminger, bhutchings, netdev
In-Reply-To: <1340227076.4604.1905.camel@edumazet-glaptop>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 20 Jun 2012 23:17:56 +0200

> In most routers setups I used, I had to disable GRO, because 64Kbytes
> packets on output path broke the tc setups (SFQ)

Then you speak of bugs and mis-features, rather than real fundamental
disadvantages of using GRO on a router :-)

> netfilter cost was hardly a problem, once correctly done.

But cost is not zero, and if you can divide it by N then you do it.
And GRO is what allows this.

Every demux, lookup, etc. is transaction cost.

Even routing cache lookup with no dst reference, which is _very_
cheap, takes up a serious amount of cpu cycles.  Enough that we think
early demux is worth it, right?

And such a routing cache lookup is significantly cheaper than a trip
down into netfilter.

^ permalink raw reply

* Re: [patch net-next 0/2] team: two RCU fixups
From: David Miller @ 2012-06-20 21:27 UTC (permalink / raw)
  To: eric.dumazet; +Cc: jpirko, netdev, jbrouer, paulmck, wfg
In-Reply-To: <1340227176.4604.1913.camel@edumazet-glaptop>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 20 Jun 2012 23:19:36 +0200

> On Wed, 2012-06-20 at 14:05 -0700, David Miller wrote:
>> From: Jiri Pirko <jpirko@redhat.com>
>> Date: Wed, 20 Jun 2012 17:31:59 +0200
>> 
>> > Jiri Pirko (2):
>> >   team: use rcu_access_pointer to access RCU pointer by writer
>> >   team: use RCU_INIT_POINTER for NULL assignment of RCU pointer
>> 
>> Applied, but this makes your subsequent patch not apply.
> 
> I reviewed them and spotted problems, and you applied them...
> 
> Then Jiri sent an update.

Sorry, I'll fix this up.

^ permalink raw reply

* Re: [PATCH net-next] inetpeer: inetpeer_invalidate_tree() cleanup
From: David Miller @ 2012-06-20 21:39 UTC (permalink / raw)
  To: eric.dumazet; +Cc: netdev, steffen.klassert
In-Reply-To: <1340200930.4604.1028.camel@edumazet-glaptop>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 20 Jun 2012 16:02:10 +0200

> From: Eric Dumazet <edumazet@google.com>
> 
> No need to use cmpxchg() in inetpeer_invalidate_tree() since we hold
> base lock.
> 
> Also use correct rcu annotations to remove sparse errors
> (CONFIG_SPARSE_RCU_POINTER=y)
> 
> net/ipv4/inetpeer.c:144:19: error: incompatible types in comparison
> expression (different address spaces)
> net/ipv4/inetpeer.c:149:20: error: incompatible types in comparison
> expression (different address spaces)
> net/ipv4/inetpeer.c:595:10: error: incompatible types in comparison
> expression (different address spaces)
> 
> 
> Signed-off-by: Eric Dumazet <edumazet@google.com>

Applied, thanks Eric.

^ permalink raw reply

* Re: [net 0/3][pull request] Intel Wired LAN Driver Updates
From: David Miller @ 2012-06-20 22:09 UTC (permalink / raw)
  To: jeffrey.t.kirsher; +Cc: netdev, gospo, sassmann
In-Reply-To: <1340181882-16333-1-git-send-email-jeffrey.t.kirsher@intel.com>

From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 20 Jun 2012 01:44:39 -0700

> This series contains fixes to igb, ixgbe and intel/Kconfig
> 
> The following are changes since commit 2c995ff892313009e336ecc8ec3411022f5b1c39:
>   batman-adv: fix skb->data assignment
> and are available in the git repository at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net master
> 
> Alexander Duyck (1):
>   ixgbe: Fix memory leak in ixgbe when receiving traffic on DDP enabled
>     rings
> 
> Carolyn Wyborny (2):
>   igb: Fix incorrect RAR address entries for i210/i211 device.
>   Kconfig: Fix Kconfig for Intel ixgbe and igb PTP support.

Pulled, thanks Jeff.

^ permalink raw reply

* [PATCH] r8169: RxConfig hack for the 8168evl.
From: Francois Romieu @ 2012-06-20 22:09 UTC (permalink / raw)
  To: Hayes Wang; +Cc: netdev, thomas.pi

The 8168evl (RTL_GIGA_MAC_VER_34) based Gigabyte GA-990FXA motherboards
are very prone to NETDEV watchdog problems without this change. See
https://bugzilla.kernel.org/show_bug.cgi?id=42899 for instance.

I don't know why it *works*. It's depressingly effective though.

For the record:
- the problem may go along IOMMU (AMD-Vi) errors but it really looks
  like a red herring.
- the patch sets the RX_MULTI_EN bit. If the 8168c doc is any guide,
  the chipset now fetches several Rx descriptors at a time.
- long ago the driver ignored the RX_MULTI_EN bit.
  e542a2269f232d61270ceddd42b73a4348dee2bb changed the RxConfig
  settings. Whatever the problem it's now labeled a regression.
- Realtek's own driver can identify two different 8168evl devices
  (CFG_METHOD_16 and CFG_METHOD_17) where the r8169 driver only
  sees one. It sucks.

Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
---

 Hayes, any hindsight ?

 drivers/net/ethernet/realtek/r8169.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 7260aa7..d7a04e0 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -3894,6 +3894,7 @@ static void rtl_init_rxcfg(struct rtl8169_private *tp)
 	case RTL_GIGA_MAC_VER_22:
 	case RTL_GIGA_MAC_VER_23:
 	case RTL_GIGA_MAC_VER_24:
+	case RTL_GIGA_MAC_VER_34:
 		RTL_W32(RxConfig, RX128_INT_EN | RX_MULTI_EN | RX_DMA_BURST);
 		break;
 	default:
-- 
1.7.10.2

^ permalink raw reply related

* Re: divide by 0 error in igbvf_set_coalesce - ab50a2a
From: David Ahern @ 2012-06-20 22:21 UTC (permalink / raw)
  To: Williams, Mitch A; +Cc: netdev@vger.kernel.org
In-Reply-To: <AAEA33E297BCAC4B9BB20A7C2DF0AB8D15B30910@FMSMSX107.amr.corp.intel.com>



On 6/18/12 2:45 PM, Williams, Mitch A wrote:
> Thanks for letting me know, David. I'll look into it and get a patch out soon. Shouldn't be that big of a deal to fix.

Could you CC me on the patch so I know when it's fixed? I have enough 
events to poll.

>
> In the meantime, my advice to you is, "Don't do that."

Uh, yea. Figured that part out. ;-)

Thanks,
David

^ permalink raw reply

* Re: [net-next 0/9][pull request] Intel Wired LAN Driver Updates
From: David Miller @ 2012-06-20 22:26 UTC (permalink / raw)
  To: jeffrey.t.kirsher; +Cc: netdev, gospo, sassmann
In-Reply-To: <1340181903-16382-1-git-send-email-jeffrey.t.kirsher@intel.com>

From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 20 Jun 2012 01:44:54 -0700

> This series contains updates to e1000, igb and ixgbe
> 
> The following are changes since commit 41063e9dd11956f2d285e12e4342e1d232ba0ea2:
>   ipv4: Early TCP socket demux.
> and are available in the git repository at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next master

Pulled, thanks Jeff.

^ permalink raw reply

* Re: [PATCH v2] ipv4: Early TCP socket demux.
From: David Miller @ 2012-06-20 22:29 UTC (permalink / raw)
  To: eric.dumazet; +Cc: shemminger, netdev
In-Reply-To: <1340195920.4604.918.camel@edumazet-glaptop>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 20 Jun 2012 14:38:40 +0200

> Problem could happen if sk->sk_rx_dst is freed while some packets are
> still in napi or socket backlog (can happen with some network
> reordering)
> 
> 1) Socket backlog must be flushed before sk->sk_rx_dst freeing
> 
> 2) Even if we move rcu_read_lock() in net_rx_action(), we need some
> napi_gro_forcedstrefs() in case we sofnet_break
> 
> Or maybe just use napi_gro_flush() ?

Good catch, but I've just figured out a more fundamental issue
with doing this at the GRO layer.

The IPV4 input path is going to undo our early socket demux by
orphaning the SKB in ip_rcv().  So we'll end up looking up the
socket twice.

^ permalink raw reply

* RE: [PATCH net-next 2/6] bnx2x: link cleanup
From: Joe Perches @ 2012-06-20 22:41 UTC (permalink / raw)
  To: Yuval Mintz
  Cc: davem@davemloft.net, netdev@vger.kernel.org, Eilon Greenstein,
	Yaniv Rosner
In-Reply-To: <979A8436335E3744ADCD3A9F2A2B68A5029F62@SJEXCHMB10.corp.ad.broadcom.com>

On Wed, 2012-06-20 at 17:50 +0000, Yuval Mintz wrote:
> > >  3. Change msleep(1) --> usleep_range(1000, 1000)
> > 
> > I believe replacing msleep(small) with
> > usleep_range(small * 1000, small * 1000) is
> > not generally a good idea.
> > 
> > Please give usleep_range an actual range to
> > work with and not a repeated single value.
> > 
> > Please think a little more about what a
> > good upper range for the maximum time to
> > sleep should be.
> > 
> > usleep_range(small * 1000, small * 2000)
> > or something similar maybe.
> >
> 
> Sounds good.  I'll change it and re-send the patch series.

Hi Yuval.

Here's a little script from awhile ago that
does it by doubling the small value as the
high value range bound.

http://kerneltrap.org/mailarchive/linux-netdev/2010/12/2/6290711

(replace [path] as appropriate)

$ grep -nPrl --include=*.[ch] "msleep\s*\(\s*1?\d\s*\)" [path] \
  xargs perl -p -i -e 's/msleep\s*\(\s*(1?\d)\s*\)/"usleep_range\(${1}000, " . scalar($1) * 2 . "000\)"/ge'

^ permalink raw reply

* accept_ra_rt_info_max_plen default value
From: Jiri Bohac @ 2012-06-20 23:07 UTC (permalink / raw)
  To: yoshfuji; +Cc: Teran McKinney, Pekka Savola, David Miller, netdev

Hi,

I have been looking for the reason behind the default of
accept_ra_rt_info_max_plen being 0. No luck.

The feature has been introduced by 930d6ff2 ([IPV6]: ROUTE: Add
accept_ra_rt_info_max_plen sysctl).

The only relevant discussion I found was
http://markmail.org/message/5m34bfzhox6y5lcf
with no explanation.

I imagine that the motivation for setting
accept_ra_rt_info_max_plen to 0 would be security concerns (?).

However, RFC 4191, section "6. Security Consideration", concludes
that the new features don't increase the risks already present:

	A malicious node could send Router Advertisement messages, specifying
	a High Default Router Preference or carrying specific routes, with
	the effect of pulling traffic away from legitimate routers.  However,
	a malicious node could easily achieve this same effect in other ways.

	For example, it could fabricate Router Advertisement messages with a
	zero Router Lifetime from the other routers, causing hosts to stop
	using the other routes.  By advertising a specific prefix, this
	attack could be carried out in a less noticeable way.  However, this
	attack has no significant incremental impact on Internet
	infrastructure security.


RFC 6434 has been published since, and under 5.3. it says:

	Small Office/Home Office (SOHO) deployments supported by routers
	adhering to [RFC6204] use RFC 4191 to advertise routes to certain
	local destinations.  Consequently, nodes that will be deployed in
	SOHO environments SHOULD implement RFC 4191.


Shouldn't the default value of accept_ra_rt_info_max_plen be
re-considered to comply with RFC 6434 by default? Any reason not
to make it 128?

Thanks,

-- 
Jiri Bohac <jbohac@suse.cz>
SUSE Labs, SUSE CZ

^ permalink raw reply

* [PATCH 2/3 net-next] tg3: Add APE scratchpad read and write functions.
From: Michael Chan @ 2012-06-21  0:06 UTC (permalink / raw)
  To: davem; +Cc: netdev, nsujir, mcarlson
In-Reply-To: <1340237192-30052-1-git-send-email-mchan@broadcom.com>

From: Matt Carlson <mcarlson@broadcom.com>

Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
---
 drivers/net/ethernet/broadcom/tg3.c |  137 +++++++++++++++++++++++++++++++++++
 drivers/net/ethernet/broadcom/tg3.h |   10 ++-
 2 files changed, 145 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
index 7c515db..e93760c 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -751,6 +751,143 @@ static int tg3_ape_event_lock(struct tg3 *tp, u32 timeout_us)
 	return timeout_us ? 0 : -EBUSY;
 }
 
+static int tg3_ape_wait_for_event(struct tg3 *tp, u32 timeout_us)
+{
+	u32 i, apedata;
+
+	for (i = 0; i < timeout_us / 10; i++) {
+		apedata = tg3_ape_read32(tp, TG3_APE_EVENT_STATUS);
+
+		if (!(apedata & APE_EVENT_STATUS_EVENT_PENDING))
+			break;
+
+		udelay(10);
+	}
+
+	return i == timeout_us / 10;
+}
+
+int tg3_ape_scratchpad_read(struct tg3 *tp, u32 *data, u32 base_off, u32 len)
+{
+	int err;
+	u32 i, bufoff, msgoff, maxlen, apedata;
+
+	if (!tg3_flag(tp, APE_HAS_NCSI))
+		return 0;
+
+	apedata = tg3_ape_read32(tp, TG3_APE_SEG_SIG);
+	if (apedata != APE_SEG_SIG_MAGIC)
+		return -ENODEV;
+
+	apedata = tg3_ape_read32(tp, TG3_APE_FW_STATUS);
+	if (!(apedata & APE_FW_STATUS_READY))
+		return -EAGAIN;
+
+	bufoff = tg3_ape_read32(tp, TG3_APE_SEG_MSG_BUF_OFF) +
+		 TG3_APE_SHMEM_BASE;
+	msgoff = bufoff + 2 * sizeof(u32);
+	maxlen = tg3_ape_read32(tp, TG3_APE_SEG_MSG_BUF_LEN);
+
+	while (len) {
+		u32 length;
+
+		/* Cap xfer sizes to scratchpad limits. */
+		length = (len > maxlen) ? maxlen : len;
+		len -= length;
+
+		apedata = tg3_ape_read32(tp, TG3_APE_FW_STATUS);
+		if (!(apedata & APE_FW_STATUS_READY))
+			return -EAGAIN;
+
+		/* Wait for up to 1 msec for APE to service previous event. */
+		err = tg3_ape_event_lock(tp, 1000);
+		if (err)
+			return err;
+
+		apedata = APE_EVENT_STATUS_DRIVER_EVNT |
+			  APE_EVENT_STATUS_SCRTCHPD_READ |
+			  APE_EVENT_STATUS_EVENT_PENDING;
+		tg3_ape_write32(tp, TG3_APE_EVENT_STATUS, apedata);
+
+		tg3_ape_write32(tp, bufoff, base_off);
+		tg3_ape_write32(tp, bufoff + sizeof(u32), length);
+
+		tg3_ape_unlock(tp, TG3_APE_LOCK_MEM);
+		tg3_ape_write32(tp, TG3_APE_EVENT, APE_EVENT_1);
+
+		base_off += length;
+
+		if (tg3_ape_wait_for_event(tp, 30000))
+			return -EAGAIN;
+
+		for (i = 0; length; i += 4, length -= 4) {
+			u32 val = tg3_ape_read32(tp, msgoff + i);
+			memcpy(data, &val, sizeof(u32));
+			data++;
+		}
+	}
+
+	return 0;
+}
+
+int tg3_ape_scratchpad_write(struct tg3 *tp, u32 dstoff, u32 *data, u32 len)
+{
+	u32 i, bufoff, msgoff, maxlen, apedata;
+
+	if (!tg3_flag(tp, APE_HAS_NCSI))
+		return 0;
+
+	apedata = tg3_ape_read32(tp, TG3_APE_SEG_SIG);
+	if (apedata != APE_SEG_SIG_MAGIC)
+		return -ENODEV;
+
+	apedata = tg3_ape_read32(tp, TG3_APE_FW_STATUS);
+	if (!(apedata & APE_FW_STATUS_READY))
+		return -EAGAIN;
+
+	bufoff = tg3_ape_read32(tp, TG3_APE_SEG_MSG_BUF_OFF) +
+		 TG3_APE_SHMEM_BASE;
+	msgoff = bufoff + 2 * sizeof(u32);
+	maxlen = tg3_ape_read32(tp, TG3_APE_SEG_MSG_BUF_LEN);
+
+	while (len) {
+		int err;
+		u32 length;
+
+		/* Cap xfer sizes to scratchpad limits. */
+		length = (len > maxlen) ? maxlen : len;
+		len -= length;
+
+		/* Wait for up to 1 millisecond for
+		 * APE to service previous event.
+		 */
+		err = tg3_ape_event_lock(tp, 1000);
+		if (err)
+			return err;
+
+		tg3_ape_write32(tp, bufoff, dstoff);
+		tg3_ape_write32(tp, bufoff + sizeof(u32), length);
+		apedata = msgoff;
+
+		dstoff += length;
+
+		for (i = 0; length; i += 4, length -= sizeof(u32)) {
+			tg3_ape_write32(tp, apedata, *data++);
+			apedata += sizeof(u32);
+		}
+
+		apedata = APE_EVENT_STATUS_DRIVER_EVNT |
+			  APE_EVENT_STATUS_SCRTCHPD_WRITE |
+			  APE_EVENT_STATUS_EVENT_PENDING;
+		tg3_ape_write32(tp, TG3_APE_EVENT_STATUS, apedata);
+
+		tg3_ape_unlock(tp, TG3_APE_LOCK_MEM);
+		tg3_ape_write32(tp, TG3_APE_EVENT, APE_EVENT_1);
+	}
+
+	return 0;
+}
+
 static int tg3_ape_send_event(struct tg3 *tp, u32 event)
 {
 	int err;
diff --git a/drivers/net/ethernet/broadcom/tg3.h b/drivers/net/ethernet/broadcom/tg3.h
index 93865f8..d167a1c 100644
--- a/drivers/net/ethernet/broadcom/tg3.h
+++ b/drivers/net/ethernet/broadcom/tg3.h
@@ -2311,10 +2311,12 @@
 #define  APE_LOCK_REQ_DRIVER		 0x00001000
 #define TG3_APE_LOCK_GRANT		0x004c
 #define  APE_LOCK_GRANT_DRIVER		 0x00001000
-#define TG3_APE_SEG_SIG			0x4000
-#define  APE_SEG_SIG_MAGIC		 0x41504521
+#define TG3_APE_STICKY_TMR		0x00b0
 
 /* APE shared memory.  Accessible through BAR1 */
+#define TG3_APE_SHMEM_BASE		0x4000
+#define TG3_APE_SEG_SIG			0x4000
+#define  APE_SEG_SIG_MAGIC		 0x41504521
 #define TG3_APE_FW_STATUS		0x400c
 #define  APE_FW_STATUS_READY		 0x00000100
 #define TG3_APE_FW_FEATURES		0x4010
@@ -2327,6 +2329,8 @@
 #define  APE_FW_VERSION_REVMSK		 0x0000ff00
 #define  APE_FW_VERSION_REVSFT		 8
 #define  APE_FW_VERSION_BLDMSK		 0x000000ff
+#define TG3_APE_SEG_MSG_BUF_OFF		0x401c
+#define TG3_APE_SEG_MSG_BUF_LEN		0x4020
 #define TG3_APE_HOST_SEG_SIG		0x4200
 #define  APE_HOST_SEG_SIG_MAGIC		 0x484f5354
 #define TG3_APE_HOST_SEG_LEN		0x4204
@@ -2353,6 +2357,8 @@
 
 #define  APE_EVENT_STATUS_DRIVER_EVNT	 0x00000010
 #define  APE_EVENT_STATUS_STATE_CHNGE	 0x00000500
+#define  APE_EVENT_STATUS_SCRTCHPD_READ	 0x00001600
+#define  APE_EVENT_STATUS_SCRTCHPD_WRITE 0x00001700
 #define  APE_EVENT_STATUS_STATE_START	 0x00010000
 #define  APE_EVENT_STATUS_STATE_UNLOAD	 0x00020000
 #define  APE_EVENT_STATUS_STATE_WOL	 0x00030000
-- 
1.7.1

^ permalink raw reply related

* [PATCH 1/3 net-next] tg3: Add common function tg3_ape_event_lock()
From: Michael Chan @ 2012-06-21  0:06 UTC (permalink / raw)
  To: davem; +Cc: netdev, nsujir, mcarlson

From: Matt Carlson <mcarlson@broadcom.com>

by refactoring code in tg3_ape_send_event().  The common function will
be used in subsequent patches.

Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
---
 drivers/net/ethernet/broadcom/tg3.c |   56 ++++++++++++++++++++---------------
 1 files changed, 32 insertions(+), 24 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
index e47ff8b..7c515db 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -730,44 +730,52 @@ static void tg3_ape_unlock(struct tg3 *tp, int locknum)
 	tg3_ape_write32(tp, gnt + 4 * locknum, bit);
 }
 
-static void tg3_ape_send_event(struct tg3 *tp, u32 event)
+static int tg3_ape_event_lock(struct tg3 *tp, u32 timeout_us)
 {
-	int i;
 	u32 apedata;
 
-	/* NCSI does not support APE events */
-	if (tg3_flag(tp, APE_HAS_NCSI))
-		return;
+	while (timeout_us) {
+		if (tg3_ape_lock(tp, TG3_APE_LOCK_MEM))
+			return -EBUSY;
+
+		apedata = tg3_ape_read32(tp, TG3_APE_EVENT_STATUS);
+		if (!(apedata & APE_EVENT_STATUS_EVENT_PENDING))
+			break;
+
+		tg3_ape_unlock(tp, TG3_APE_LOCK_MEM);
+
+		udelay(10);
+		timeout_us -= (timeout_us > 10) ? 10 : timeout_us;
+	}
+
+	return timeout_us ? 0 : -EBUSY;
+}
+
+static int tg3_ape_send_event(struct tg3 *tp, u32 event)
+{
+	int err;
+	u32 apedata;
 
 	apedata = tg3_ape_read32(tp, TG3_APE_SEG_SIG);
 	if (apedata != APE_SEG_SIG_MAGIC)
-		return;
+		return -EAGAIN;
 
 	apedata = tg3_ape_read32(tp, TG3_APE_FW_STATUS);
 	if (!(apedata & APE_FW_STATUS_READY))
-		return;
+		return -EAGAIN;
 
 	/* Wait for up to 1 millisecond for APE to service previous event. */
-	for (i = 0; i < 10; i++) {
-		if (tg3_ape_lock(tp, TG3_APE_LOCK_MEM))
-			return;
-
-		apedata = tg3_ape_read32(tp, TG3_APE_EVENT_STATUS);
-
-		if (!(apedata & APE_EVENT_STATUS_EVENT_PENDING))
-			tg3_ape_write32(tp, TG3_APE_EVENT_STATUS,
-					event | APE_EVENT_STATUS_EVENT_PENDING);
+	err = tg3_ape_event_lock(tp, 1000);
+	if (err)
+		return err;
 
-		tg3_ape_unlock(tp, TG3_APE_LOCK_MEM);
+	tg3_ape_write32(tp, TG3_APE_EVENT_STATUS,
+			event | APE_EVENT_STATUS_EVENT_PENDING);
 
-		if (!(apedata & APE_EVENT_STATUS_EVENT_PENDING))
-			break;
+	tg3_ape_unlock(tp, TG3_APE_LOCK_MEM);
+	tg3_ape_write32(tp, TG3_APE_EVENT, APE_EVENT_1);
 
-		udelay(100);
-	}
-
-	if (!(apedata & APE_EVENT_STATUS_EVENT_PENDING))
-		tg3_ape_write32(tp, TG3_APE_EVENT, APE_EVENT_1);
+	return 0;
 }
 
 static void tg3_ape_driver_state_change(struct tg3 *tp, int kind)
-- 
1.7.1

^ permalink raw reply related

* [PATCH 3/3 net-next] tg3: Add sysfs file to export sensor data
From: Michael Chan @ 2012-06-21  0:06 UTC (permalink / raw)
  To: davem; +Cc: netdev, nsujir, mcarlson
In-Reply-To: <1340237192-30052-2-git-send-email-mchan@broadcom.com>

Some tg3 devices have management firmware that can export data such as
temperature and other real time diagnostics data.  Export this data to
sysfs so that userspace can access this information.

Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Signed-off-by: Nithin Nayak Sujir <nsujir@broadcom.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
---
 drivers/net/ethernet/broadcom/tg3.c |  241 +++++++++++++++++++++++++++++++++++
 drivers/net/ethernet/broadcom/tg3.h |   60 +++++++++
 2 files changed, 301 insertions(+), 0 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
index e93760c..f6c56ff 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -9538,6 +9538,182 @@ static int tg3_init_hw(struct tg3 *tp, int reset_phy)
 	return tg3_reset_hw(tp, reset_phy);
 }
 
+static void tg3_sd_xfer(struct tg3 *tp, u32 off, u32 size)
+{
+	struct tg3_sd *sd = tp->sd;
+
+	if (!size)
+		return;
+
+	tg3_ape_scratchpad_read(tp, (u32 *) &sd->buf[off], off, size);
+}
+
+static void tg3_sd_update_host(struct tg3 *tp, struct tg3_sd_record *rec)
+{
+	tg3_sd_xfer(tp, rec->data_off, rec->data_len);
+	tg3_sd_xfer(tp, rec->hdr_off, rec->hdr_len);
+}
+
+static void tg3_sd_update_drvflags(struct tg3 *tp, bool unloading)
+{
+	struct tg3_sd *sd = tp->sd;
+	u32 flags;
+
+	if (!sd || !sd->sd_flags_off)
+		return;
+
+	tg3_ape_scratchpad_read(tp, &flags, sd->sd_flags_off, 4);
+
+	flags &= ~TG3_OCIR_DRVR_FEAT_MASK;
+
+	if (!unloading) {
+		u32 mask = NETIF_F_RXCSUM | NETIF_F_IP_CSUM |
+			   NETIF_F_IPV6_CSUM | NETIF_F_HW_CSUM;
+
+		if (tp->dev->features & mask)
+			flags |= TG3_OCIR_DRVR_FEAT_CSUM;
+
+		if (tp->dev->features & NETIF_F_ALL_TSO)
+			flags |= TG3_OCIR_DRVR_FEAT_TSO;
+	}
+
+	tg3_ape_scratchpad_write(tp, sd->sd_flags_off, &flags, 4);
+}
+
+static void tg3_sd_scan_scratchpad(struct tg3 *tp, struct tg3_ocir *ocir)
+{
+	int i;
+
+	for (i = 0; i < TG3_SD_NUM_RECS; i++, ocir++) {
+		u32 off = i * TG3_OCIR_LEN, len = TG3_OCIR_LEN;
+
+		tg3_ape_scratchpad_read(tp, (u32 *) ocir, off, len);
+		off += len;
+
+		if (ocir->signature != TG3_OCIR_SIG_MAGIC ||
+		    !(ocir->version_flags & TG3_OCIR_FLAG_ACTIVE))
+			memset(ocir, 0, TG3_OCIR_LEN);
+	}
+}
+
+static ssize_t tg3_sd_read(struct device *dev, struct device_attribute *attr,
+			     char *buff)
+{
+	struct pci_dev *pdev = to_pci_dev(dev);
+	struct net_device *netdev = pci_get_drvdata(pdev);
+	struct tg3 *tp = netdev_priv(netdev);
+	struct tg3_sd *sd = tp->sd;
+
+	memcpy(buff, sd->buf, sd->buf_size);
+
+	return sd->buf_size;
+}
+
+static DEVICE_ATTR(tg3_sd, 0400, tg3_sd_read, NULL);
+
+static int tg3_sd_init(struct tg3 *tp)
+{
+	int i;
+	u32 size = 0;
+	struct tg3_sd *sd;
+	struct tg3_ocir ocirs[TG3_SD_NUM_RECS];
+
+	if (!tg3_flag(tp, ENABLE_APE))
+		return 0;
+
+	tp->sd = kzalloc(sizeof(struct tg3_sd), GFP_KERNEL);
+	if (!tp->sd)
+		return -ENOMEM;
+
+	sd = tp->sd;
+	tg3_sd_scan_scratchpad(tp, ocirs);
+
+	for (i = 0; i < TG3_SD_NUM_RECS; i++) {
+		u32 val = 1;
+		struct tg3_sd_record *rec = &sd->rec[i];
+
+		if (!ocirs[i].src_data_length)
+			continue;
+
+		rec->hdr_len = ocirs[i].src_hdr_length;
+		rec->hdr_off = ocirs[i].src_hdr_offset;
+		rec->data_len = ocirs[i].src_data_length;
+		rec->data_off = ocirs[i].src_data_offset;
+
+		size += ocirs[i].src_hdr_length;
+		size += ocirs[i].src_data_length;
+
+		rec->utmr_off = i * TG3_OCIR_LEN + TG3_OCIR_UPDATE_TMR_OFF;
+		rec->rtmr_off = i * TG3_OCIR_LEN + TG3_OCIR_REFRESH_TMR_OFF;
+		rec->rtmr_int = ocirs[i].refresh_int;
+
+		/* Initialize utmr_off to non-zero so that we read the region
+		 * at least once */
+		if (tg3_ape_scratchpad_write(tp, rec->utmr_off, &val, 4))
+			netdev_err(tp->dev, "write scratchpad error\n");
+
+		ocirs[i].update_tmr = 0;
+	}
+	if (!size) {
+		kfree(sd);
+		tp->sd = NULL;
+		return -ENODEV;
+	}
+
+	size += sizeof(ocirs);
+
+	sd->buf = kzalloc(size, GFP_KERNEL);
+	if (!sd->buf) {
+		kfree(sd);
+		tp->sd = NULL;
+		return -ENOMEM;
+	}
+
+	sd->buf_size = size;
+	memcpy(sd->buf, ocirs, sizeof(ocirs));
+
+	sd->sd_flags_off = 2 * TG3_OCIR_LEN +
+			     (tp->pci_fn * sizeof(u32)) +
+			     TG3_OCIR_PORT0_FLGS_OFF;
+
+	tg3_sd_update_drvflags(tp, false);
+	return 0;
+}
+
+static void tg3_sd_fini(struct tg3 *tp)
+{
+	struct tg3_sd *sd = tp->sd;
+
+	if (!sd)
+		return;
+
+	tg3_sd_update_drvflags(tp, true);
+
+	kfree(sd->buf);
+	kfree(sd);
+	tp->sd = NULL;
+}
+
+static void tg3_sd_close(struct tg3 *tp)
+{
+	struct tg3_sd *sd = tp->sd;
+
+	if (!sd)
+		return;
+
+	device_remove_file(&tp->pdev->dev, &dev_attr_tg3_sd);
+}
+
+static int tg3_sd_open(struct tg3 *tp)
+{
+	struct tg3_sd *sd = tp->sd;
+
+	if (!sd)
+		return -ENODEV;
+
+	return device_create_file(&tp->pdev->dev, &dev_attr_tg3_sd);
+}
+
 #define TG3_STAT_ADD32(PSTAT, REG) \
 do {	u32 __val = tr32(REG); \
 	(PSTAT)->low += __val; \
@@ -9623,6 +9799,59 @@ static void tg3_chk_missed_msi(struct tg3 *tp)
 	}
 }
 
+
+static void tg3_sd_timer(struct tg3 *tp)
+{
+	int i;
+	u32 val;
+	struct tg3_sd *sd = tp->sd;
+	struct tg3_ocir *ocirp = (struct tg3_ocir *) sd->buf;
+
+	if (!netif_running(tp->dev))
+		return;
+
+	for (i = 0; i < TG3_SD_NUM_RECS; i++, ocirp++) {
+		struct tg3_sd_record *rec = &sd->rec[i];
+
+		if (!rec->data_len)
+			continue;
+
+		tg3_ape_scratchpad_read(tp, &val, rec->utmr_off, 4);
+		/* Check if data has changed */
+		if (val) {
+
+			if (!rec->rtmr_int) {
+				tg3_sd_update_host(tp, rec);
+
+				rec->updated_seq++;
+				ocirp->update_tmr = rec->updated_seq;
+			} else {
+				u32 curr;
+				unsigned long tgt;
+
+				curr = tg3_ape_read32(tp, TG3_APE_STICKY_TMR);
+				tgt = rec->rtmr_val + rec->rtmr_int;
+				if (time_after((unsigned long) curr, tgt)) {
+					tg3_sd_update_host(tp, rec);
+
+					rec->rtmr_val = curr;
+					tg3_ape_scratchpad_write(tp,
+							rec->rtmr_off,
+							&curr, 4);
+
+					rec->updated_seq++;
+					ocirp->update_tmr = rec->updated_seq;
+				}
+			}
+
+			val = 0;
+			if (tg3_ape_scratchpad_write(tp, rec->utmr_off,
+						     &val, 4))
+				netdev_err(tp->dev, "write scratchpad error\n");
+		}
+	}
+}
+
 static void tg3_timer(unsigned long __opaque)
 {
 	struct tg3 *tp = (struct tg3 *) __opaque;
@@ -9661,6 +9890,9 @@ static void tg3_timer(unsigned long __opaque)
 		if (tg3_flag(tp, 5705_PLUS))
 			tg3_periodic_fetch_stats(tp);
 
+		if (tp->sd)
+			tg3_sd_timer(tp);
+
 		if (tp->setlpicnt && !--tp->setlpicnt)
 			tg3_phy_eee_enable(tp);
 
@@ -10246,6 +10478,8 @@ static int tg3_open(struct net_device *dev)
 
 	tg3_phy_start(tp);
 
+	tg3_sd_open(tp);
+
 	tg3_full_lock(tp, 0);
 
 	tg3_timer_start(tp);
@@ -10295,6 +10529,8 @@ static int tg3_close(struct net_device *dev)
 
 	tg3_timer_stop(tp);
 
+	tg3_sd_close(tp);
+
 	tg3_phy_stop(tp);
 
 	tg3_full_lock(tp, 1);
@@ -15945,6 +16181,8 @@ static int __devinit tg3_init_one(struct pci_dev *pdev,
 
 	tg3_timer_init(tp);
 
+	tg3_sd_init(tp);
+
 	err = register_netdev(dev);
 	if (err) {
 		dev_err(&pdev->dev, "Cannot register net device, aborting\n");
@@ -16039,6 +16277,9 @@ static void __devexit tg3_remove_one(struct pci_dev *pdev)
 		}
 
 		unregister_netdev(dev);
+
+		tg3_sd_fini(tp);
+
 		if (tp->aperegs) {
 			iounmap(tp->aperegs);
 			tp->aperegs = NULL;
diff --git a/drivers/net/ethernet/broadcom/tg3.h b/drivers/net/ethernet/broadcom/tg3.h
index d167a1c..61a8f71 100644
--- a/drivers/net/ethernet/broadcom/tg3.h
+++ b/drivers/net/ethernet/broadcom/tg3.h
@@ -2379,6 +2379,18 @@
 #define TG3_APE_LOCK_PHY3		5
 #define TG3_APE_LOCK_GPIO		7
 
+/* SD flags */
+#define TG3_OCIR_SIG_MAGIC		0x5253434f
+#define TG3_OCIR_FLAG_ACTIVE		0x00000001
+
+#define TG3_OCIR_DRVR_FEAT_CSUM		0x00000001
+#define TG3_OCIR_DRVR_FEAT_TSO		0x00000002
+#define TG3_OCIR_DRVR_FEAT_MASK		0xff
+
+#define TG3_OCIR_REFRESH_TMR_OFF	0x00000008
+#define TG3_OCIR_UPDATE_TMR_OFF		0x0000000c
+#define TG3_OCIR_PORT0_FLGS_OFF		0x0000002c
+
 #define TG3_EEPROM_SB_F1R2_MBA_OFF	0x10
 
 
@@ -2677,6 +2689,52 @@ struct tg3_hw_stats {
 	u8				__reserved4[0xb00-0x9c8];
 };
 
+#define TG3_SD_NUM_RECS		3
+#define TG3_OCIR_LEN			(sizeof(struct tg3_ocir))
+
+
+struct tg3_ocir {
+	u32				signature;
+	u16				version_flags;
+	u16				refresh_int;
+	u32				refresh_tmr;
+	u32				update_tmr;
+	u32				dst_base_addr;
+	u16				src_hdr_offset;
+	u16				src_hdr_length;
+	u16				src_data_offset;
+	u16				src_data_length;
+	u16				dst_hdr_offset;
+	u16				dst_data_offset;
+	u16				dst_reg_upd_offset;
+	u16				dst_sem_offset;
+	u32				reserved1[2];
+	u32				port0_flags;
+	u32				port1_flags;
+	u32				port2_flags;
+	u32				port3_flags;
+	u32				reserved2[1];
+};
+
+struct tg3_sd_record {
+	u16				hdr_off;
+	u16				hdr_len;
+	u16				data_off;
+	u16				data_len;
+	u32				updated_seq;
+	u16				utmr_off;
+	u16				rtmr_off;
+	u32				rtmr_val;
+	u16				rtmr_int;
+};
+
+struct tg3_sd {
+	struct tg3_sd_record		rec[TG3_SD_NUM_RECS];
+	u32				sd_flags_off;
+	int				buf_size;
+	u8				*buf;
+};
+
 /* 'mapping' is superfluous as the chip does not write into
  * the tx/rx post rings so we could just fetch it from there.
  * But the cache behavior is better how we are doing it now.
@@ -3212,6 +3270,8 @@ struct tg3 {
 	const char			*fw_needed;
 	const struct firmware		*fw;
 	u32				fw_len; /* includes BSS */
+
+	struct tg3_sd			*sd;
 };
 
 #endif /* !(_T3_H) */
-- 
1.7.1

^ permalink raw reply related

* Re: [PATCH] net: sh_eth: fix the rxdesc pointer when rx descriptor empty happens
From: Shimoda, Yoshihiro @ 2012-06-21  1:26 UTC (permalink / raw)
  To: Guennadi Liakhovetski; +Cc: netdev, SH-Linux
In-Reply-To: <Pine.LNX.4.64.1206201507260.20254@axis700.grange>

Hello Guennadi-san,

2012/06/20 22:10, Guennadi Liakhovetski wrote:
> Hello Shimoda-san
> 
> On Tue, 29 May 2012, Shimoda, Yoshihiro wrote:
> 
>> When Receive Descriptor Empty happens, rxdesc pointer of the driver
>> and actual next descriptor of the controller may be mismatch.
>> This patch fixes it.
> 
> Unfortunately, this patch breaks networking on ecovec (sh7724). Booting 
> with dhcp and NFS-root progresses very slowly with lots of "nfs: server 
> not responding / Ok" messages and never completes. Reverting it in current 
> Linus' tree fixes the problem.

Thank you very much for the report.
The SH7724 doesn't set the RMCR register. So, the EDRRR will be clear after
the controller receives a freme every time.
So, the "fix the rxdesc pointer" had to check a condition.

I wrote a patch for the issue as the following.
If possible, would you try the patch?

Best regards,
Yoshihiro Shimoda
---
Subject: [PATCH] net: sh_eth: fix the condition to fix the cur_tx/dirty_rx

The following commit couldn't work if the RMCR is not set to 1.

"net: sh_eth: fix the rxdesc pointer when rx descriptor empty happens"
commit id 79fba9f51755c704c0a7d7b7f0df10874dc0a744

If RMCR is not set, the controller will clear the EDRRR after it received
a frame. In this case, the driver doesn't need to fix the value of
cur_rx/dirty_rx. The driver only needs it when the controll detects
receive descriptors are empty.

Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
---
 drivers/net/ethernet/renesas/sh_eth.c |   12 +++++++-----
 1 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c
index 667169b..79bf09b 100644
--- a/drivers/net/ethernet/renesas/sh_eth.c
+++ b/drivers/net/ethernet/renesas/sh_eth.c
@@ -1011,7 +1011,7 @@ static int sh_eth_txfree(struct net_device *ndev)
 }

 /* Packet receive function */
-static int sh_eth_rx(struct net_device *ndev)
+static int sh_eth_rx(struct net_device *ndev, u32 intr_status)
 {
 	struct sh_eth_private *mdp = netdev_priv(ndev);
 	struct sh_eth_rxdesc *rxdesc;
@@ -1102,9 +1102,11 @@ static int sh_eth_rx(struct net_device *ndev)
 	/* Restart Rx engine if stopped. */
 	/* If we don't need to check status, don't. -KDU */
 	if (!(sh_eth_read(ndev, EDRRR) & EDRRR_R)) {
-		/* fix the values for the next receiving */
-		mdp->cur_rx = mdp->dirty_rx = (sh_eth_read(ndev, RDFAR) -
-					       sh_eth_read(ndev, RDLAR)) >> 4;
+		/* fix the values for the next receiving if RDE is set */
+		if (intr_status & EESR_RDE)
+			mdp->cur_rx = mdp->dirty_rx =
+				(sh_eth_read(ndev, RDFAR) -
+				 sh_eth_read(ndev, RDLAR)) >> 4;
 		sh_eth_write(ndev, EDRRR_R, EDRRR);
 	}

@@ -1273,7 +1275,7 @@ static irqreturn_t sh_eth_interrupt(int irq, void *netdev)
 			EESR_RTSF | /* short frame recv */
 			EESR_PRE  | /* PHY-LSI recv error */
 			EESR_CERF)){ /* recv frame CRC error */
-		sh_eth_rx(ndev);
+		sh_eth_rx(ndev, intr_status);
 	}

 	/* Tx Check */
-- 
1.7.1


^ permalink raw reply related

* Re: [PATCH] [XFRM] Fix unexpected SA hard expiration after changing date
From: Fan Du @ 2012-06-21  2:11 UTC (permalink / raw)
  To: David Miller; +Cc: herbert, netdev, fdu
In-Reply-To: <20120619.020553.227635216346617898.davem@davemloft.net>

Hi David

On 2012年06月19日 17:05, David Miller wrote:
> From: David Miller<davem@davemloft.net>
> Date: Tue, 19 Jun 2012 02:01:11 -0700 (PDT)
>
>> From: "fan.du"<fan.du@windriver.com>
>> Date: Tue, 19 Jun 2012 15:51:09 +0800
>>
>>> From: "fan.du"<fan.du@windriver.com>
>>
>> Please don't put your email user name instead of real name in quotes
>> there.  Thank you.
>
> Also fdu@windriver.com bounces, do not put it in the CC: list.

I have send the V3 which made modifications requested by your advice at
here:
http://marc.info/?l=linux-netdev&m=134009837402499&w=2
http://marc.info/?l=linux-netdev&m=134009837402498&w=2

Could you please take a look at it if you have time?

thanks :)

-- 

Love each day!
--fan

^ permalink raw reply

* Re: [PATCH] [XFRM] Fix unexpected SA hard expiration after changing date
From: David Miller @ 2012-06-21  3:43 UTC (permalink / raw)
  To: fan.du; +Cc: herbert, netdev, fdu
In-Reply-To: <4FE282E7.2010804@windriver.com>

From: Fan Du <fan.du@windriver.com>
Date: Thu, 21 Jun 2012 10:11:51 +0800

> Could you please take a look at it if you have time?

Everyone saw it, you need to be patient.

And you still have fdu@windriver.com in the CC: list, which I told you
bounces.

I asked you explicitly to remove this email address from the CC: list,
because it bounces.

^ permalink raw reply

* Re: [PATCH] Allow receiving packets on the fallback tunnel if they pass sanity checks
From: David Miller @ 2012-06-21  4:04 UTC (permalink / raw)
  To: phil; +Cc: netdev, phild
In-Reply-To: <20120605154058.GA16615@ipom.com>

From: Phil Dibowitz <phil@ipom.com>
Date: Tue, 5 Jun 2012 08:40:58 -0700

> From b413062771afbba064ae9bc49b5daed7abb1243d Mon Sep 17 00:00:00 2001
> From: Ville Nuorvala <ville.nuorvala@gmail.com>
> Subject: [PATCH] Allow receiving packets on the fallback tunnel if they pass sanity checks
> 
> The same IPv6 address checks are performed as with any normal tunnel,
> but as the fallback tunnel endpoint addresses are unspecified, the checks
> must be performed on a per-packet basis, rather than at tunnel
> configuration time.
> 
> Signed-off-by: Ville Nuorvala <ville.nuorvala@gmail.com>
> Tested-by: Phil Dibowitz <phil@ipom.com>

I've reviewed this change but I still have no idea why it's
necessary.

You need to compose a more lengthy and detailed commit log message
explaining everything before I'm going to consider applying this
patch.

You can't just say "we have some problem at Facebook, this patch fixes
it", and then merely describe word by word the content of the patch
without explaining the "why".  That simply doesn't cut it.

Thanks.

^ permalink raw reply

* Re: Possible deadlock in ipv6?
From: David Miller @ 2012-06-21  4:05 UTC (permalink / raw)
  To: eric.dumazet; +Cc: vdavydov, netdev
In-Reply-To: <1339492184.22704.26.camel@edumazet-glaptop>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 12 Jun 2012 11:09:44 +0200

> Is it expected we send traffic on device dismantle ?

If we are subscribed to multicast groups we could, to
announce our leaving those groups.

^ permalink raw reply

* Re: [PATCH] [XFRM] Fix unexpected SA hard expiration after changing date
From: David Miller @ 2012-06-21  4:06 UTC (permalink / raw)
  To: fan.du; +Cc: herbert, netdev, fdu
In-Reply-To: <1340092269-6136-2-git-send-email-fan.du@windriver.com>

From: "fan.du" <fan.du@windriver.com>
Date: Tue, 19 Jun 2012 15:51:09 +0800

> +			x->xflags |= ~XFRM_SOFT_EXPIRE;

This is not how you clear a bit in a bitmask.

^ permalink raw reply

* Re: [PATCH] net: Update netdev_alloc_frag to work more efficiently with TCP and GRO
From: Alexander Duyck @ 2012-06-21  4:07 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: Alexander Duyck, netdev, davem, jeffrey.t.kirsher
In-Reply-To: <1340198514.4604.970.camel@edumazet-glaptop>

On 6/20/2012 6:21 AM, Eric Dumazet wrote:
> On Wed, 2012-06-20 at 10:17 +0200, Eric Dumazet wrote:
>
>> Strange, I did again benchs with order-2 allocations and got good
>> results this time, but with latest net-next, maybe things have changed
>> since last time I did this.
>>
>> (netdev_alloc_frag(), get_page_from_freelist() and put_page() less
>> prevalent in perf results)
>>
> In fact, since SLUB uses order-3 for kmalloc-2048, I felt lucky to try
> this as well, and results are really good, on ixgbe at least.
>
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 5b21522..ffd2cba 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -299,6 +299,9 @@ struct netdev_alloc_cache {
>   };
>   static DEFINE_PER_CPU(struct netdev_alloc_cache, netdev_alloc_cache);
>
> +#define MAX_NETDEV_FRAGSIZE	max_t(unsigned int, PAGE_SIZE, 32768)
> +#define NETDEV_FRAG_ORDER	get_order(MAX_NETDEV_FRAGSIZE)
> +
>   /**
>    * netdev_alloc_frag - allocate a page fragment
>    * @fragsz: fragment size
> @@ -316,11 +319,13 @@ void *netdev_alloc_frag(unsigned int fragsz)
>   	nc =&__get_cpu_var(netdev_alloc_cache);
>   	if (unlikely(!nc->page)) {
>   refill:
> -		nc->page = alloc_page(GFP_ATOMIC | __GFP_COLD);
> +		nc->page = alloc_pages(GFP_ATOMIC | __GFP_COLD |
> +				       (NETDEV_FRAG_ORDER ? __GFP_COMP : 0),
> +				       NETDEV_FRAG_ORDER);
>   		nc->offset = 0;
>   	}
I was wondering if you needed the check for NETDEV_FRAG_ORDER here.  
 From what I can tell setting __GFP_COMP for an order 0 page has no 
effect since it only seems to get checked in prep_new_page and that is 
after a check to verify if the page is order 0 or not.

Thanks,

Alex

^ permalink raw reply

* Re: Q: NET/JME: pci_get_drvdata pointer return check at jme_remove
From: devendra.aaru @ 2012-06-21  4:41 UTC (permalink / raw)
  To: Ben Hutchings; +Cc: netdev
In-Reply-To: <1340224238.2576.17.camel@bwh-desktop.uk.solarflarecom.com>

Hi Ben,

On Thu, Jun 21, 2012 at 2:00 AM, Ben Hutchings
<bhutchings@solarflare.com> wrote:
> On Wed, 2012-06-20 at 22:50 +0530, devendra.aaru wrote:
>> Hi,
>>
>> looking at the jme_init_one error path, the context of the driver data
>> is set to null.
>>
>> If the driver unloads , the unload _remove_one, will be called and
>> deferencing the pointer, leading to a oops.
>>
>> so we need to have a check at before doing the netdev_priv at remove_one.
>>
>> Please correct me if my understanding is wrong....
>
> If a driver probe function fails for some device (i.e. its return value
> is negative), its remove function is *not* called for that device.
>
Oh, Thanks for the information, really i m a noob. i will not ask this
q's until i read some more things about the kernel and device driver
layers.
> Ben.
>
> --
> Ben Hutchings, Staff Engineer, Solarflare
> Not speaking for my employer; that's the marketing department's job.
> They asked us to note that Solarflare product names are trademarked.
>

Thanks,
Devendra

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox