Netdev List
 help / color / mirror / Atom feed
* [PATCH 10/10] atl1c: remove PHY polling from atl1c_change_mtu
From: xiong @ 2012-05-01  1:38 UTC (permalink / raw)
  To: davem, netdev, linux-kernel; +Cc: qca-linux-team, nic-devel, xiong
In-Reply-To: <1335836338-9425-1-git-send-email-xiong@qca.qualcomm.com>

PHY polling code for FPGA is considered in every MDIO R/W API.
no need to add additional code to atl1c_change_mtu.

Signed-off-by: xiong <xiong@qca.qualcomm.com>
Tested-by: David Liu <dwliu@qca.qaulcomm.com>
---
 drivers/net/ethernet/atheros/atl1c/atl1c_main.c |    8 --------
 1 files changed, 0 insertions(+), 8 deletions(-)

diff --git a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
index 05ce8ec..9cc1570 100644
--- a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
+++ b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
@@ -553,14 +553,6 @@ static int atl1c_change_mtu(struct net_device *netdev, int new_mtu)
 		netdev_update_features(netdev);
 		atl1c_up(adapter);
 		clear_bit(__AT_RESETTING, &adapter->flags);
-		if (adapter->hw.ctrl_flags & ATL1C_FPGA_VERSION) {
-			u32 phy_data;
-
-			AT_READ_REG(&adapter->hw, 0x1414, &phy_data);
-			phy_data |= 0x10000000;
-			AT_WRITE_REG(&adapter->hw, 0x1414, phy_data);
-		}
-
 	}
 	return 0;
 }
-- 
1.7.7

^ permalink raw reply related

* Re: [PATCH net-next 00/10] tipc: last batch from the sourceforge queue
From: David Miller @ 2012-05-01  1:45 UTC (permalink / raw)
  To: paul.gortmaker; +Cc: netdev, allan.stephens, jon.maloy, erik.hugne, ying.xue
In-Reply-To: <1335825428-16053-1-git-send-email-paul.gortmaker@windriver.com>

From: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Mon, 30 Apr 2012 18:36:58 -0400

> I'm glad to say this represents the last batch of salvaged commits
> from what was the sourceforge queue of stuff misplaced on the older
> v2.6.19/v1.7.x baseline.  Going forward, folks got a clear message
> that they _must_ put forward any new/prospective changes on netdev
> for peer review and ask for continuous integration and not stockpile
> crap in a corner (cause I'm sure as hell not going to volunteer to
> be Winston Wolf for it again).
> 
> Anyway, knowing that there isn't any more "old" patches from that to
> worry about, I took the opportunity to close out by clobbering a bunch
> of needless extra blank lines following comments, since there isn't
> any pending patch context fallout to worry about.  This one cosmetic
> change alone makes up most of the diffstat, giving:
> 
>  32 files changed, 16 insertions(+), 530 deletions(-)
> 
> out of the total:
> 
>  34 files changed, 58 insertions(+), 567 deletions(-)

You must feel like you've just moved a mountain, Mr. Wolf.

> That aside, the meat of what is here is:
> 
>   -reduce some of the build up/tear down on configuration paths
> 
>   -more strict checks on published names and payload types
> 
>   -factor out some duplicated code;  +some redundant code deletion.
> 
> Testing has been the usual 64 <---> 32bit using tipc-utils ptts.
> 
> I still want to look at your suggestion of reusing existing code
> for the logging stuff someday, now that the queue is closed out,
> but that is completely separate from the backlog, and it probably
> isn't going to be happening in the 3.5 timeframe.

Pulled, thanks.

^ permalink raw reply

* Re: [PATCH 00/10] atl1c: update hardware settings - v4
From: David Miller @ 2012-05-01  1:45 UTC (permalink / raw)
  To: xiong; +Cc: netdev, linux-kernel, qca-linux-team, nic-devel
In-Reply-To: <1335836338-9425-1-git-send-email-xiong@qca.qualcomm.com>

From: xiong <xiong@qca.qualcomm.com>
Date: Tue, 1 May 2012 09:38:48 +0800

> This update contains a serial of patches, most of them are hardware
> settings related. register definitions are refined (or removed if
> meaningless) for each patch.
> 
> This is the last patch set.
> 
> The patches have addressed all sparse and checkpatch warnings.
> 
> Following NICs are tested:
> AR8131/AR8132/AR8151A/AR8152A/AR8152B
> Test item includes:
> build/install/uninstall/dhcp/ping/iperf/wol/reboot/etc.

All applied, thanks.

^ permalink raw reply

* Re: [PATCH 1/4] e1000: add transmit timestamping support
From: David Miller @ 2012-05-01  1:46 UTC (permalink / raw)
  To: eric.dumazet; +Cc: willemb, netdev, jeffrey.t.kirscher, eilong, aabdulla
In-Reply-To: <1335599262.2900.50.camel@edumazet-glaptop>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 28 Apr 2012 09:47:42 +0200

> On Fri, 2012-04-27 at 15:04 -0400, Willem de Bruijn wrote:
>> Signed-off-by: Willem de Bruijn <willemb@google.com>
...
> Acked-by: Eric Dumazet <edumazet@google.com>

Applied.

^ permalink raw reply

* Re: [PATCH 2/4] e1000e: add transmit timestamping support
From: David Miller @ 2012-05-01  1:46 UTC (permalink / raw)
  To: eric.dumazet; +Cc: willemb, netdev, jeffrey.t.kirscher, eilong, aabdulla
In-Reply-To: <1335599273.2900.51.camel@edumazet-glaptop>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 28 Apr 2012 09:47:53 +0200

> On Fri, 2012-04-27 at 15:04 -0400, Willem de Bruijn wrote:
>> Signed-off-by: Willem de Bruijn <willemb@google.com>
 ...
> Acked-by: Eric Dumazet <edumazet@google.com>

Applied.

^ permalink raw reply

* Re: [PATCH 3/4] bnx2x: add transmit timestamping support
From: David Miller @ 2012-05-01  1:46 UTC (permalink / raw)
  To: eric.dumazet; +Cc: willemb, netdev, jeffrey.t.kirscher, eilong, aabdulla
In-Reply-To: <1335599319.2900.52.camel@edumazet-glaptop>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 28 Apr 2012 09:48:39 +0200

> On Fri, 2012-04-27 at 15:04 -0400, Willem de Bruijn wrote:
>> Signed-off-by: Willem de Bruijn <willemb@google.com>
 ...
> Acked-by: Eric Dumazet <edumazet@google.com>

Applied.

^ permalink raw reply

* Re: [PATCH 4/4] forcedeth: add transmit timestamping support
From: David Miller @ 2012-05-01  1:47 UTC (permalink / raw)
  To: eric.dumazet; +Cc: willemb, netdev, jeffrey.t.kirscher, eilong, aabdulla
In-Reply-To: <1335599385.2900.53.camel@edumazet-glaptop>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 28 Apr 2012 09:49:45 +0200

> On Fri, 2012-04-27 at 15:04 -0400, Willem de Bruijn wrote:
>> Insert an skb_tx_timestamp call in both ndo_start_xmit routines
>> Tested to work for the nv_start_xmit_optimized case
>> 
>> Signed-off-by: Willem de Bruijn <willemb@google.com>
 ...
> Acked-by: Eric Dumazet <edumazet@google.com>

Applied.

^ permalink raw reply

* Re: [PATCH net-next] pch_gbe: reprogram multicast address register on reset
From: David Miller @ 2012-05-01  1:47 UTC (permalink / raw)
  To: roy.qing.li; +Cc: netdev, richardcochran, tshimizu818
In-Reply-To: <1335592421-31406-1-git-send-email-roy.qing.li@gmail.com>

From: roy.qing.li@gmail.com
Date: Sat, 28 Apr 2012 13:53:41 +0800

> From: RongQing.Li <roy.qing.li@gmail.com>
> 
> The reset logic after a Rx FIFO overrun will clear the programmed
> multicast addresses. This patch fixes the issue by reprogramming the
> registers after the reset.
> 
> The commit eefc48b tried to fix this problem, but it introduces
> unnecessary codes. In fact, all multicast addresses have been saved
> in netdev->mc, So we can call pch_gbe_set_multi() directly after
> reset_hw and reset_rx.
> 
> This commit kills 50+ line codes
> 
> Cc: Richard Cochran <richardcochran@gmail.com>
> Cc: Takahiro Shimizu <tshimizu818@gmail.com>
> Signed-off-by: RongQing.Li <roy.qing.li@gmail.com>

