* Re: [PATCH] can: c_can_pci: limit compilation to archs with clock support
From: David Miller @ 2012-06-20 9:54 UTC (permalink / raw)
To: mkl; +Cc: netdev, linux-can, federico.vaga
In-Reply-To: <1340185688-9454-1-git-send-email-mkl@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Wed, 20 Jun 2012 11:48:08 +0200
> In commit:
>
> 5b92da0 c_can_pci: generic module for C_CAN/D_CAN on PCI
>
> the c_can_pci driver has been added. It uses clk_*() functions
> unconditionally, resulting in a link error on archs without
> clock support. This patch adds a "depends on HAVE_CLK" to the
> Kconfig symbol.
This is an unreasonable change and I just explained why in my email to
Frederico, did you not see it?
He says that this driver was only tested on an architecture that
currently doesn't even have clock support in any existing tree, and
therefore completely relies upon local changes they have to add clock
support to that platform.
Which means you're change is restricting compilation of this driver to
platforms the driver was never, ever, tested on.
Can you see what a complete joke this is?
^ permalink raw reply
* RE: [PATCH] netxen: Error return off by one in 'netxen_nic_set_pauseparam()'.
From: Rajesh Borundia @ 2012-06-20 9:51 UTC (permalink / raw)
To: santosh prasad nayak, Dan Carpenter
Cc: Sony Chacko, netdev, kernel-janitors@vger.kernel.org
In-Reply-To: <CAOD=uF6Oe1KZqmtUpY57u9GJh9BqxoK0DP0n4yP_DrMUjfXbCQ@mail.gmail.com>
_______________________________________
From: santosh prasad nayak [santoshprasadnayak@gmail.com]
Sent: Wednesday, June 20, 2012 1:29 PM
To: Dan Carpenter; Rajesh Borundia
Cc: Sony Chacko; netdev; kernel-janitors@vger.kernel.org
Subject: Re: [PATCH] netxen: Error return off by one in 'netxen_nic_set_pauseparam()'.
On Wed, Jun 20, 2012 at 1:14 PM, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> On Wed, Jun 20, 2012 at 12:57:39PM +0530, santosh nayak wrote:
>> From: Santosh Nayak <santoshprasadnayak@gmail.com>
>>
>> There are 'NETXEN_NIU_MAX_GBE_PORTS' GBE ports. Port indexing starts
>> from zero.
>> Hence we should also return error for "port == NETXEN_NIU_MAX_GBE_PORTS"
>>
>
> I don't know this code well enough to say if you are right or not,
> but what about for port == NETXEN_NIU_MAX_XG_PORTS a few lines later
> in both functions?
I think "for port == NETXEN_NIU_MAX_XG_PORTS" error should be returned.
@Rajesh,
Can you please comment on it ?
regards
santosh
>
> regards,
> dan carpenter
>
Yes error should be returned for both port == NETXEN_NIU_MAX_XG_PORTS and
port == NETXEN_NIU_MAX_GBE_PORTS.
Rajesh
^ permalink raw reply
* Re: linux-next: build failure after merge of the net-next tree
From: David Miller @ 2012-06-20 9:58 UTC (permalink / raw)
To: federico.vaga
Cc: mkl, bhupesh.sharma, sfr, netdev, linux-next, linux-kernel,
giancarlo.asnaghi, wg
In-Reply-To: <5059693.iaLYtpk3E4@harkonnen>
From: Federico Vaga <federico.vaga@gmail.com>
Date: Wed, 20 Jun 2012 11:59:26 +0200
>> Then the driver should NEVER have been submitted without the
>> required infrastructure in place first.
>
> This particular driver don't use the clk framework at the moment. I put
> that lines about clk to try to be generic as possibile, but I see that I
> made a mistake: I'm sorry.
Why would you try to be generic by using an interface currently
only available on certain platforms?
That is how you make drivers non-portable, and not generic.
^ permalink raw reply
* Re: linux-next: build failure after merge of the net-next tree
From: Federico Vaga @ 2012-06-20 9:59 UTC (permalink / raw)
To: David Miller
Cc: mkl, bhupesh.sharma, sfr, netdev, linux-next, linux-kernel,
giancarlo.asnaghi, wg
In-Reply-To: <20120620.020611.1696375957120854262.davem@davemloft.net>
> Then the driver should NEVER have been submitted without the
> required infrastructure in place first.
This particular driver don't use the clk framework at the moment. I put
that lines about clk to try to be generic as possibile, but I see that I
made a mistake: I'm sorry. An alternative solution to HAVE_CLK
dependency can be: remove the clk_* lines because actualy nobody use
them. In the future, if our c_can migrate to clk and our clk framework
is accepted in the kernel, we can re-add the clk_* lines.
--
Federico Vaga
^ permalink raw reply
* Re: 10GBE performance drop with net.ipv4.tcp_timestamps=0
From: Eric Dumazet @ 2012-06-20 10:06 UTC (permalink / raw)
To: Stefan Priebe - Profihost AG; +Cc: Linux Netdev List
In-Reply-To: <4FE19CFC.8030408@profihost.ag>
On Wed, 2012-06-20 at 11:50 +0200, Stefan Priebe - Profihost AG wrote:
> Am 20.06.2012 11:47, schrieb Eric Dumazet:
> > On Wed, 2012-06-20 at 11:33 +0200, Stefan Priebe - Profihost AG wrote:
> >
> >> Sure. In that case i get 4Gbit/s in both variants. I also tried two
> >> other different machines same result.
> >>
> >
> > So 3.5 on receiver is the problem, it seems ?
> Yes.
>
> > And you checked all the stuff about irq affinities, i presume, since a
> > lot of things might have changed between 2.6.32 and 3.5 ?
>
> It is a single core E5 Xeon - i've set the affinity like this:
And you still have the retransmits in "netstat -s" output ?
Might be a firmware or pci issue, I have same cards but no problem here.
Check LRO is on ?
ethtool -k eth2
^ permalink raw reply
* Re: [PATCH] can: c_can_pci: limit compilation to archs with clock support
From: Marc Kleine-Budde @ 2012-06-20 10:10 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-can, federico.vaga
In-Reply-To: <20120620.025452.2203668280120884694.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1436 bytes --]
On 06/20/2012 11:54 AM, David Miller wrote:
> From: Marc Kleine-Budde <mkl@pengutronix.de>
> Date: Wed, 20 Jun 2012 11:48:08 +0200
>
>> In commit:
>>
>> 5b92da0 c_can_pci: generic module for C_CAN/D_CAN on PCI
>>
>> the c_can_pci driver has been added. It uses clk_*() functions
>> unconditionally, resulting in a link error on archs without
>> clock support. This patch adds a "depends on HAVE_CLK" to the
>> Kconfig symbol.
>
> This is an unreasonable change and I just explained why in my email to
> Frederico, did you not see it?
I send that mail before I received Frederico's and your Mail.
> He says that this driver was only tested on an architecture that
> currently doesn't even have clock support in any existing tree, and
> therefore completely relies upon local changes they have to add clock
> support to that platform.
>
> Which means you're change is restricting compilation of this driver to
> platforms the driver was never, ever, tested on.
>
> Can you see what a complete joke this is?
I think we finally can see the big picture now; I'm preparing a patch
which removes the clk_*() functions.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply
* Re: [PATCH] can: c_can_pci: limit compilation to archs with clock support
From: David Miller @ 2012-06-20 10:12 UTC (permalink / raw)
To: mkl; +Cc: netdev, linux-can, federico.vaga
In-Reply-To: <4FE1A1A1.3000105@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Wed, 20 Jun 2012 12:10:41 +0200
> I think we finally can see the big picture now; I'm preparing a patch
> which removes the clk_*() functions.
Thank you.
^ permalink raw reply
* Re: [PATCH] usbnet: Activate halt interrupt endpoint before re-submit URB
From: Ming Lei @ 2012-06-20 10:15 UTC (permalink / raw)
To: Oliver Neukum
Cc: Huajun Li, David Miller, stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz,
linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <201206201058.55519.oneukum-l3A5Bk7waGM@public.gmane.org>
On Wed, Jun 20, 2012 at 4:58 PM, Oliver Neukum <oneukum-l3A5Bk7waGM@public.gmane.org> wrote:
> Am Mittwoch, 20. Juni 2012, 10:07:55 schrieb Ming Lei:
>> BTW, maybe it is better to add below
>>
>> usbnet_defer_kevent(dev, EVENT_STS_HALT);
>>
>> for -EPIPE returned from usb_urb_submit if it will be resent.
>
> Why? If it failed once it'll probably also fail the next time.
-EPIPE just means the endpoint is halted, either from usb_urb_submit
or urb->status, so the HALT should be cleared in the situation.
> In that case we'd need to do something more intrusive
> like resetting the device, but that cannot be done well
> in the generic usbnet part.
IMO, resetting is not needed for -EPIPE, but may be needed for
-EPROTO failure.
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] ipv4: Early TCP socket demux.
From: David Miller @ 2012-06-20 10:15 UTC (permalink / raw)
To: eric.dumazet; +Cc: shemminger, netdev
In-Reply-To: <20120619.231412.1236237191660427779.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Tue, 19 Jun 2012 23:14:12 -0700 (PDT)
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Wed, 20 Jun 2012 07:59:00 +0200
>
>> On Tue, 2012-06-19 at 21:46 -0700, David Miller wrote:
>>
>>> These numbers can be decreased further, because since we're already
>>> looking at the TCP header we can pre-cook the TCP control block in the
>>> SKB and skip much of the stuff that tcp_v4_rcv() does since we've done
>>> it already in the early demux code.
>>
>> It could be done at GRO level and remove one another demux.
>>
>> As routers probably have no use of GRO, no need of additional knob.
>
> That's a great idea.
Here's what I have so far, the ipv6 implementation we get nearly for
free :-)
Initially I tried to use ->gro_complete() for this as it was more
natural, but we abort before we get there for a lot of cases where we
want to use the early demux and cached route (ACKs, FINs, sub-mss
sized packets, etc.)
diff --git a/include/net/protocol.h b/include/net/protocol.h
index 967b926..a1b1b53 100644
--- a/include/net/protocol.h
+++ b/include/net/protocol.h
@@ -37,7 +37,6 @@
/* This is used to register protocols. */
struct net_protocol {
- int (*early_demux)(struct sk_buff *skb);
int (*handler)(struct sk_buff *skb);
void (*err_handler)(struct sk_buff *skb, u32 info);
int (*gso_send_check)(struct sk_buff *skb);
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 5b21522..c1b5626 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -2956,6 +2956,12 @@ int skb_gro_receive(struct sk_buff **head, struct sk_buff *skb)
return -ENOMEM;
__copy_skb_header(nskb, p);
+ if (p->sk) {
+ nskb->sk = p->sk;
+ nskb->destructor = p->destructor;
+ p->sk = NULL;
+ p->destructor = NULL;
+ }
nskb->mac_len = p->mac_len;
skb_reserve(nskb, headroom);
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index 07a02f6..0aabad7 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -1519,7 +1519,6 @@ static const struct net_protocol igmp_protocol = {
#endif
static const struct net_protocol tcp_protocol = {
- .early_demux = tcp_v4_early_demux,
.handler = tcp_v4_rcv,
.err_handler = tcp_v4_err,
.gso_send_check = tcp_v4_gso_send_check,
diff --git a/net/ipv4/ip_input.c b/net/ipv4/ip_input.c
index 93b092c..c4fe1d2 100644
--- a/net/ipv4/ip_input.c
+++ b/net/ipv4/ip_input.c
@@ -323,32 +323,19 @@ static int ip_rcv_finish(struct sk_buff *skb)
* how the packet travels inside Linux networking.
*/
if (skb_dst(skb) == NULL) {
- const struct net_protocol *ipprot;
- int protocol = iph->protocol;
- int err;
-
- rcu_read_lock();
- ipprot = rcu_dereference(inet_protos[protocol]);
- err = -ENOENT;
- if (ipprot && ipprot->early_demux)
- err = ipprot->early_demux(skb);
- rcu_read_unlock();
-
- if (err) {
- err = ip_route_input_noref(skb, iph->daddr, iph->saddr,
- iph->tos, skb->dev);
- if (unlikely(err)) {
- if (err == -EHOSTUNREACH)
- IP_INC_STATS_BH(dev_net(skb->dev),
- IPSTATS_MIB_INADDRERRORS);
- else if (err == -ENETUNREACH)
- IP_INC_STATS_BH(dev_net(skb->dev),
- IPSTATS_MIB_INNOROUTES);
- else if (err == -EXDEV)
- NET_INC_STATS_BH(dev_net(skb->dev),
- LINUX_MIB_IPRPFILTER);
- goto drop;
- }
+ int err = ip_route_input_noref(skb, iph->daddr, iph->saddr,
+ iph->tos, skb->dev);
+ if (unlikely(err)) {
+ if (err == -EHOSTUNREACH)
+ IP_INC_STATS_BH(dev_net(skb->dev),
+ IPSTATS_MIB_INADDRERRORS);
+ else if (err == -ENETUNREACH)
+ IP_INC_STATS_BH(dev_net(skb->dev),
+ IPSTATS_MIB_INNOROUTES);
+ else if (err == -EXDEV)
+ NET_INC_STATS_BH(dev_net(skb->dev),
+ LINUX_MIB_IPRPFILTER);
+ goto drop;
}
}
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 13857df..2a483ad 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1671,52 +1671,6 @@ csum_err:
}
EXPORT_SYMBOL(tcp_v4_do_rcv);
-int tcp_v4_early_demux(struct sk_buff *skb)
-{
- struct net *net = dev_net(skb->dev);
- const struct iphdr *iph;
- const struct tcphdr *th;
- struct sock *sk;
- int err;
-
- err = -ENOENT;
- if (skb->pkt_type != PACKET_HOST)
- goto out_err;
-
- if (!pskb_may_pull(skb, ip_hdrlen(skb) + sizeof(struct tcphdr)))
- goto out_err;
-
- iph = ip_hdr(skb);
- th = (struct tcphdr *) ((char *)iph + ip_hdrlen(skb));
-
- if (th->doff < sizeof(struct tcphdr) / 4)
- goto out_err;
-
- if (!pskb_may_pull(skb, ip_hdrlen(skb) + th->doff * 4))
- goto out_err;
-
- sk = __inet_lookup_established(net, &tcp_hashinfo,
- iph->saddr, th->source,
- iph->daddr, th->dest,
- skb->dev->ifindex);
- if (sk) {
- skb->sk = sk;
- skb->destructor = sock_edemux;
- if (sk->sk_state != TCP_TIME_WAIT) {
- struct dst_entry *dst = sk->sk_rx_dst;
- if (dst)
- dst = dst_check(dst, 0);
- if (dst) {
- skb_dst_set_noref(skb, dst);
- err = 0;
- }
- }
- }
-
-out_err:
- return err;
-}
-
/*
* From tcp_input.c
*/
@@ -2576,6 +2530,7 @@ void tcp4_proc_exit(void)
struct sk_buff **tcp4_gro_receive(struct sk_buff **head, struct sk_buff *skb)
{
const struct iphdr *iph = skb_gro_network_header(skb);
+ struct sk_buff **pp;
switch (skb->ip_summed) {
case CHECKSUM_COMPLETE:
@@ -2591,7 +2546,36 @@ struct sk_buff **tcp4_gro_receive(struct sk_buff **head, struct sk_buff *skb)
return NULL;
}
- return tcp_gro_receive(head, skb);
+ pp = tcp_gro_receive(head, skb);
+
+ if (!NAPI_GRO_CB(skb)->same_flow) {
+ const struct tcphdr *th = tcp_hdr(skb);
+ struct net_device *dev = skb->dev;
+ struct sock *sk;
+
+ sk = __inet_lookup_established(dev_net(dev), &tcp_hashinfo,
+ iph->saddr, th->source,
+ iph->daddr, th->dest,
+ dev->ifindex);
+ if (sk) {
+ skb_orphan(skb);
+ skb->sk = sk;
+ skb->destructor = sock_edemux;
+ if (!skb_dst(skb) &&
+ sk->sk_state != TCP_TIME_WAIT) {
+ struct dst_entry *dst = sk->sk_rx_dst;
+ if (dst)
+ dst = dst_check(dst, 0);
+ if (dst) {
+ struct rtable *rt = (struct rtable *) dst;
+
+ if (rt->rt_iif == dev->ifindex)
+ skb_dst_set_noref(skb, dst);
+ }
+ }
+ }
+ }
+ return pp;
}
int tcp4_gro_complete(struct sk_buff *skb)
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index 26a8862..b8ea463 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -797,6 +797,7 @@ static struct sk_buff **tcp6_gro_receive(struct sk_buff **head,
struct sk_buff *skb)
{
const struct ipv6hdr *iph = skb_gro_network_header(skb);
+ struct sk_buff **pp;
switch (skb->ip_summed) {
case CHECKSUM_COMPLETE:
@@ -812,7 +813,32 @@ static struct sk_buff **tcp6_gro_receive(struct sk_buff **head,
return NULL;
}
- return tcp_gro_receive(head, skb);
+ pp = tcp_gro_receive(head, skb);
+
+ if (!NAPI_GRO_CB(skb)->same_flow) {
+ const struct tcphdr *th = tcp_hdr(skb);
+ struct net_device *dev = skb->dev;
+ struct sock *sk;
+
+ sk = __inet6_lookup_established(dev_net(dev), &tcp_hashinfo,
+ &iph->saddr, th->source,
+ &iph->daddr, th->dest,
+ dev->ifindex);
+ if (sk) {
+ skb_orphan(skb);
+ skb->sk = sk;
+ skb->destructor = sock_edemux;
+ if (!skb_dst(skb) &&
+ sk->sk_state != TCP_TIME_WAIT) {
+ struct dst_entry *dst = sk->sk_rx_dst;
+ if (dst)
+ dst = dst_check(dst, 0);
+ if (dst)
+ skb_dst_set(skb, dst);
+ }
+ }
+ }
+ return pp;
}
static int tcp6_gro_complete(struct sk_buff *skb)
^ permalink raw reply related
* Re: [PATCH] netxen: Error return off by one in 'netxen_nic_set_pauseparam()'.
From: santosh prasad nayak @ 2012-06-20 10:16 UTC (permalink / raw)
To: Rajesh Borundia
Cc: Dan Carpenter, Sony Chacko, netdev,
kernel-janitors@vger.kernel.org
In-Reply-To: <13A253B3F9BEFE43B93C09CF75F63CAA81A886EF19@MNEXMB1.qlogic.org>
On Wed, Jun 20, 2012 at 3:21 PM, Rajesh Borundia
<rajesh.borundia@qlogic.com> wrote:
> _______________________________________
> From: santosh prasad nayak [santoshprasadnayak@gmail.com]
> Sent: Wednesday, June 20, 2012 1:29 PM
> To: Dan Carpenter; Rajesh Borundia
> Cc: Sony Chacko; netdev; kernel-janitors@vger.kernel.org
> Subject: Re: [PATCH] netxen: Error return off by one in 'netxen_nic_set_pauseparam()'.
>
> On Wed, Jun 20, 2012 at 1:14 PM, Dan Carpenter <dan.carpenter@oracle.com> wrote:
>> On Wed, Jun 20, 2012 at 12:57:39PM +0530, santosh nayak wrote:
>>> From: Santosh Nayak <santoshprasadnayak@gmail.com>
>>>
>>> There are 'NETXEN_NIU_MAX_GBE_PORTS' GBE ports. Port indexing starts
>>> from zero.
>>> Hence we should also return error for "port == NETXEN_NIU_MAX_GBE_PORTS"
>>>
>>
>> I don't know this code well enough to say if you are right or not,
>> but what about for port == NETXEN_NIU_MAX_XG_PORTS a few lines later
>> in both functions?
>
>
> I think "for port == NETXEN_NIU_MAX_XG_PORTS" error should be returned.
>
>
> @Rajesh,
>
> Can you please comment on it ?
>
>
> regards
> santosh
>
>>
>> regards,
>> dan carpenter
>>
>
> Yes error should be returned for both port == NETXEN_NIU_MAX_XG_PORTS and
> port == NETXEN_NIU_MAX_GBE_PORTS.
Ok.
The current patch is for GBE port.
For XG port I will send another patch.
regards
santosh
>
>
> Rajesh
>
^ permalink raw reply
* Re: linux-next: build failure after merge of the net-next tree
From: Federico Vaga @ 2012-06-20 10:17 UTC (permalink / raw)
To: David Miller
Cc: mkl, bhupesh.sharma, sfr, netdev, linux-next, linux-kernel,
giancarlo.asnaghi, wg
In-Reply-To: <20120620.025837.721158723130014230.davem@davemloft.net>
> Why would you try to be generic by using an interface currently
> only available on certain platforms?
I know, I was wrong.
> That is how you make drivers non-portable, and not generic.
Now is fixed in my mind; I learn the lesson.
--
Federico Vaga
^ permalink raw reply
* Re: [PATCH] can: c_can_pci: limit compilation to archs with clock support
From: Federico Vaga @ 2012-06-20 10:18 UTC (permalink / raw)
To: Marc Kleine-Budde; +Cc: David Miller, netdev, linux-can
In-Reply-To: <4FE1A1A1.3000105@pengutronix.de>
> I think we finally can see the big picture now; I'm preparing a patch
> which removes the clk_*() functions.
Thank you, and sorry for the big trouble
--
Federico Vaga
^ permalink raw reply
* Re: [PATCH] usbnet: Activate halt interrupt endpoint before re-submit URB
From: Oliver Neukum @ 2012-06-20 10:21 UTC (permalink / raw)
To: Ming Lei; +Cc: Huajun Li, David Miller, stern, linux-usb, netdev
In-Reply-To: <CACVXFVMy6Hrqgw6rmAXv5YXD86sLF+FUPTRRcXKs40uwN6ioCg@mail.gmail.com>
Am Mittwoch, 20. Juni 2012, 12:15:25 schrieb Ming Lei:
> On Wed, Jun 20, 2012 at 4:58 PM, Oliver Neukum <oneukum@suse.de> wrote:
> > Am Mittwoch, 20. Juni 2012, 10:07:55 schrieb Ming Lei:
> >> BTW, maybe it is better to add below
> >>
> >> usbnet_defer_kevent(dev, EVENT_STS_HALT);
> >>
> >> for -EPIPE returned from usb_urb_submit if it will be resent.
> >
> > Why? If it failed once it'll probably also fail the next time.
>
> -EPIPE just means the endpoint is halted, either from usb_urb_submit
> or urb->status, so the HALT should be cleared in the situation.
It probably was halted and cleared. However that you cleared
a halt doesn't mean that the reason for stalling went away.
So you must cope with an endpoint being halted again right after
it was cleared.
> > In that case we'd need to do something more intrusive
> > like resetting the device, but that cannot be done well
> > in the generic usbnet part.
>
> IMO, resetting is not needed for -EPIPE, but may be needed for
> -EPROTO failure.
We don't need it for a single failure, but what else would we do
if we keep getting -EPIPE?
Regards
Oliver
^ permalink raw reply
* Re: linux-next: build failure after merge of the net-next tree
From: Stephen Rothwell @ 2012-06-20 10:26 UTC (permalink / raw)
To: David Miller
Cc: viresh.kumar2, bhupesh.sharma, netdev, linux-next, linux-kernel,
federico.vaga, giancarlo.asnaghi, wg, mkl, spear-devel,
Andrew Morton
In-Reply-To: <20120620.012037.783895812206310043.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1139 bytes --]
Hi all,
On Wed, 20 Jun 2012 01:20:37 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
>
> From: viresh kumar <viresh.kumar2@arm.com>
> Date: Wed, 20 Jun 2012 09:08:34 +0100
>
> > Please see following patchset from me, that got applied in linux-next
> >
> > https://lkml.org/lkml/2012/4/24/154
> >
> > Please check if this patchset is present in your build repo. I believe it should be
> > there. If it is, then you shouldn't get these errors.
>
> Well, then Stephen shouldn't get those errors either.
>
> But obviously he did.
>
> But all of this talk about changes existing only in linux-next is
> entirely moot. Because The damn thing MUST build independently inside
> of net-next which doesn't have those clock layer changes.
>
> Someone send me a clean fix for net-next now.
I get those errors because those patches are in the akpm tree which is
merged after everything else ...
One possibility is to put those changes in another (stable) tree and
merge that into the net-next tree (and any other tree that needs it).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: build failure after merge of the net-next tree
From: Marc Kleine-Budde @ 2012-06-20 10:33 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Miller, viresh.kumar2, bhupesh.sharma, netdev, linux-next,
linux-kernel, federico.vaga, giancarlo.asnaghi, wg, spear-devel,
Andrew Morton
In-Reply-To: <20120620202604.407af721f746045ae00c8268@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 1798 bytes --]
On 06/20/2012 12:26 PM, Stephen Rothwell wrote:
> Hi all,
>
> On Wed, 20 Jun 2012 01:20:37 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
>>
>> From: viresh kumar <viresh.kumar2@arm.com>
>> Date: Wed, 20 Jun 2012 09:08:34 +0100
>>
>>> Please see following patchset from me, that got applied in linux-next
>>>
>>> https://lkml.org/lkml/2012/4/24/154
>>>
>>> Please check if this patchset is present in your build repo. I believe it should be
>>> there. If it is, then you shouldn't get these errors.
>>
>> Well, then Stephen shouldn't get those errors either.
>>
>> But obviously he did.
>>
>> But all of this talk about changes existing only in linux-next is
>> entirely moot. Because The damn thing MUST build independently inside
>> of net-next which doesn't have those clock layer changes.
>>
>> Someone send me a clean fix for net-next now.
>
> I get those errors because those patches are in the akpm tree which is
> merged after everything else ...
>
> One possibility is to put those changes in another (stable) tree and
> merge that into the net-next tree (and any other tree that needs it).
We're about to remove the offending clk_*() functions from the driver,
as they are untested anyway. The hardware the driver was developed for
uses a hardcoded clock rate in the driver anyway, as it cannot be
retrieved from clock tree. As soon as there is hardware available that
will work with the clock tree, we can add those functions back.
Sorry for the noise,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply
* [PATCH] netxen : Error return off by one for XG port.
From: santosh nayak @ 2012-06-20 10:52 UTC (permalink / raw)
To: sony.chacko, rajesh.borundia; +Cc: netdev, kernel-janitors, Santosh Nayak
From: Santosh Nayak <santoshprasadnayak@gmail.com>
There are NETXEN_NIU_MAX_XG_PORTS ports.
Port indexing starts from zero.
Hence we should also return error for 'port == NETXEN_NIU_MAX_XG_PORTS'.
Signed-off-by: Santosh Nayak <santoshprasadnayak@gmail.com>
---
.../ethernet/qlogic/netxen/netxen_nic_ethtool.c | 4 ++--
drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic_ethtool.c b/drivers/net/ethernet/qlogic/netxen/netxen_nic_ethtool.c
index d4f179f..9103e3e 100644
--- a/drivers/net/ethernet/qlogic/netxen/netxen_nic_ethtool.c
+++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic_ethtool.c
@@ -511,7 +511,7 @@ netxen_nic_get_pauseparam(struct net_device *dev,
break;
}
} else if (adapter->ahw.port_type == NETXEN_NIC_XGBE) {
- if ((port < 0) || (port > NETXEN_NIU_MAX_XG_PORTS))
+ if ((port < 0) || (port >= NETXEN_NIU_MAX_XG_PORTS))
return;
pause->rx_pause = 1;
val = NXRD32(adapter, NETXEN_NIU_XG_PAUSE_CTL);
@@ -577,7 +577,7 @@ netxen_nic_set_pauseparam(struct net_device *dev,
}
NXWR32(adapter, NETXEN_NIU_GB_PAUSE_CTL, val);
} else if (adapter->ahw.port_type == NETXEN_NIC_XGBE) {
- if ((port < 0) || (port > NETXEN_NIU_MAX_XG_PORTS))
+ if ((port < 0) || (port >= NETXEN_NIU_MAX_XG_PORTS))
return -EIO;
val = NXRD32(adapter, NETXEN_NIU_XG_PAUSE_CTL);
if (port == 0) {
diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c b/drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c
index de96a94..946160f 100644
--- a/drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c
+++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c
@@ -365,7 +365,7 @@ static int netxen_niu_disable_xg_port(struct netxen_adapter *adapter)
if (NX_IS_REVISION_P3(adapter->ahw.revision_id))
return 0;
- if (port > NETXEN_NIU_MAX_XG_PORTS)
+ if (port >= NETXEN_NIU_MAX_XG_PORTS)
return -EINVAL;
mac_cfg = 0;
@@ -392,7 +392,7 @@ static int netxen_p2_nic_set_promisc(struct netxen_adapter *adapter, u32 mode)
u32 port = adapter->physical_port;
u16 board_type = adapter->ahw.board_type;
- if (port > NETXEN_NIU_MAX_XG_PORTS)
+ if (port >= NETXEN_NIU_MAX_XG_PORTS)
return -EINVAL;
mac_cfg = NXRD32(adapter, NETXEN_NIU_XGE_CONFIG_0 + (0x10000 * port));
--
1.7.4.4
^ permalink raw reply related
* Re: [PATCH] usbnet: Activate halt interrupt endpoint before re-submit URB
From: Ming Lei @ 2012-06-20 10:56 UTC (permalink / raw)
To: Oliver Neukum; +Cc: Huajun Li, David Miller, stern, linux-usb, netdev
In-Reply-To: <201206201221.37211.oneukum@suse.de>
On Wed, Jun 20, 2012 at 6:21 PM, Oliver Neukum <oneukum@suse.de> wrote:
> It probably was halted and cleared. However that you cleared
> a halt doesn't mean that the reason for stalling went away.
> So you must cope with an endpoint being halted again right after
> it was cleared.
I only suggested we should handle -EPIPE for usb_submit_urb
on interrupt endpoint, maybe it is the 1st handling, at least it is
per USB spec.
Also from implementation of usb gadget device, generally
ClearFeature(HALT) is to clear the some halt related flag of
endpoint hardware.
Looks the reasons of interrupt endpoint stalling is invisible
for usbnet driver, so it is not easy to handle the situation
you described(halted and cleared repeatedly).
>
>> > In that case we'd need to do something more intrusive
>> > like resetting the device, but that cannot be done well
>> > in the generic usbnet part.
>>
>> IMO, resetting is not needed for -EPIPE, but may be needed for
>> -EPROTO failure.
>
> We don't need it for a single failure, but what else would we do
> if we keep getting -EPIPE?
Suppose the case will happen, what is the appropriate actions
usbnet should take on the failure? I am not sure RESET can deal
with it.
Also is it a actual failure case or only a theory case?
Thanks,
--
Ming Lei
^ permalink raw reply
* Re: [PATCH -v1 3/3] usbnet: handle remote wakeup asap
From: Sergei Shtylyov @ 2012-06-20 11:02 UTC (permalink / raw)
To: Ming Lei
Cc: David S. Miller, Greg Kroah-Hartman, Oliver Neukum,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1340176553-32225-4-git-send-email-ming.lei-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
Hello.
On 20-06-2012 11:15, Ming Lei wrote:
> If usbnet is resumed by remote wakeup, generally there are
> some packets comming to be handled, so allocate and submit
> rx URBs in usbnet_resume to avoid delays introduced by tasklet.
> Otherwise, usbnet may have been runtime suspended before the
> usbnet_bh is executed to schedule Rx URBs.
> Without the patch, usbnet can't recieve any packets from peer
> in runtime suspend state if runtime PM is enabled and
> autosuspend_delay is set as zero.
> Signed-off-by: Ming Lei<ming.lei-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
> ---
> drivers/net/usb/usbnet.c | 42 ++++++++++++++++++++++++++----------------
> 1 file changed, 26 insertions(+), 16 deletions(-)
> diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
> index 9bfa775..a89d6c5 100644
> --- a/drivers/net/usb/usbnet.c
> +++ b/drivers/net/usb/usbnet.c
> @@ -1201,6 +1201,21 @@ deferred:
> }
> EXPORT_SYMBOL_GPL(usbnet_start_xmit);
>
> +static void rx_alloc_submit(struct usbnet *dev, gfp_t flags)
> +{
> + struct urb *urb;
> + int i;
> +
> + /* don't refill the queue all at once */
> + for (i = 0; i< 10&& dev->rxq.qlen< RX_QLEN(dev); i++) {
> + urb = usb_alloc_urb(0, flags);
> + if (urb != NULL) {
> + if (rx_submit(dev, urb, flags) == -ENOLINK)
The above 2 *if* statements can be collapsed into single one.
> + return;
> + }
> + }
> +}
> +
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* From Captain Miller Peterson
From: Captain Miller Peterson @ 2012-06-20 10:53 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 31 bytes --]
(Find Details Of Mail Attached)
^ permalink raw reply
* Re: [PATCH v2] ipv4: Early TCP socket demux.
From: Eric Dumazet @ 2012-06-20 11:03 UTC (permalink / raw)
To: David Miller; +Cc: shemminger, netdev
In-Reply-To: <20120620.031543.1511134879638711616.davem@davemloft.net>
On Wed, 2012-06-20 at 03:15 -0700, David Miller wrote:
> Here's what I have so far, the ipv6 implementation we get nearly for
> free :-)
>
> Initially I tried to use ->gro_complete() for this as it was more
> natural, but we abort before we get there for a lot of cases where we
> want to use the early demux and cached route (ACKs, FINs, sub-mss
> sized packets, etc.)
>
Seems very good, I only have one remark :
> /*
> * From tcp_input.c
> */
> @@ -2576,6 +2530,7 @@ void tcp4_proc_exit(void)
> struct sk_buff **tcp4_gro_receive(struct sk_buff **head, struct sk_buff *skb)
> {
> const struct iphdr *iph = skb_gro_network_header(skb);
> + struct sk_buff **pp;
>
> switch (skb->ip_summed) {
> case CHECKSUM_COMPLETE:
> @@ -2591,7 +2546,36 @@ struct sk_buff **tcp4_gro_receive(struct sk_buff **head, struct sk_buff *skb)
> return NULL;
> }
>
> - return tcp_gro_receive(head, skb);
> + pp = tcp_gro_receive(head, skb);
> +
> + if (!NAPI_GRO_CB(skb)->same_flow) {
> + const struct tcphdr *th = tcp_hdr(skb);
> + struct net_device *dev = skb->dev;
> + struct sock *sk;
> +
> + sk = __inet_lookup_established(dev_net(dev), &tcp_hashinfo,
> + iph->saddr, th->source,
> + iph->daddr, th->dest,
> + dev->ifindex);
> + if (sk) {
> + skb_orphan(skb);
> + skb->sk = sk;
> + skb->destructor = sock_edemux;
> + if (!skb_dst(skb) &&
I am not sure we need the skb_dst(skb) test here, it should be NULL
anyway in GRO layer ? (loopback device don't use GRO ;) )
> + sk->sk_state != TCP_TIME_WAIT) {
> + struct dst_entry *dst = sk->sk_rx_dst;
> + if (dst)
> + dst = dst_check(dst, 0);
> + if (dst) {
> + struct rtable *rt = (struct rtable *) dst;
> +
> + if (rt->rt_iif == dev->ifindex)
> + skb_dst_set_noref(skb, dst);
> + }
> + }
> + }
> + }
> + return pp;
> }
>
> int tcp4_gro_complete(struct sk_buff *skb)
^ permalink raw reply
* Re: [PATCH 01/17] mm: sl[au]b: Add knowledge of PFMEMALLOC reserve pages
From: Sebastian Andrzej Siewior @ 2012-06-20 11:05 UTC (permalink / raw)
To: Mel Gorman
Cc: Andrew Morton, Linux-MM, Linux-Netdev, LKML, David Miller,
Neil Brown, Peter Zijlstra, Mike Christie, Eric B Munson
In-Reply-To: <1340184920-22288-2-git-send-email-mgorman@suse.de>
On Wed, Jun 20, 2012 at 10:35:04AM +0100, Mel Gorman wrote:
> [a.p.zijlstra@chello.nl: Original implementation]
> Signed-off-by: Mel Gorman <mgorman@suse.de>
> ---
> diff --git a/mm/slab.c b/mm/slab.c
> index e901a36..b190cac 100644
> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -1851,6 +1984,7 @@ static void kmem_freepages(struct kmem_cache *cachep, void *addr)
> while (i--) {
> BUG_ON(!PageSlab(page));
> __ClearPageSlab(page);
> + __ClearPageSlabPfmemalloc(page);
> page++;
> }
> if (current->reclaim_state)
> @@ -3120,16 +3254,19 @@ bad:
> diff --git a/mm/slub.c b/mm/slub.c
> index 8c691fa..43738c9 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -1414,6 +1418,7 @@ static void __free_slab(struct kmem_cache *s, struct page *page)
> -pages);
>
> __ClearPageSlab(page);
> + __ClearPageSlabPfmemalloc(page);
> reset_page_mapcount(page);
> if (current->reclaim_state)
> current->reclaim_state->reclaimed_slab += pages;
So you mention a change here in v11's changelog but I don't see it.
Sebastian
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: 10GBE performance drop with net.ipv4.tcp_timestamps=0
From: Eric Dumazet @ 2012-06-20 11:08 UTC (permalink / raw)
To: Stefan Priebe - Profihost AG; +Cc: Linux Netdev List
In-Reply-To: <1340186788.4604.857.camel@edumazet-glaptop>
On Wed, 2012-06-20 at 12:06 +0200, Eric Dumazet wrote:
> On Wed, 2012-06-20 at 11:50 +0200, Stefan Priebe - Profihost AG wrote:
> > Am 20.06.2012 11:47, schrieb Eric Dumazet:
> > > On Wed, 2012-06-20 at 11:33 +0200, Stefan Priebe - Profihost AG wrote:
> > >
> > >> Sure. In that case i get 4Gbit/s in both variants. I also tried two
> > >> other different machines same result.
> > >>
> > >
> > > So 3.5 on receiver is the problem, it seems ?
> > Yes.
> >
> > > And you checked all the stuff about irq affinities, i presume, since a
> > > lot of things might have changed between 2.6.32 and 3.5 ?
> >
> > It is a single core E5 Xeon - i've set the affinity like this:
>
> And you still have the retransmits in "netstat -s" output ?
>
> Might be a firmware or pci issue, I have same cards but no problem here.
>
> Check LRO is on ?
>
> ethtool -k eth2
>
Ah, your ethtool -S gives strange fdir_miss counts, you should ask Intel
guys help maybe...
^ permalink raw reply
* Re: [PATCH v2] ipv4: Early TCP socket demux.
From: David Miller @ 2012-06-20 11:09 UTC (permalink / raw)
To: eric.dumazet; +Cc: shemminger, netdev
In-Reply-To: <1340190206.4604.862.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 20 Jun 2012 13:03:26 +0200
> I am not sure we need the skb_dst(skb) test here, it should be NULL
> anyway in GRO layer ? (loopback device don't use GRO ;) )
Thanks, I was too lazy to check this and just assumed that a non-NULL
skb_dst(skb) was a very real possibility.
^ permalink raw reply
* Re: [PATCH -v1 3/3] usbnet: handle remote wakeup asap
From: Oliver Neukum @ 2012-06-20 11:24 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Ming Lei, David S. Miller, Greg Kroah-Hartman,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4FE1ADB4.4060302-Igf4POYTYCDQT0dZR+AlfA@public.gmane.org>
Am Mittwoch, 20. Juni 2012, 13:02:12 schrieb Sergei Shtylyov:
> > Without the patch, usbnet can't recieve any packets from peer
> > in runtime suspend state if runtime PM is enabled and
> > autosuspend_delay is set as zero.
>
> > Signed-off-by: Ming Lei<ming.lei-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
> > ---
> > drivers/net/usb/usbnet.c | 42 ++++++++++++++++++++++++++----------------
> > 1 file changed, 26 insertions(+), 16 deletions(-)
>
> > diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
> > index 9bfa775..a89d6c5 100644
> > --- a/drivers/net/usb/usbnet.c
> > +++ b/drivers/net/usb/usbnet.c
> > @@ -1201,6 +1201,21 @@ deferred:
> > }
> > EXPORT_SYMBOL_GPL(usbnet_start_xmit);
> >
> > +static void rx_alloc_submit(struct usbnet *dev, gfp_t flags)
> > +{
> > + struct urb *urb;
> > + int i;
> > +
> > + /* don't refill the queue all at once */
> > + for (i = 0; i< 10&& dev->rxq.qlen< RX_QLEN(dev); i++) {
> > + urb = usb_alloc_urb(0, flags);
> > + if (urb != NULL) {
> > + if (rx_submit(dev, urb, flags) == -ENOLINK)
>
> The above 2 if statements can be collapsed into single one.
>
That would not improve readability.
Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: linux-next: build failure after merge of the net-next tree
From: Mark Brown @ 2012-06-20 11:35 UTC (permalink / raw)
To: David Miller
Cc: bhupesh.sharma, sfr, netdev, linux-next, linux-kernel,
federico.vaga, giancarlo.asnaghi, wg, mkl
In-Reply-To: <20120619.214759.2265041580160751452.davem@davemloft.net>
On Tue, Jun 19, 2012 at 09:47:59PM -0700, David Miller wrote:
> From: Bhupesh SHARMA <bhupesh.sharma@st.com>
> > So, whether adding a check in Kconfig for HAVE_CLK be a proper
> > solution ? But that will limit the compilation of this driver for
> > only platforms which are ARM based.
> > One may need to support this driver on x86 like platforms also..
> Then x86 will need to provide clock operations, or there needs to
> be dummy ones for such platforms.
Not directly germane but I've been sending patches for this to the x86
guys for a little while though they're doing a /dev/null impression.
> This isn't rocket science.
The other option is that the clock API stubs itself out when not enabled
which is going into mainline (not sure quite where it is at the minute).
These sort of per-arch APIs should be a legacy thing, hopefully we'll
manage to squash them at some point and we should certainly work to
avoid introducing new ones.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox