Netdev List
 help / color / mirror / Atom feed
* Re: [PATCH net-next] mlx4: use dev_kfree_skb() instead of dev_kfree_skb_any()
From: Or Gerlitz @ 2012-09-18 19:58 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: David Miller, netdev, Yevgeny Petrilin, Or Gerlitz, Ying Cai
In-Reply-To: <1347866974.26523.53.camel@edumazet-glaptop>

On Mon, Sep 17, 2012 at 10:29 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:

> Since commit e22979d96a5 (mlx4_en: Moving to Interrupts for TX
> completions), we no longer can free TX skb from hard IRQ, but only from
> normal softirq or process context.
>
> Therefore, we can directly call dev_kfree_skb() from
> mlx4_en_free_tx_desc() like other conventional NAPI drivers.

Hi Eric,

The team is all off till tomorrow, we will look and get back to you

Or.

^ permalink raw reply

* Re: [PATCH net-next V4 0/2] Add rtnl_link_ops support to IPoIB
From: Or Gerlitz @ 2012-09-18 20:07 UTC (permalink / raw)
  To: Roland Dreier, David Miller; +Cc: netdev
In-Reply-To: <1347551797-2495-1-git-send-email-ogerlitz@mellanox.com>

On Thu, Sep 13, 2012 at 6:56 PM, Or Gerlitz <ogerlitz@mellanox.com> wrote:
> This is about adding rtnl_link_ops to IPoIB, primarly addressing feedback
> from Dave on a similar patch that was part of the eIPoIB submission.
[...]
> Roland, this patch is hanging out for pretty long while (few months) without
> any comment from you, if it makes things easier, I would like to merge it through
> net-next, makes sense?


Hi Roland,

Haven't heard from you on this patch, are you picking this or it can
get in though net-next?

Or.

> Changes from V3:
>  - addressed feedback from Patrick McHardy to move the IFLA_IPOIB_yyy ipoib
>    rtnl defintions into include/linux/if_link.h
>  - changed IFLA_IPOIB_CHILD_PKEY to be named IFLA_IPOIB_PKEY which will cope
>    with more IFLA_IPOIB_yyy entries to be added once the basic support is in
>
> Changes from V2:
>  - removed the notion of user defined index per child, since we can do well w.o it
>  - for that end, make (an internal to ipoib) distrinction between legacy childs created
>    through the old sysfs way to childs created using rtnl link ops
>
> Changes from V1:
>  - applied feedback from Dave Miller to avoid using sysfs
>  - added rtnl_link_ops support in ipoib and use them to add/delete childs
>
> Or Gerlitz (1):
>   IB/ipoib: Add rtnl_link_ops support

^ permalink raw reply

* Re: [PATCH net-next v3 0/4] Take care of xfrm policy when checking dst entries
From: David Miller @ 2012-09-18 20:08 UTC (permalink / raw)
  To: nicolas.dichtel
  Cc: vyasevich, eric.dumazet, sds, james.l.morris, eparis, sri,
	linux-sctp, netdev
In-Reply-To: <20120917.155458.777649470378504320.davem@davemloft.net>

From: David Miller <davem@davemloft.net>
Date: Mon, 17 Sep 2012 15:54:58 -0400 (EDT)

> I'm reconsidering putting Eric's patch into 'net' and that would
> allow me to use your v3 patches as-is.

And that's what I've done just now, thanks.

^ permalink raw reply

* Re: [PATCH net-next V4 0/2] Add rtnl_link_ops support to IPoIB
From: David Miller @ 2012-09-18 20:12 UTC (permalink / raw)
  To: or.gerlitz; +Cc: roland, netdev
In-Reply-To: <CAJZOPZL6cEEbyMgj+3_h-ZHf0jzNs3yF=f3uOTrKB6EO4Vx2yw@mail.gmail.com>

From: Or Gerlitz <or.gerlitz@gmail.com>
Date: Tue, 18 Sep 2012 23:07:54 +0300

> On Thu, Sep 13, 2012 at 6:56 PM, Or Gerlitz <ogerlitz@mellanox.com> wrote:
>> This is about adding rtnl_link_ops to IPoIB, primarly addressing feedback
>> from Dave on a similar patch that was part of the eIPoIB submission.
> [...]
>> Roland, this patch is hanging out for pretty long while (few months) without
>> any comment from you, if it makes things easier, I would like to merge it through
>> net-next, makes sense?
> 
> 
> Hi Roland,
> 
> Haven't heard from you on this patch, are you picking this or it can
> get in though net-next?

Nobody has given any generic networking review to this patch yet, and given
that I'd be very disappointed if Roland went ahead and applied this.

You never need to ping people over issues like this and it's extremely
irritating that you keep doing this.

Everything you need to know is at:

http://patchwork.ozlabs.org/project/netdev/list/

And you can clearly see your patch sitting there in "Under Review"
state.

You simply need to be patient and wait for people to get to reviewing
your patch rather than forcing the issue with pings.  We track patches
in patchwork so we don't need to waste time with "pings"

^ permalink raw reply

* Re: [PATCH 1/3] net/ieee802154/6lowpan.c: Remove unecessary semicolon
From: David Miller @ 2012-09-18 20:13 UTC (permalink / raw)
  To: peter.senna
  Cc: alex.bluesman.smirnov, dbaryshkov, linux-zigbee-devel, netdev,
	linux-kernel, kernel-janitors, trivial
In-Reply-To: <1347988245-31413-1-git-send-email-peter.senna@gmail.com>

From: Peter Senna Tschudin <peter.senna@gmail.com>
Date: Tue, 18 Sep 2012 19:10:43 +0200

> Found by http://coccinelle.lip6.fr/
> 
> Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>

Applied.

^ permalink raw reply

* Re: [PATCH 2/3] net/openvswitch/vport.c: Remove unecessary semicolon
From: David Miller @ 2012-09-18 20:13 UTC (permalink / raw)
  To: peter.senna-Re5JQEeQqe8AvxtiuMwx3w
  Cc: dev-yBygre7rU0TnMu66kgdUjQ, trivial-DgEjT+Ai2ygdnm+yROfE0A,
	netdev-u79uwXL29TY76Z2rM5mHXA,
	kernel-janitors-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1347988245-31413-2-git-send-email-peter.senna-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

From: Peter Senna Tschudin <peter.senna-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Tue, 18 Sep 2012 19:10:44 +0200

> Found by http://coccinelle.lip6.fr/
> 
> Signed-off-by: Peter Senna Tschudin <peter.senna-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

Applied.

^ permalink raw reply

* Re: [PATCH 3/3] net/tipc/name_table.c: Remove unecessary semicolon
From: David Miller @ 2012-09-18 20:13 UTC (permalink / raw)
  To: peter.senna
  Cc: jon.maloy, trivial, netdev, kernel-janitors, linux-kernel,
	tipc-discussion, allan.stephens
In-Reply-To: <1347988245-31413-3-git-send-email-peter.senna@gmail.com>

From: Peter Senna Tschudin <peter.senna@gmail.com>
Date: Tue, 18 Sep 2012 19:10:45 +0200

> Found by http://coccinelle.lip6.fr/
> 
> Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>

Applied.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

^ permalink raw reply

* Re: [PATCH] xfrm_user: return error pointer instead of NULL
From: David Miller @ 2012-09-18 20:16 UTC (permalink / raw)
  To: steffen.klassert; +Cc: minipli, netdev, linux-kernel, stable
In-Reply-To: <20120917071642.GC13023@secunet.com>

From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Mon, 17 Sep 2012 09:16:42 +0200

> On Thu, Sep 13, 2012 at 11:41:26PM +0200, Mathias Krause wrote:
>> When dump_one_state() returns an error, e.g. because of a too small
>> buffer to dump the whole xfrm state, xfrm_state_netlink() returns NULL
>> instead of an error pointer. But its callers expect an error pointer
>> and therefore continue to operate on a NULL skbuff.
>> 
>> This could lead to a privilege escalation (execution of user code in
>> kernel context) if the attacker has CAP_NET_ADMIN and is able to map
>> address 0.
> 
> Or it simply crashes with a NULL pointer dereference.
> 
>> 
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Mathias Krause <minipli@googlemail.com>
> 
> Acked-by: Steffen Klassert <steffen.klassert@secunet.com>

Applied, and queued up for -stable.

Please do not CC: stable explicitly in your patch submissions,
I removed it from the patch.

Instead, ask me to queue the patch up for -stable.  We handle stable
submissed via a patch queue which I maintain at:

	http://patchwork.ozlabs.org/user/bundle/2566/?state=*

so that I can let patches cook in Linus's tree for a length of
time of my choosing, rather than having bug fixes automatically
propagate the moment it hits Linus's tree.

Thanks.

^ permalink raw reply

* Re: [PATCH] xfrm_user: return error pointer instead of NULL #2
From: David Miller @ 2012-09-18 20:16 UTC (permalink / raw)
  To: steffen.klassert; +Cc: minipli, netdev, linux-kernel, stable
In-Reply-To: <20120917071853.GD13023@secunet.com>

From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Mon, 17 Sep 2012 09:18:53 +0200

> On Fri, Sep 14, 2012 at 09:58:32PM +0200, Mathias Krause wrote:
>> When dump_one_policy() returns an error, e.g. because of a too small
>> buffer to dump the whole xfrm policy, xfrm_policy_netlink() returns
>> NULL instead of an error pointer. But its caller expects an error
>> pointer and therefore continues to operate on a NULL skbuff.
>> 
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Mathias Krause <minipli@googlemail.com>
> 
> Acked-by: Steffen Klassert <steffen.klassert@secunet.com>

Applied and queued up for -stable.

^ permalink raw reply

* Re: [PATCH] bnx2x: fix rx checksum validation for IPv6
From: David Miller @ 2012-09-18 20:17 UTC (permalink / raw)
  To: eric.dumazet
  Cc: mschmidt, netdev, eilong, edumazet, yanivr, yuvalmin, meravs,
	evansr, therbert, willemb, hskinnemoen
In-Reply-To: <1347578079.8555.141.camel@edumazet-glaptop>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 14 Sep 2012 01:14:39 +0200

> On Fri, 2012-09-14 at 00:59 +0200, Michal Schmidt wrote:
>> Commit d6cb3e41 "bnx2x: fix checksum validation" caused a performance
>> regression for IPv6. Rx checksum offload does not work. IPv6 packets
>> are passed to the stack with CHECKSUM_NONE.
>> 
>> The hardware obviously cannot perform IP checksum validation for IPv6,
>> because there is no checksum in the IPv6 header. This should not prevent
>> us from setting CHECKSUM_UNNECESSARY.
>> 
>> Tested on BCM57711.
>> 
>> Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
 ...
> Thanks for fixing this bug !
> 
> Acked-by: Eric Dumazet <edumazet@google.com>
> 
> 

Applied, thanks.

^ permalink raw reply

* Re: [PATCH] netxen: check for root bus in netxen_mask_aer_correctable
From: David Miller @ 2012-09-18 20:23 UTC (permalink / raw)
  To: rajesh.borundia; +Cc: nikolay, sony.chacko, netdev
In-Reply-To: <13A253B3F9BEFE43B93C09CF75F63CAA827E3AE9F9@MNEXMB1.qlogic.org>


No, this is not the correct way to submit patches written by other
people.

Look at how people like Jeff Kirsher submits Intel driver patches
written by people other than himself.

^ permalink raw reply

* Re: [PATCH] netxen: check for root bus in netxen_mask_aer_correctable
From: David Miller @ 2012-09-18 20:23 UTC (permalink / raw)
  To: nikolay; +Cc: sony.chacko, rajesh.borundia, netdev
In-Reply-To: <1347637803-4837-1-git-send-email-nikolay@redhat.com>

From: nikolay@redhat.com
Date: Fri, 14 Sep 2012 17:50:03 +0200

> From: Nikolay Aleksandrov <nikolay@redhat.com>
> 
> Add a check if pdev->bus->self == NULL (root bus). When attaching
> a netxen NIC to a VM it can be on the root bus and the guest would
> crash in netxen_mask_aer_correctable() because of a NULL pointer
> dereference if CONFIG_PCIEAER is present.
> 
> Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>

Applied and queued up for -stable, thanks.

^ permalink raw reply

* Re: [PATCH] net: fix memory leak on oom with zerocopy
From: David Miller @ 2012-09-18 20:25 UTC (permalink / raw)
  To: mst; +Cc: edumazet, bhutchings, mirq-linux, netdev, linux-kernel
In-Reply-To: <20120916084416.GA22936@redhat.com>

From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Sun, 16 Sep 2012 11:44:16 +0300

> If orphan flags fails, we don't free the skb
> on receive, which leaks the skb memory.
> 
> Return value was also wrong: netif_receive_skb
> is supposed to return NET_RX_DROP, not ENOMEM.
> 
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

Applied, thanks Michael.

^ permalink raw reply

* Re: [patch net] sky2: fix rx filter setup on link up
From: David Miller @ 2012-09-18 20:25 UTC (permalink / raw)
  To: shemminger; +Cc: jiri, netdev, mlindner, linux-kernel
In-Reply-To: <20120917141507.7528b3ee@nehalam.linuxnetplumber.net>

From: Stephen Hemminger <shemminger@vyatta.com>
Date: Mon, 17 Sep 2012 14:15:07 -0700

> Are you sure it isn't IPv6 or something else setting additional mulitcast
> addresses. You may need to instrument the set_multicast call.

I'm confident in Jiri's analysis and patch and it's clear the hardware
is doing this on it's own, so please take his bug fix seriously.

^ permalink raw reply

* Re: [PATCH] tcp: fix regression in urgent data handling
From: David Miller @ 2012-09-18 20:26 UTC (permalink / raw)
  To: eric.dumazet; +Cc: netdev, springl-k, alexander.h.duyck
In-Reply-To: <1347922299.26523.198.camel@edumazet-glaptop>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 18 Sep 2012 00:51:39 +0200

> From: Eric Dumazet <edumazet@google.com>
> 
> Stephan Springl found that commit 1402d366019fed "tcp: introduce
> tcp_try_coalesce" introduced a regression for rlogin
> 
> It turns out problem comes from TCP urgent data handling and
> a change in behavior in input path.
> 
> rlogin sends two one-byte packets with URG ptr set, and when next data
> frame is coalesced, we lack sk_data_ready() calls to wakeup consumer.
> 
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Stephan Springl <springl-k@lar.bfw.de>
> Cc: Alexander Duyck <alexander.h.duyck@intel.com>

Applied, thanks Eric.

^ permalink raw reply

* Re: [PATCH] xfrm: fix a rcu_read_lock() imbalance in make_blackhole
From: David Miller @ 2012-09-18 20:30 UTC (permalink / raw)
  To: roy.qing.li; +Cc: netdev
In-Reply-To: <1347957610-7422-1-git-send-email-roy.qing.li@gmail.com>

From: roy.qing.li@gmail.com
Date: Tue, 18 Sep 2012 16:40:10 +0800

> From: Li RongQing <roy.qing.li@gmail.com>
> 
> if xfrm_policy_get_afinfo returns 0, it has already called rcu_read_unlock,
> xfrm_policy_put_afinfo should not be called again.
> 
> Signed-off-by: Li RongQing <roy.qing.li@gmail.com>

This bug exists in the 'net' tree too, where this lock is a read lock.

I've applied this patch and adjusted the commit log text to accomodate
to difference.

Thanks.

^ permalink raw reply

* Re: [net] e1000: Small packets may get corrupted during padding by HW
From: David Miller @ 2012-09-18 20:33 UTC (permalink / raw)
  To: jeffrey.t.kirsher; +Cc: tushar.n.dave, netdev, gospo, sassmann
In-Reply-To: <1347740217-10257-1-git-send-email-jeffrey.t.kirsher@intel.com>

From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Sat, 15 Sep 2012 13:16:57 -0700

> From: Tushar Dave <tushar.n.dave@intel.com>
> 
> On PCI/PCI-X HW, if packet size is less than ETH_ZLEN,
> packets may get corrupted during padding by HW.
> To WA this issue, pad all small packets manually.
> 
> Signed-off-by: Tushar Dave <tushar.n.dave@intel.com>
> Tested-by: Aaron Brown <aaron.f.brown@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>

There has been a lot of bike shedding on this patch, but the fix is
correct and thus I'm going to apply it to 'net'.