Applied.

^ permalink raw reply

* Re: [net 1/3] igbvf: fix the bug when initializing the igbvf
From: Shan Wei @ 2012-05-01  1:48 UTC (permalink / raw)
  To: Jeff Kirsher; +Cc: davem, netdev, gospo, sassmann, Samuel Liao, Shan Wei
In-Reply-To: <1335827794-26992-2-git-send-email-jeffrey.t.kirsher@intel.com>

Jeff Kirsher said, at 2012/5/1 7:16:

> From: Shan Wei <shanwei88@gmail.com>


The "From" tag will be wrote in git log as Author of this patch.
It should be "From: Samuel Liao <samuelliao@tencent.com>", not me.

So, please resubmit it to David Miller.
Thanks.

> 
> Maybe it's a typo, but it cause that igbvf can't be initialized successfully.
> Set perm_addr value using valid dev_addr, although which is equal to hw.mac.addr.
> 
> Signed-off-by: Samuel Liao <samuelliao@tencent.com>
> Signed-off-by: Shan Wei <davidshan@tencent.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>

^ permalink raw reply

* Re: [PATCH 1/4 net-next] net: allow skb->head to be a page fragment
From: David Miller @ 2012-05-01  1:48 UTC (permalink / raw)
  To: eric.dumazet
  Cc: netdev, ilpo.jarvinen, ncardwell, therbert, maze,
	jeffrey.t.kirsher, bhutchings, mcarlson, mchan, herbert
In-Reply-To: <1335522818.2775.227.camel@edumazet-glaptop>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 27 Apr 2012 12:33:38 +0200

> From: Eric Dumazet <edumazet@google.com>
> 
> skb->head is currently allocated from kmalloc(). This is convenient but
> has the drawback the data cannot be converted to a page fragment if
> needed.
 ...
> Given all these issues, the following patch introduces the possibility
> of having skb->head be a fragment in itself. We use a new skb flag,
> skb->head_frag to carry this information.
 ...
> Signed-off-by: Eric Dumazet <edumazet@google.com>

Applied.

^ permalink raw reply

* Re: [PATCH 2/4 net-next] tg3: provide frags as skb head
From: David Miller @ 2012-05-01  1:48 UTC (permalink / raw)
  To: eric.dumazet
  Cc: netdev, ilpo.jarvinen, therbert, ncardwell, bhutchings, mcarlson,
	jeffrey.t.kirsher, mchan, herbert, maze
In-Reply-To: <1335522889.2775.231.camel@edumazet-glaptop>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 27 Apr 2012 12:34:49 +0200

> From: Eric Dumazet <edumazet@google.com>
> 
> This patch converts tg3 driver, one of our reference drivers, to use new
> build_skb() api in frag mode.
> 
> Instead of using kmalloc() to allocate the memory block that will be
> used by build_skb() as skb->head, we use a page fragment.
> 
> This is a followup of patch "net: allow skb->head to be a page fragment"
> 
> This allows GRO, TCP coalescing, and splice() to be more efficient.
> 
> Incidentally, this also removes SLUB slow path contention in kfree()
> 
> Signed-off-by: Eric Dumazet <edumazet@google.com>

Applied.

^ permalink raw reply

* Re: [PATCH 3/4 v2 net-next] net: make GRO aware of skb->head_frag
From: David Miller @ 2012-05-01  1:48 UTC (permalink / raw)
  To: eric.dumazet
  Cc: netdev, ncardwell, therbert, jeffrey.t.kirsher, mchan, mcarlson,
	herbert, bhutchings, ilpo.jarvinen, maze
In-Reply-To: <1335809434.2296.9.camel@edumazet-glaptop>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 30 Apr 2012 20:10:34 +0200

> From: Eric Dumazet <edumazet@google.com>
> 
> GRO can check if skb to be merged has its skb->head mapped to a page
> fragment, instead of a kmalloc() area.
> 
> We 'upgrade' skb->head as a fragment in itself
> 
> This avoids the frag_list fallback, and permits to build true GRO skb
> (one sk_buff and up to 16 fragments), using less memory.
> 
> This reduces number of cache misses when user makes its copy, since a
> single sk_buff is fetched.
> 
> This is a followup of patch "net: allow skb->head to be a page fragment"
> 
> Signed-off-by: Eric Dumazet <edumazet@google.com>

Applied.

^ permalink raw reply

* Re: [PATCH 4/4 net-next] tcp: makes tcp_try_coalesce aware of skb->head_frag
From: David Miller @ 2012-05-01  1:48 UTC (permalink / raw)
  To: eric.dumazet
  Cc: netdev, ncardwell, jeffrey.t.kirsher, therbert, herbert,
	bhutchings, mcarlson, mchan, maze, ilpo.jarvinen
In-Reply-To: <1335523113.2775.239.camel@edumazet-glaptop>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 27 Apr 2012 12:38:33 +0200

> From: Eric Dumazet <edumazet@google.com>
> 
> TCP coalesce can check if skb to be merged has its skb->head mapped to a
> page fragment, instead of a kmalloc() area.
> 
> We had to disable coalescing in this case, for performance reasons.
> 
> We 'upgrade' skb->head as a fragment in itself.
> 
> This reduces number of cache misses when user makes its copies, since a
> less sk_buff are fetched.
> 
> This makes receive and ofo queues shorter and thus reduce cache line
> misses in TCP stack.
> 
> This is a followup of patch "net: allow skb->head to be a page fragment"
> 
> Tested with tg3 nic, with GRO on or off. We can see "TCPRcvCoalesce"
> counter being incremented.
> 
> Signed-off-by: Eric Dumazet <edumazet@google.com>

Applied.

^ permalink raw reply

* Re: [PATCH 5/5 net-next] net: makes skb_splice_bits() aware of skb->head_frag
From: David Miller @ 2012-05-01  1:48 UTC (permalink / raw)
  To: eric.dumazet
  Cc: netdev, ncardwell, jeffrey.t.kirsher, therbert, herbert,
	bhutchings, mcarlson, mchan, maze, ilpo.jarvinen
In-Reply-To: <1335528603.2775.246.camel@edumazet-glaptop>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 27 Apr 2012 14:10:03 +0200

> From: Eric Dumazet <edumazet@google.com>
> 
> __skb_splice_bits() can check if skb to be spliced has its skb->head
> mapped to a page fragment, instead of a kmalloc() area.
> 
> If so we can avoid a copy of the skb head and get a reference on
> underlying page.
> 
> Signed-off-by: Eric Dumazet <edumazet@google.com>

Applied.

^ permalink raw reply

* Re: [PATCH 0/7] smsc75xx fixes
From: David Miller @ 2012-05-01  1:55 UTC (permalink / raw)
  To: steve.glendinning; +Cc: netdev, fillods
In-Reply-To: <1335808616-22513-1-git-send-email-steve.glendinning@shawell.net>

From: Steve Glendinning <steve.glendinning@shawell.net>
Date: Mon, 30 Apr 2012 18:56:49 +0100

> Stephane Fillod's big patch addresses multiple issues, so this patchset
> splits it into a separate patch for each issue.
> 
> Thanks to Stephane for finding and fixing these bugs.
> 
> Steve Glendinning (7):
>   smsc75xx: mark link down on startup and let PHY interrupt deal with
>     carrier changes
>   smsc75xx: fix mdio reads and writes
>   smsc75xx: add more information to register io failure warnings
>   smsc75xx: fix phy init reset loop
>   smsc75xx: fix phy interrupt acknowledge
>   smsc75xx: declare smsc75xx's MII as GMII capable
>   smsc75xx: enable mac to detect speed/duplex from phy

All applied, thanks Steve.

^ permalink raw reply

* [net v2 0/3][pull request] Intel Wired LAN Driver Updates
From: Jeff Kirsher @ 2012-05-01  1:58 UTC (permalink / raw)
  To: davem; +Cc: Jeff Kirsher, netdev, gospo, sassmann