Thanks.

^ permalink raw reply

* [RFC net-next] netpoll: use static branch
From: Stephen Hemminger @ 2012-09-18 21:10 UTC (permalink / raw)
  To: David Miller, Cong Wang, Eric Dumazet; +Cc: netdev

This is an attempt to optimize netpoll when not used.

Since distro's enable everything and netpoll is only occasionally
used, improve performance by getting netpoll condition check
out of the Rx fastpath.

Compile tested only, I have no real use for netpoll.

Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>


---
 include/linux/netpoll.h |   28 ++++++++++++++++++++--------
 net/core/netpoll.c      |    8 +++++++-
 2 files changed, 27 insertions(+), 9 deletions(-)

--- a/include/linux/netpoll.h	2012-09-18 13:25:15.575750004 -0700
+++ b/include/linux/netpoll.h	2012-09-18 13:29:16.245323347 -0700
@@ -66,10 +66,16 @@ static inline void netpoll_send_skb(stru
 
 
 #ifdef CONFIG_NETPOLL
+extern struct static_key netpoll_needed;
+
 static inline bool netpoll_rx_on(struct sk_buff *skb)
 {
-	struct netpoll_info *npinfo = rcu_dereference_bh(skb->dev->npinfo);
+	struct netpoll_info *npinfo;
+
+	if (static_key_true(&netpoll_needed))
+		return false;
 
+	npinfo = rcu_dereference_bh(skb->dev->npinfo);
 	return npinfo && (!list_empty(&npinfo->rx_np) || npinfo->rx_flags);
 }
 
@@ -79,12 +85,14 @@ static inline bool netpoll_rx(struct sk_
 	unsigned long flags;
 	bool ret = false;
 
-	local_irq_save(flags);
+	if (static_key_true(&netpoll_needed))
+		return false;
 
-	if (!netpoll_rx_on(skb))
+	local_irq_save(flags);
+	npinfo = rcu_dereference_bh(skb->dev->npinfo);
+	if (!npinfo || (list_empty(&npinfo->rx_np) && !npinfo->rx_flags))
 		goto out;
 
-	npinfo = rcu_dereference_bh(skb->dev->npinfo);
 	spin_lock(&npinfo->rx_lock);
 	/* check rx_flags again with the lock held */
 	if (npinfo->rx_flags && __netpoll_rx(skb, npinfo))
@@ -96,11 +104,15 @@ out:
 	return ret;
 }
 
-static inline int netpoll_receive_skb(struct sk_buff *skb)
+static inline bool netpoll_receive_skb(struct sk_buff *skb)
 {
+	if (static_key_true(&netpoll_needed))
+		return false;
+
 	if (!list_empty(&skb->dev->napi_list))
 		return netpoll_rx(skb);
-	return 0;
+
+	return false;
 }
 
 static inline void *netpoll_poll_lock(struct napi_struct *napi)
@@ -139,9 +151,9 @@ static inline bool netpoll_rx_on(struct
 {
 	return false;
 }
-static inline int netpoll_receive_skb(struct sk_buff *skb)
+static inline bool netpoll_receive_skb(struct sk_buff *skb)
 {
-	return 0;
+	return false;
 }
 static inline void *netpoll_poll_lock(struct napi_struct *napi)
 {
--- a/net/core/netpoll.c	2012-09-18 13:25:15.575750004 -0700
+++ b/net/core/netpoll.c	2012-09-18 13:26:44.330855089 -0700
@@ -67,6 +67,8 @@ module_param(carrier_timeout, uint, 0644
 #define np_notice(np, fmt, ...)				\
 	pr_notice("%s: " fmt, np->name, ##__VA_ARGS__)
 
+struct static_key netpoll_needed __read_mostly;
+
 static void queue_process(struct work_struct *work)
 {
 	struct netpoll_info *npinfo =
@@ -786,6 +788,8 @@ int __netpoll_setup(struct netpoll *np,
 		npinfo->rx_flags |= NETPOLL_RX_ENABLED;
 		list_add_tail(&np->rx, &npinfo->rx_np);
 		spin_unlock_irqrestore(&npinfo->rx_lock, flags);
+
+		static_key_slow_inc(&netpoll_needed);
 	}
 
 	/* last thing to do is link it to the net device structure */
@@ -926,8 +930,10 @@ void __netpoll_cleanup(struct netpoll *n
 	if (!list_empty(&npinfo->rx_np)) {
 		spin_lock_irqsave(&npinfo->rx_lock, flags);
 		list_del(&np->rx);
-		if (list_empty(&npinfo->rx_np))
+		if (list_empty(&npinfo->rx_np)) {
 			npinfo->rx_flags &= ~NETPOLL_RX_ENABLED;
+			static_key_slow_dec(&netpoll_needed);
+		}
 		spin_unlock_irqrestore(&npinfo->rx_lock, flags);
 	}
 

^ permalink raw reply

* BUG: TCPDUMP invalid cksum persists after disabling TCP cksum offload
From: Jamie Gloudon @ 2012-09-18 21:14 UTC (permalink / raw)
  To: netdev
In-Reply-To: <1347998905.2685.29.camel@bwh-desktop.uk.solarflarecom.com>

Hello,
   I am seeing that tx checksum offload appears to be still running after disabling the feature with ethtool. I'm using kernel 3.6.0-rc6 and the latest ethtool from the git repo. 
 
The default settings on my e1000e NIC:
# ethtool -k eth1 | grep ': on'
 rx-checksumming: on
 tx-checksumming: on
        tx-checksum-ip-generic: on
 scatter-gather: on
         tx-scatter-gather: on
 tcp-segmentation-offload: on
         tx-tcp-segmentation: on
         tx-tcp6-segmentation: on
 generic-segmentation-offload: on
 generic-receive-offload: on
 rx-vlan-offload: on
 tx-vlan-offload: on
 receive-hashing: on
 highdma: on [fixed]
 rx-vlan-filter: on [fixed]
 tx-nocache-copy: on
 
The results after disabling tcp cksum offload feature:
# ethtool -K eth1 tx off
Actual changes:
 tx-checksumming: off
         tx-checksum-ip-generic: off
 scatter-gather: off
         tx-scatter-gather: off [requested on]
 tcp-segmentation-offload: off
         tx-tcp-segmentation: off [requested on]
         tx-tcp6-segmentation: off [requested on]
 generic-segmentation-offload: off [requested on]
 
However, in tcpdump, I'm still observing incorrect tcp checksum:
14:44:38.838711 IP (tos 0x10, ttl 64, id 45798, offset 0, flags [DF], proto TCP
(6), length 60)
     1.1.1.2.59748 > 1.1.1.1.23: Flags [S], cksum 0x0433 (incorrect -> 0x4137), seq 318222122, win 14600, options [mss 1460,sackOK,TS val 5447116 ecr 0,nop,wscale 7], length 0
 
Is this behaviour valid? I'm quite baffled.

Regards,
Jamie Gloudon

^ permalink raw reply

* Re: [PATCH v2 net-next 0/4] ipv6: fix the reassembly expire code in nf_conntrack
From: David Miller @ 2012-09-18 21:44 UTC (permalink / raw)
  To: amwang; +Cc: netdev, netfilter-devel, herbert
In-Reply-To: <1347942582-23962-1-git-send-email-amwang@redhat.com>

From: Cong Wang <amwang@redhat.com>
Date: Tue, 18 Sep 2012 12:29:38 +0800

> V2: use IS_ENABLED(CONFIG_IPV6) to fix a build error
>     rebase to latest net-next
> 
> ipv6: add a new namespace for nf_conntrack_reasm
> ipv6: unify conntrack reassembly expire code with standard one
> ipv6: make ip6_frag_nqueues() and ip6_frag_mem() static
> ipv6: unify fragment thresh handling code
> 
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: "David S. Miller" <davem@davemloft.net>
> Signed-off-by: Cong Wang <amwang@redhat.com>

Please address Pedro's feedback and resubmit, thanks.

^ permalink raw reply

* Re: [PATCH v2 net-next 0/4] ipv6: fix the reassembly expire code in nf_conntrack
From: David Miller @ 2012-09-18 21:46 UTC (permalink / raw)
  To: amwang; +Cc: netdev, netfilter-devel, herbert
In-Reply-To: <20120918.174422.676733596356822897.davem@davemloft.net>

From: David Miller <davem@davemloft.net>
Date: Tue, 18 Sep 2012 17:44:22 -0400 (EDT)

> From: Cong Wang <amwang@redhat.com>
> Date: Tue, 18 Sep 2012 12:29:38 +0800
> 
>> V2: use IS_ENABLED(CONFIG_IPV6) to fix a build error
>>     rebase to latest net-next
>> 
>> ipv6: add a new namespace for nf_conntrack_reasm
>> ipv6: unify conntrack reassembly expire code with standard one
>> ipv6: make ip6_frag_nqueues() and ip6_frag_mem() static
>> ipv6: unify fragment thresh handling code
>> 
>> Cc: Herbert Xu <herbert@gondor.apana.org.au>
>> Cc: "David S. Miller" <davem@davemloft.net>
>> Signed-off-by: Cong Wang <amwang@redhat.com>
> 
> Please address Pedro's feedback and resubmit, thanks.

Of course I meant "Pablo", and I meant to reply to v3 of your patches,
sorry :-)

^ permalink raw reply

* Re: BUG: TCPDUMP invalid cksum persists after disabling TCP cksum offload
From: Vijay Subramanian @ 2012-09-18 21:46 UTC (permalink / raw)
  To: Jamie Gloudon; +Cc: netdev
In-Reply-To: <20120918211423.GA19115@darkstar>

> The results after disabling tcp cksum offload feature:
> # ethtool -K eth1 tx off

Instead of this, can you try
# ethtool -K eth1 tso off


Vijay

^ permalink raw reply

* Re: BUG: TCPDUMP invalid cksum persists after disabling TCP cksum offload
From: Rick Jones @ 2012-09-18 21:54 UTC (permalink / raw)
  To: Vijay Subramanian; +Cc: Jamie Gloudon, netdev
In-Reply-To: <CAGK4HS9LSAGJ4amNK-rWKFNz=ZCVLkQm4sWABhY5C+6DBWsmUA@mail.gmail.com>

On 09/18/2012 02:46 PM, Vijay Subramanian wrote:
>> The results after disabling tcp cksum offload feature:
>> # ethtool -K eth1 tx off
>
> Instead of this, can you try
> # ethtool -K eth1 tso off

Doesn't TSO depend on TX CKO being enabled?  That is, if TX CKO were 
disabled, shouldn't TSO have been implicitly disabled at the same time?

rick jones

^ permalink raw reply

* Re: BUG: TCPDUMP invalid cksum persists after disabling TCP cksum offload
From: Jamie Gloudon @ 2012-09-18 22:20 UTC (permalink / raw)
  To: Rick Jones; +Cc: Vijay Subramanian, netdev
In-Reply-To: <5058ED9E.1000902@hp.com>

Rick is correct. Disabling TX CKO also disable TSO. You can see that in
my ethtool output.

On Tue, Sep 18, 2012 at 02:54:38PM -0700, Rick Jones wrote:
> On 09/18/2012 02:46 PM, Vijay Subramanian wrote:
> >>The results after disabling tcp cksum offload feature:
> >># ethtool -K eth1 tx off
> >
> >Instead of this, can you try
> ># ethtool -K eth1 tso off
> 
> Doesn't TSO depend on TX CKO being enabled?  That is, if TX CKO were
> disabled, shouldn't TSO have been implicitly disabled at the same time?
> 
> rick jones

^ permalink raw reply

* Re: [PATCH 1/5] ucc_geth: Reduce IRQ off in xmit path
From: Francois Romieu @ 2012-09-18 22:39 UTC (permalink / raw)
  To: Joakim Tjernlund; +Cc: netdev
In-Reply-To: <1347987385-19071-1-git-send-email-Joakim.Tjernlund@transmode.se>

Joakim Tjernlund <Joakim.Tjernlund@transmode.se> :
> Currently ucc_geth_start_xmit wraps IRQ off for the
> whole body just to be safe.
> Reduce the IRQ off period to a minimum.

The driver does not do much work in its irq handler. You may as well
convert it to the usual tg3-ish locking style (i.e. almost no locking).

-- 
Ueimor

^ 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