This series of patches contains fixes for igbvf and ixgbe.

v2: Corrected authorship for the igbvf patch to Samuel Liao.

The following are changes since commit 1cebce36d660c83bd1353e41f3e66abd4686f215:
  tcp: fix infinite cwnd in tcp_complete_cwr()
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 a memory leak in IEEE DCB

Samuel Liao (1):
  igbvf: fix the bug when initializing the igbvf

Yi Zou (1):
  ixgbe: fix calling skb_put on nonlinear skb assertion bug

 drivers/net/ethernet/intel/igbvf/netdev.c     |    4 ++--
 drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c |    1 +
 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |    9 +++++----
 3 files changed, 8 insertions(+), 6 deletions(-)

-- 
1.7.7.6

^ permalink raw reply

* [net 2/3] ixgbe: Fix a memory leak in IEEE DCB
From: Jeff Kirsher @ 2012-05-01  1:58 UTC (permalink / raw)
  To: davem; +Cc: Alexander Duyck, netdev, gospo, sassmann, Jeff Kirsher
In-Reply-To: <1335837495-9722-1-git-send-email-jeffrey.t.kirsher@intel.com>

From: Alexander Duyck <alexander.h.duyck@intel.com>

The driver was freeing memory in shutdown instead of remove.  As a result
we were leaking memory if IEEE DCB was enabled and we loaded/unloaded the
driver.  This change moves the freeing of the memory into the remove
routine where it belongs.

Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Acked-by: John Fastabend <john.r.fastabend@intel.com>
Tested-by: Ross Brattain <ross.b.brattain@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |    9 +++++----
 1 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index a7f3cd8..88f6b2e 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -4873,10 +4873,6 @@ static int __ixgbe_shutdown(struct pci_dev *pdev, bool *enable_wake)
 	}
 
 	ixgbe_clear_interrupt_scheme(adapter);
-#ifdef CONFIG_DCB
-	kfree(adapter->ixgbe_ieee_pfc);
-	kfree(adapter->ixgbe_ieee_ets);
-#endif
 
 #ifdef CONFIG_PM
 	retval = pci_save_state(pdev);
@@ -7224,6 +7220,11 @@ static void __devexit ixgbe_remove(struct pci_dev *pdev)
 
 	ixgbe_release_hw_control(adapter);
 
+#ifdef CONFIG_DCB
+	kfree(adapter->ixgbe_ieee_pfc);
+	kfree(adapter->ixgbe_ieee_ets);
+
+#endif
 	iounmap(adapter->hw.hw_addr);
 	pci_release_selected_regions(pdev, pci_select_bars(pdev,
 				     IORESOURCE_MEM));
-- 
1.7.7.6

^ permalink raw reply related

* [net 1/3] igbvf: fix the bug when initializing the igbvf
From: Jeff Kirsher @ 2012-05-01  1:58 UTC (permalink / raw)
  To: davem; +Cc: Samuel Liao, netdev, gospo, sassmann, Shan Wei, Jeff Kirsher
In-Reply-To: <1335837495-9722-1-git-send-email-jeffrey.t.kirsher@intel.com>

From: Samuel Liao <samuelliao@tencent.com>

Maybe it's a typo, but it cause that igbvf can't be initialized successfully.
Set perm_addr value using valid dev_addr, although which is equal to hw.mac.addr.

Signed-off-by: Samuel Liao <samuelliao@tencent.com>
Signed-off-by: Shan Wei <davidshan@tencent.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
 drivers/net/ethernet/intel/igbvf/netdev.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/intel/igbvf/netdev.c b/drivers/net/ethernet/intel/igbvf/netdev.c
index d61ca2a..8ec74b0 100644
--- a/drivers/net/ethernet/intel/igbvf/netdev.c
+++ b/drivers/net/ethernet/intel/igbvf/netdev.c
@@ -2731,14 +2731,14 @@ static int __devinit igbvf_probe(struct pci_dev *pdev,
 			netdev->addr_len);
 	}
 
-	if (!is_valid_ether_addr(netdev->perm_addr)) {
+	if (!is_valid_ether_addr(netdev->dev_addr)) {
 		dev_err(&pdev->dev, "Invalid MAC Address: %pM\n",
 		        netdev->dev_addr);
 		err = -EIO;
 		goto err_hw_init;
 	}
 
-	memcpy(netdev->perm_addr, adapter->hw.mac.addr, netdev->addr_len);
+	memcpy(netdev->perm_addr, netdev->dev_addr, netdev->addr_len);
 
 	setup_timer(&adapter->watchdog_timer, &igbvf_watchdog,
 	            (unsigned long) adapter);
-- 
1.7.7.6

^ permalink raw reply related

* [net 3/3] ixgbe: fix calling skb_put on nonlinear skb assertion bug
From: Jeff Kirsher @ 2012-05-01  1:58 UTC (permalink / raw)
  To: davem; +Cc: Yi Zou, netdev, gospo, sassmann, Jeff Kirsher
In-Reply-To: <1335837495-9722-1-git-send-email-jeffrey.t.kirsher@intel.com>

From: Yi Zou <yi.zou@intel.com>

With the support to bounce buffer added, the skb is coming as nonlinear in the
case of non-DDPed data frames for FCoE, which is mostly ok as the FCoE stack
would take care of that. However, for target mode, we have to set the FC CRC
and FC EOF field to allow the protocol stack to not drop the frame for the last
data frame of that sequence. So fix this by linearizing the skb first before
doing skb_put().

Signed-off-by: Yi Zou <yi.zou@intel.com>
Tested-by: Marcus Dennis <marcusx.e.dennis@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
 drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c
index 77ea4b7..bc07933 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c
@@ -437,6 +437,7 @@ int ixgbe_fcoe_ddp(struct ixgbe_adapter *adapter,
 	 */
 	if ((fh->fh_r_ctl == FC_RCTL_DD_SOL_DATA) &&
 	    (fctl & FC_FC_END_SEQ)) {
+		skb_linearize(skb);
 		crc = (struct fcoe_crc_eof *)skb_put(skb, sizeof(*crc));
 		crc->fcoe_eof = FC_EOF_T;
 	}
-- 
1.7.7.6

^ permalink raw reply related

* [PATCH net-next] net: add a prefetch in socket backlog processing
From: Eric Dumazet @ 2012-05-01  2:07 UTC (permalink / raw)
  To: David Miller; +Cc: netdev

From: Eric Dumazet <edumazet@google.com>

TCP or UDP stacks have big enough latencies that prefetching next
pointer is worth it.

Signed-off-by: Eric Dumazet <edumazet@google.com>
---
 net/core/sock.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/net/core/sock.c b/net/core/sock.c
index 836bca6..1a88351 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -1700,6 +1700,7 @@ static void __release_sock(struct sock *sk)
 		do {
 			struct sk_buff *next = skb->next;
 
+			prefetch(next);
 			WARN_ON_ONCE(skb_dst_is_noref(skb));
 			skb->next = NULL;
 			sk_backlog_rcv(sk, skb);

^ permalink raw reply related

* Re: [net v2 0/3][pull request] Intel Wired LAN Driver Updates
From: David Miller @ 2012-05-01  2:07 UTC (permalink / raw)
  To: jeffrey.t.kirsher; +Cc: netdev, gospo, sassmann
In-Reply-To: <1335837495-9722-1-git-send-email-jeffrey.t.kirsher@intel.com>

From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Mon, 30 Apr 2012 18:58:12 -0700

> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net master

Pulled, thanks Jeff.

^ permalink raw reply

* Re: [PATCH] cxgb3: Don't call cxgb_vlan_mode until q locks are initialized
From: David Miller @ 2012-05-01  2:09 UTC (permalink / raw)
  To: roland; +Cc: divy, netdev, roland
In-Reply-To: <1335806147-17310-1-git-send-email-roland@kernel.org>

From: Roland Dreier <roland@kernel.org>
Date: Mon, 30 Apr 2012 10:15:47 -0700

> From: Roland Dreier <roland@purestorage.com>
> 
> The driver calls cxgb_vlan_mode() from init_one().  This calls into
> synchronize_rx(), which locks all the q locks, but the q locks are not
> initialized until cxgb_up() -> setup_sge_qsets().  So move the call to
> cxgb_vlan_mode() into cxgb_up(), after the call to setup_sge_qsets().
> We also move the body of these functions up higher to avoid having to
> a forward declaration.
> 
> This was found because of the lockdep warning:
 ...
> Contrary to what lockdep says, the code is not fine: we are locking an
> uninitialized spinlock.
> 
> Signed-off-by: Roland Dreier <roland@purestorage.com>

Applied, thanks.

^ permalink raw reply

* [PATCH net-next] net: skb_peek()/skb_peek_tail() cleanups
From: Eric Dumazet @ 2012-05-01  2:31 UTC (permalink / raw)
  To: David Miller; +Cc: netdev

From: Eric Dumazet <edumazet@google.com>

remove useless casts and rename variables for less confusion.

Signed-off-by: Eric Dumazet <edumazet@google.com>
---
 include/linux/skbuff.h |   20 ++++++++++++--------
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 2c75e98..988fc49 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -883,10 +883,11 @@ static inline struct sk_buff *skb_unshare(struct sk_buff *skb,
  */
 static inline struct sk_buff *skb_peek(const struct sk_buff_head *list_)
 {
-	struct sk_buff *list = ((const struct sk_buff *)list_)->next;
-	if (list == (struct sk_buff *)list_)
-		list = NULL;
-	return list;
+	struct sk_buff *skb = list_->next;
+
+	if (skb == (struct sk_buff *)list_)
+		skb = NULL;
+	return skb;
 }
 
 /**
@@ -902,6 +903,7 @@ static inline struct sk_buff *skb_peek_next(struct sk_buff *skb,
 		const struct sk_buff_head *list_)
 {
 	struct sk_buff *next = skb->next;
+
 	if (next == (struct sk_buff *)list_)
 		next = NULL;
 	return next;
@@ -922,10 +924,12 @@ static inline struct sk_buff *skb_peek_next(struct sk_buff *skb,
  */
 static inline struct sk_buff *skb_peek_tail(const struct sk_buff_head *list_)
 {
-	struct sk_buff *list = ((const struct sk_buff *)list_)->prev;
-	if (list == (struct sk_buff *)list_)
-		list = NULL;
-	return list;
+	struct sk_buff *skb = list_->prev;
+
+	if (skb == (struct sk_buff *)list_)
+		skb = NULL;
+	return skb;
+
 }
 
 /**

^ permalink raw reply related

* Re: [PATCH net-next] net: add a prefetch in socket backlog processing
From: Joe Perches @ 2012-05-01  3:24 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1335838029.11396.12.camel@edumazet-glaptop>

On Tue, 2012-05-01 at 04:07 +0200, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
> 
> TCP or UDP stacks have big enough latencies that prefetching next
> pointer is worth it.
> 
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> ---
>  net/core/sock.c |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/net/core/sock.c b/net/core/sock.c
> index 836bca6..1a88351 100644
> --- a/net/core/sock.c
> +++ b/net/core/sock.c
> @@ -1700,6 +1700,7 @@ static void __release_sock(struct sock *sk)
>  		do {
>  			struct sk_buff *next = skb->next;
>  
> +			prefetch(next);
>  			WARN_ON_ONCE(skb_dst_is_noref(skb));
>  			skb->next = NULL;
>  			sk_backlog_rcv(sk, skb);

Hi Eric.

Why should next be "prefetch"ed when
two lines below it's set to null and
the only use is as a pointer not as
an apparently undereferenced pointer?

^ permalink raw reply

* Re: [PATCH 3/4 v2 net-next] net: make GRO aware of skb->head_frag
From: Alexander Duyck @ 2012-05-01  5:33 UTC (permalink / raw)
  To: Eric Dumazet
  Cc: Alexander Duyck, David Miller, netdev, Neal Cardwell, Tom Herbert,
	Jeff Kirsher, Michael Chan, Matt Carlson, Herbert Xu,
	Ben Hutchings, Ilpo Järvinen, Maciej Żenczykowski
In-Reply-To: <1335835677.11396.5.camel@edumazet-glaptop>

On Mon, Apr 30, 2012 at 6:27 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Mon, 2012-04-30 at 16:36 -0700, Alexander Duyck wrote:
>> On 04/30/2012 11:10 AM, Eric Dumazet wrote:
>> > From: Eric Dumazet <edumazet@google.com>
>> >
>> > GRO can check if skb to be merged has its skb->head mapped to a page
>> > fragment, instead of a kmalloc() area.
>> >
>> > We 'upgrade' skb->head as a fragment in itself
>> >
>> > This avoids the frag_list fallback, and permits to build true GRO skb
>> > (one sk_buff and up to 16 fragments), using less memory.
>> >
>> > This reduces number of cache misses when user makes its copy, since a
>> > single sk_buff is fetched.
>> >
>> > This is a followup of patch "net: allow skb->head to be a page fragment"
>> >

[...]

>> > diff --git a/net/core/skbuff.c b/net/core/skbuff.c
>> > index effa75d..2ad1ee7 100644
>> > --- a/net/core/skbuff.c
>> > +++ b/net/core/skbuff.c
>> > @@ -69,7 +69,7 @@
>> >  #include <trace/events/skb.h>
>> >  #include <linux/highmem.h>
>> >
>> > -static struct kmem_cache *skbuff_head_cache __read_mostly;
>> > +struct kmem_cache *skbuff_head_cache __read_mostly;
>> >  static struct kmem_cache *skbuff_fclone_cache __read_mostly;
>> >
>> >  static void sock_pipe_buf_release(struct pipe_inode_info *pipe,
>> > @@ -2901,6 +2901,31 @@ int skb_gro_receive(struct sk_buff **head, struct sk_buff *skb)
>> >
>> >             NAPI_GRO_CB(skb)->free = 1;
>> >             goto done;
>> > +   } else if (skb->head_frag) {
>> > +           int nr_frags = pinfo->nr_frags;
>> > +           skb_frag_t *frag = pinfo->frags + nr_frags;
>> > +           struct page *page = virt_to_head_page(skb->head);
>> > +           unsigned int first_size = headlen - offset;
>> > +           unsigned int first_offset;
>> > +
>> > +           if (nr_frags + 1 + skbinfo->nr_frags > MAX_SKB_FRAGS)
>> > +                   return -E2BIG;
>> > +
>> > +           first_offset = skb->data -
>> > +                          (unsigned char *)page_address(page) +
>> > +                          offset;
>> > +
>> > +           pinfo->nr_frags = nr_frags + 1 + skbinfo->nr_frags;
>> > +
>> > +           frag->page.p      = page;
>> > +           frag->page_offset = first_offset;
>> > +           skb_frag_size_set(frag, first_size);
>> > +
>> > +           memcpy(frag + 1, skbinfo->frags, sizeof(*frag) * skbinfo->nr_frags);
>> > +           /* We dont need to clear skbinfo->nr_frags here */
>> > +
>> > +           NAPI_GRO_CB(skb)->free = NAPI_GRO_FREE_STOLEN_HEAD;
>> > +           goto done;
>> >     } else if (skb_gro_len(p) != pinfo->gso_size)
>> >             return -E2BIG;
>> >
>> >
>> >
>> Maybe I missed something, but shouldn't you be checking skb->cloned, and
>> skb_shinfo()->dataref before you can consider just dropping the
>> sk_buff?  It seems like if you are sharing the frag with a clone you
>> would have to retain the skb->head so that you can track the dataref.
>> Otherwise you will likely cause issues because the stack could end up
>> freeing the sk_buff, or the GRO frame will be capable of calling
>> put_page and freeing the page out from under the clone.
>>
>
> Is it a general question, or specific to this patch ?
>
> If its a general problem, we already check dataref where appropriate.
> Fact that skb->head is a kmalloc() or frag doesnt matter.
>
> If specific to GRO, see my first answer. GRO owns each skb.
>
> adding a BUG() would make no sense here.

The question I had was more specific to GRO.  As long as we have
skb->users == 1 and the skb isn't cloned we should be fine.   It just
hadn't occurred to me before that napi_gro_receive had the extra
requirement that the skb couldn't be cloned.

Thanks,

Alex

^ 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