* Re: [PATCH 0/4] netfilter updates for net-next (batch 3)
From: David Miller @ 2012-06-19 4:09 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <20120619033745.GA31405@1984>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Tue, 19 Jun 2012 05:37:45 +0200
> On Tue, Jun 19, 2012 at 05:16:25AM +0200, pablo@netfilter.org wrote:
> [...]
>> You can pull these changes from:
>>
>> git://1984.lsi.us.es/nf-next master
>
> Please, also take the small patch attached after this 4 patch series. It
> fixes one linking issue.
>
> Sorry, I'll put more care next time testing compilation options more
> extensively.
Done.
^ permalink raw reply
* Re: [PATCH] ipv4: Early TCP socket demux.
From: David Miller @ 2012-06-19 4:10 UTC (permalink / raw)
To: stephen.hemminger; +Cc: netdev
In-Reply-To: <a22edf13-1bf5-49fb-8ebe-05054f68c129@tahiti.vyatta.com>
From: Stephen Hemminger <stephen.hemminger@vyatta.com>
Date: Mon, 18 Jun 2012 21:03:26 -0700 (PDT)
> David, I understand it, Eric understands it, and maybe one or
> two others. But on the principal of what is "good for the goose
> is good for the gander", you really need to provide a reasonable
> change log entry. Just because you are the network maintainer
> doesn't mean you get to skip all the documented rules about submitting
> patches.
This wasn't going to be the final commit log entry.
^ permalink raw reply
* Re: [PATCH] ipv4: Early TCP socket demux.
From: Changli Gao @ 2012-06-19 4:13 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev
In-Reply-To: <a22edf13-1bf5-49fb-8ebe-05054f68c129@tahiti.vyatta.com>
On Tue, Jun 19, 2012 at 12:03 PM, Stephen Hemminger
<stephen.hemminger@vyatta.com> wrote:
>
>>
>> You know you want it.
>>
>> Signed-off-by: David S. Miller <davem@davemloft.net>
>
> David, I understand it, Eric understands it, and maybe one or
> two others. But on the principal of what is "good for the goose
> is good for the gander", you really need to provide a reasonable
> change log entry. Just because you are the network maintainer
> doesn't mean you get to skip all the documented rules about submitting
> patches.
Agree. Thanks.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [PATCH] ipv4: Early TCP socket demux.
From: David Miller @ 2012-06-19 4:15 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1340078846.7491.2127.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 19 Jun 2012 06:07:26 +0200
> On Mon, 2012-06-18 at 19:40 -0700, David Miller wrote:
>> You know you want it.
>>
>> Signed-off-by: David S. Miller <davem@davemloft.net>
>
> Yeah, very good idea David ;)
>
> needs some polishing of course.
Such as? IPv6 support?
> This reminds the idea of having seperate dst per tcp socket, to remove
> the dst refcnt contention as well.
I'm leery of this.
We're going to move towards having dst entries more strongly shared
as we move to remove the routing cache.
In fact I have another short-term change planned that adjusts which
keys the routing cache uses based upon what kinds of keys are actually
active in the current FIB rule configuration.
I think we want to encourage sharing and make the route footprint
smaller rather than expanding it's size artificually on even the
socket level.
If you really care about this refcount problem, then it's another
reason to never orphan socket sourced packets. Then we wouldn't need
to ever refcount the route just to send a packet, we'd just use the
implicit reference held by the socket instead. Socket route releasing
would be held back by the presence of any packets in the socket send
queue. If we have to reset the dst mis-lifetime due to route flushes,
we'd need to use a specific packet as a sequence point.
That to me sounds like a more reasonable approach than just making
more and more routes.
^ permalink raw reply
* Re: [PATCH] ipv4: Early TCP socket demux.
From: David Miller @ 2012-06-19 4:16 UTC (permalink / raw)
To: xiaosuo; +Cc: stephen.hemminger, netdev
In-Reply-To: <CABa6K_E+EzeJQF_m4aoq1WAYUwWQxd8_=k7HT0XZ6P5EpBR+4g@mail.gmail.com>
From: Changli Gao <xiaosuo@gmail.com>
Date: Tue, 19 Jun 2012 12:13:48 +0800
> On Tue, Jun 19, 2012 at 12:03 PM, Stephen Hemminger
> <stephen.hemminger@vyatta.com> wrote:
>>
>>>
>>> You know you want it.
>>>
>>> Signed-off-by: David S. Miller <davem@davemloft.net>
>>
>> David, I understand it, Eric understands it, and maybe one or
>> two others. But on the principal of what is "good for the goose
>> is good for the gander", you really need to provide a reasonable
>> change log entry. Just because you are the network maintainer
>> doesn't mean you get to skip all the documented rules about submitting
>> patches.
>
> Agree. Thanks.
That's the last time I try to be even slightly humerous on this
list.
Thanks for killing the fun Stephen.
^ permalink raw reply
* Re: [PATCH] ipv4: Early TCP socket demux.
From: Eric Dumazet @ 2012-06-19 4:23 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20120618.211539.105938285016510975.davem@davemloft.net>
On Mon, 2012-06-18 at 21:15 -0700, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Tue, 19 Jun 2012 06:07:26 +0200
>
> > On Mon, 2012-06-18 at 19:40 -0700, David Miller wrote:
> >> You know you want it.
> >>
> >> Signed-off-by: David S. Miller <davem@davemloft.net>
> >
> > Yeah, very good idea David ;)
> >
> > needs some polishing of course.
>
> Such as? IPv6 support?
>
I was referring to socket leak in :
+ 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) {
+ skb_dst_set_noref(skb, dst);
+ err = 0;
+ }
+ }
+ }
^ permalink raw reply
* Re: [PATCH] ipv4: Early TCP socket demux.
From: Eric Dumazet @ 2012-06-19 4:25 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <1340079813.7491.2164.camel@edumazet-glaptop>
On Tue, 2012-06-19 at 06:23 +0200, Eric Dumazet wrote:
> On Mon, 2012-06-18 at 21:15 -0700, David Miller wrote:
> > From: Eric Dumazet <eric.dumazet@gmail.com>
> > Date: Tue, 19 Jun 2012 06:07:26 +0200
> >
> > > On Mon, 2012-06-18 at 19:40 -0700, David Miller wrote:
> > >> You know you want it.
> > >>
> > >> Signed-off-by: David S. Miller <davem@davemloft.net>
> > >
> > > Yeah, very good idea David ;)
> > >
> > > needs some polishing of course.
> >
> > Such as? IPv6 support?
> >
>
> I was referring to socket leak in :
>
> + 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) {
> + skb_dst_set_noref(skb, dst);
> + err = 0;
> + }
> + }
> + }
>
>
It's not a leak, but seems strange to keep it around if we dont use it
yet.
^ permalink raw reply
* Re: [PATCH] ipv4: Early TCP socket demux.
From: David Miller @ 2012-06-19 4:26 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1340079813.7491.2164.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 19 Jun 2012 06:23:33 +0200
> I was referring to socket leak in :
>
> + 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) {
> + skb_dst_set_noref(skb, dst);
> + err = 0;
> + }
> + }
> + }
>
I see no leak.
^ permalink raw reply
* Re: [PATCH] ipv4: Early TCP socket demux.
From: David Miller @ 2012-06-19 4:27 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1340079938.7491.2172.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 19 Jun 2012 06:25:38 +0200
> On Tue, 2012-06-19 at 06:23 +0200, Eric Dumazet wrote:
>> On Mon, 2012-06-18 at 21:15 -0700, David Miller wrote:
>> > From: Eric Dumazet <eric.dumazet@gmail.com>
>> > Date: Tue, 19 Jun 2012 06:07:26 +0200
>> >
>> > > On Mon, 2012-06-18 at 19:40 -0700, David Miller wrote:
>> > >> You know you want it.
>> > >>
>> > >> Signed-off-by: David S. Miller <davem@davemloft.net>
>> > >
>> > > Yeah, very good idea David ;)
>> > >
>> > > needs some polishing of course.
>> >
>> > Such as? IPv6 support?
>> >
>>
>> I was referring to socket leak in :
>>
>> + 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) {
>> + skb_dst_set_noref(skb, dst);
>> + err = 0;
>> + }
>> + }
>> + }
>>
>>
>
> It's not a leak, but seems strange to keep it around if we dont use it
> yet.
How are we not using it? We use the cached SKB socket no matter what
happens.
Look at how inet hash lookup works.
The error tells the caller solely whether a route lookup is still
necessary.
^ permalink raw reply
* Re: [PATCH] ipv4: Early TCP socket demux.
From: Eric Dumazet @ 2012-06-19 4:31 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20120618.211539.105938285016510975.davem@davemloft.net>
On Mon, 2012-06-18 at 21:15 -0700, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> > This reminds the idea of having seperate dst per tcp socket, to remove
> > the dst refcnt contention as well.
>
> I'm leery of this.
>
> We're going to move towards having dst entries more strongly shared
> as we move to remove the routing cache.
>
> In fact I have another short-term change planned that adjusts which
> keys the routing cache uses based upon what kinds of keys are actually
> active in the current FIB rule configuration.
>
> I think we want to encourage sharing and make the route footprint
> smaller rather than expanding it's size artificually on even the
> socket level.
>
> If you really care about this refcount problem, then it's another
> reason to never orphan socket sourced packets. Then we wouldn't need
> to ever refcount the route just to send a packet, we'd just use the
> implicit reference held by the socket instead. Socket route releasing
> would be held back by the presence of any packets in the socket send
> queue. If we have to reset the dst mis-lifetime due to route flushes,
> we'd need to use a specific packet as a sequence point.
>
> That to me sounds like a more reasonable approach than just making
> more and more routes.
We already don't touch dst refcnt on TCP xmit path, unless packet is
parked in Qdisc queue...
But with BQL this is becoming less effective.
^ permalink raw reply
* Re: [PATCH] ipv4: Early TCP socket demux.
From: Eric Dumazet @ 2012-06-19 4:37 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20120618.212721.2148947025741866390.davem@davemloft.net>
On Mon, 2012-06-18 at 21:27 -0700, David Miller wrote:
> How are we not using it? We use the cached SKB socket no matter what
> happens.
>
> Look at how inet hash lookup works.
>
> The error tells the caller solely whether a route lookup is still
> necessary.
OK, remove the unlikely() in __inet_lookup_skb() so that its obvious we
have this skb_steal_sock() thing :)
^ permalink raw reply
* Re: [PATCH] ipv4: Early TCP socket demux.
From: Changli Gao @ 2012-06-19 4:43 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Tom Herbert
In-Reply-To: <20120618.194016.2282814982594761206.davem@davemloft.net>
On Tue, Jun 19, 2012 at 10:40 AM, David Miller <davem@davemloft.net> wrote:
> @@ -324,19 +324,34 @@ static int ip_rcv_finish(struct sk_buff *skb)
> * how the packet travels inside Linux networking.
> */
> if (skb_dst(skb) == NULL) {
> - 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;
> + const struct net_protocol *ipprot;
> + int protocol = iph->protocol;
> + int hash, err;
> +
> + hash = protocol & (MAX_INET_PROTOS - 1);
> +
> + rcu_read_lock();
> + ipprot = rcu_dereference(inet_protos[hash]);
> + err = -ENOENT;
> + if (ipprot && ipprot->early_demux)
> + err = ipprot->early_demux(skb);
I am afraid that this lookup with hurt the performance of the
forwarding path. A knob?
If this approach is acceptable, maybe we can use sockets to do finer RFS.
Thanks.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [PATCH] ipv4: Early TCP socket demux.
From: Eric Dumazet @ 2012-06-19 4:47 UTC (permalink / raw)
To: Changli Gao; +Cc: David Miller, netdev, Tom Herbert
In-Reply-To: <CABa6K_Ge-Y1ne3iBcN1HSRN+G4bW6hSAHYFGKuA5QKW6CT3grQ@mail.gmail.com>
On Tue, 2012-06-19 at 12:43 +0800, Changli Gao wrote:
> I am afraid that this lookup with hurt the performance of the
> forwarding path. A knob?
>
ip_rcv() & ip_rcv_finish() in the forwarding path ?
^ permalink raw reply
* Re: [PATCH] ipv4: Early TCP socket demux.
From: Changli Gao @ 2012-06-19 4:51 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, Tom Herbert
In-Reply-To: <1340081276.7491.2228.camel@edumazet-glaptop>
On Tue, Jun 19, 2012 at 12:47 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Tue, 2012-06-19 at 12:43 +0800, Changli Gao wrote:
>
>> I am afraid that this lookup with hurt the performance of the
>> forwarding path. A knob?
>>
>
> ip_rcv() & ip_rcv_finish() in the forwarding path ?
>
>
Yes, the two routines are shared by both. I think you mean
ip_local_deliver() and ip_local_deliver_finish().
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [RFC] TCP: Support configurable delayed-ack parameters.
From: Eric Dumazet @ 2012-06-19 5:11 UTC (permalink / raw)
To: greearb; +Cc: netdev, Daniel Baluta
In-Reply-To: <1340067163-29329-1-git-send-email-greearb@candelatech.com>
On Mon, 2012-06-18 at 17:52 -0700, greearb@candelatech.com wrote:
> From: Ben Greear <greearb@candelatech.com>
>
> RFC2581 ($4.2) specifies when an ACK should be generated as follows:
>
> " .. an ACK SHOULD be generated for at least every second
> full-sized segment, and MUST be generated within 500 ms
> of the arrival of the first unacknowledged packet.
> "
>
> We export the number of segments and the timeout limits
> specified above, so that a user can tune them according
> to their needs.
>
> Specifically:
> * /proc/sys/net/ipv4/tcp_default_delack_segs, represents
> the threshold for the number of segments.
> * /proc/sys/net/ipv4/tcp_default_delack_min, specifies
> the minimum timeout value
> * /proc/sys/net/ipv4/tcp_default_delack_max, specifies
> the maximum timeout value.
>
> In addition, new TCP socket options are added to allow
> per-socket configuration:
>
> TCP_DELACK_SEGS
> TCP_DELACK_MIN
> TCP_DELACK_MAX
>
> In order to keep a multiply out of the hot path, the segs * mss
> computation is recalculated and cached whenever segs or mss changes.
>
I know David was worried about this multiply, but current cpus do a
multiply in at most 3 cycles.
Addding an u32 field in socket structure adds 1/16 of a cache line, and
adds more penalty.
Avoiding to build/send an ACK packet can save us so many cpu cycles that
the multiply is pure noise.
^ permalink raw reply
* RE: [PATCH] net: added support for 40GbE link.
From: Parav.Pandit @ 2012-06-19 5:20 UTC (permalink / raw)
To: rick.jones2; +Cc: netdev, bhutchings
In-Reply-To: <4FDF56FB.9080509@hp.com>
> -----Original Message-----
> From: Rick Jones [mailto:rick.jones2@hp.com]
> Sent: Monday, June 18, 2012 9:58 PM
> To: Pandit, Parav
> Cc: netdev@vger.kernel.org; bhutchings@solarflare.com
> Subject: Re: [PATCH] net: added support for 40GbE link.
>
> On 06/18/2012 05:44 AM, Parav Pandit wrote:
>
> > diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h index
> > 297370a..1ebfa6e 100644
> > --- a/include/linux/ethtool.h
> > +++ b/include/linux/ethtool.h
> > @@ -1153,6 +1153,10 @@ struct ethtool_ops {
> > #define SUPPORTED_10000baseR_FEC (1<< 20)
> > #define SUPPORTED_20000baseMLD2_Full (1<< 21)
> > #define SUPPORTED_20000baseKR2_Full (1<< 22)
> > +#define SUPPORTED_40000baseKR4_Full (1<< 23)
> > +#define SUPPORTED_40000baseCR4_Full (1<< 24)
> > +#define SUPPORTED_40000baseSR4_Full (1<< 25)
> > +#define SUPPORTED_40000baseLR4_Full (1<< 26)
> >
> > /* Indicates what features are advertised by the interface. */
> > #define ADVERTISED_10baseT_Half (1<< 0)
> > @@ -1178,6 +1182,10 @@ struct ethtool_ops {
> > #define ADVERTISED_10000baseR_FEC (1<< 20)
> > #define ADVERTISED_20000baseMLD2_Full (1<< 21)
> > #define ADVERTISED_20000baseKR2_Full (1<< 22)
> > +#define ADVERTISED_40000baseKR4_Full (1<< 23)
> > +#define ADVERTISED_40000baseCR4_Full (1<< 24)
> > +#define ADVERTISED_40000baseSR4_Full (1<< 25)
> > +#define ADVERTISED_40000baseLR4_Full (1<< 26)
>
> Any idea how many defines will be wanted for 100 Gbit Ethernet?
> Supported and advertising in ethtool_cmd are __u32s...
>
100G supports CR10, ER4, LR4, Base-R and SR10 interfaces. So 5 bits. We have space from 27 to 31 bits for 100G as well.
> rick jones
^ permalink raw reply
* Re: [PATCH] ipv4: Early TCP socket demux.
From: David Miller @ 2012-06-19 6:07 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1340080661.7491.2205.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 19 Jun 2012 06:37:41 +0200
> On Mon, 2012-06-18 at 21:27 -0700, David Miller wrote:
>
>> How are we not using it? We use the cached SKB socket no matter what
>> happens.
>>
>> Look at how inet hash lookup works.
>>
>> The error tells the caller solely whether a route lookup is still
>> necessary.
>
> OK, remove the unlikely() in __inet_lookup_skb() so that its obvious we
> have this skb_steal_sock() thing :)
Sure thing.
We also need to add some dst->ops->check() handling as well.
^ permalink raw reply
* Re: [PATCH] ipv4: Early TCP socket demux.
From: Eric Dumazet @ 2012-06-19 6:28 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20120618.230723.612232275251003129.davem@davemloft.net>
On Mon, 2012-06-18 at 23:07 -0700, David Miller wrote:
> Sure thing.
>
> We also need to add some dst->ops->check() handling as well.
Yes, rp_filter comes to mind.
^ permalink raw reply
* Re: [PATCH] sctp: fix warning when compiling without IPv6
From: David Miller @ 2012-06-19 7:28 UTC (permalink / raw)
To: dhalperi; +Cc: netdev
In-Reply-To: <B7062EEE-046D-4435-B5FC-54FF3F763645@cs.washington.edu>
From: Daniel Halperin <dhalperi@cs.washington.edu>
Date: Mon, 18 Jun 2012 14:04:55 -0700
> net/sctp/protocol.c: In function ‘sctp_addr_wq_timeout_handler’:
> net/sctp/protocol.c:676: warning: label ‘free_next’ defined but not used
>
> Signed-off-by: Daniel Halperin <dhalperi@cs.washington.edu>
Applied.
^ permalink raw reply
* Re: [PATCH RESEND] net: lpc_eth: Driver cleanup
From: David Miller @ 2012-06-19 7:28 UTC (permalink / raw)
To: stigge
Cc: eric.dumazet, netdev, linux-kernel, kevin.wells, srinivas.bakki,
aletes.xgr, linux-arm-kernel
In-Reply-To: <1340050482-22666-1-git-send-email-stigge@antcom.de>
From: Roland Stigge <stigge@antcom.de>
Date: Mon, 18 Jun 2012 22:14:42 +0200
> This patch removes some nowadays superfluous definitions (one unused define and
> an obsolete function forward declaration) and corrects a netdev_err() to
> netdev_dbg().
>
> Signed-off-by: Roland Stigge <stigge@antcom.de>
> Signed-off-by: Alexandre Pereira da Silva <aletes.xgr@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: added support for 40GbE link.
From: David Miller @ 2012-06-19 7:29 UTC (permalink / raw)
To: bhutchings; +Cc: parav.pandit, netdev
In-Reply-To: <1340039376.2913.13.camel@bwh-desktop.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Mon, 18 Jun 2012 18:09:36 +0100
> On Mon, 2012-06-18 at 18:14 +0530, Parav Pandit wrote:
...
>> -/* The forced speed, 10Mb, 100Mb, gigabit, 2.5Gb, 10GbE. */
>> +/* The forced speed, 10Mb, 100Mb, gigabit, 2.5Gb, 10GbE, 40GbE. */
>
> I don't think there's any need to name all possible link speeds, and it
> just encourages the bad practice of ethtool API users checking for
> specific values. You may notice there is no SPEED_20000.
Agreed.
>> @@ -542,13 +542,11 @@ static int prb_calc_retire_blk_tmo(struct packet_sock *po,
...
> This function should be fixed properly. Firstly, it must use
> ethtool_cmd_speed() rather than directly accessing ecmd.speed.
> Secondly, it should allow any speed value rather than checking for
> specific values. Then there will be no need to make further changes for
> 100G or any other new speed.
Agreed.
^ permalink raw reply
* Re: [PATCH] phy/micrel: change phy_id_mask for KSZ9021 and KS8001
From: David Miller @ 2012-06-19 7:31 UTC (permalink / raw)
To: jason77.wang; +Cc: david.choi, nobuhiro.iwamatsu.yj, netdev
In-Reply-To: <1340009529-4231-1-git-send-email-jason77.wang@gmail.com>
From: Hui Wang <jason77.wang@gmail.com>
Date: Mon, 18 Jun 2012 16:52:09 +0800
> On a freescale imx6q platform, a hardware phy chip KSZ9021 is
> recognized as a KS8001 chip by the current driver like this:
> eth0: Freescale FEC PHY driver [Micrel KS8001 or KS8721]
>
> KSZ9021 has phy_id 0x00221610, while KSZ8001 has phy_id
> 0x0022161a, the current phy_id_mask (0x00fffff0/0x00ffff10) can't
> distinguish them. So change phy_id_mask to resolve this problem.
>
> Although the micrel datasheet says that the 4 LSB of phyid2 register
> contains the chip revision number and the current driver is designed
> to follow this rule, in reality the chip implementation doesn't follow
> it.
>
> Cc: David J. Choi <david.choi@micrel.com>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
> Signed-off-by: Hui Wang <jason77.wang@gmail.com>
Applied, thanks.
^ permalink raw reply
* RE: [PATCH] net: added support for 40GbE link.
From: Parav.Pandit @ 2012-06-19 7:33 UTC (permalink / raw)
To: davem, bhutchings; +Cc: netdev
In-Reply-To: <20120619.002905.922583388766089167.davem@davemloft.net>
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Tuesday, June 19, 2012 12:59 PM
> To: bhutchings@solarflare.com
> Cc: Pandit, Parav; netdev@vger.kernel.org
> Subject: Re: [PATCH] net: added support for 40GbE link.
>
> From: Ben Hutchings <bhutchings@solarflare.com>
> Date: Mon, 18 Jun 2012 18:09:36 +0100
>
> > On Mon, 2012-06-18 at 18:14 +0530, Parav Pandit wrote:
> ...
> >> -/* The forced speed, 10Mb, 100Mb, gigabit, 2.5Gb, 10GbE. */
> >> +/* The forced speed, 10Mb, 100Mb, gigabit, 2.5Gb, 10GbE, 40GbE. */
> >
> > I don't think there's any need to name all possible link speeds, and
> > it just encourages the bad practice of ethtool API users checking for
> > specific values. You may notice there is no SPEED_20000.
>
> Agreed.
Should eventually all net driver should remove using SPEED_xxxxxx and start using hard coded value of 10, 100, 1000, 20000?
>
> >> @@ -542,13 +542,11 @@ static int prb_calc_retire_blk_tmo(struct
> >> packet_sock *po,
> ...
> > This function should be fixed properly. Firstly, it must use
> > ethtool_cmd_speed() rather than directly accessing ecmd.speed.
> > Secondly, it should allow any speed value rather than checking for
> > specific values. Then there will be no need to make further changes
> > for 100G or any other new speed.
>
> Agreed.
That means ethtool_cmd_speed() should not be called in this function?
If I understand correctly, it should return the value of 8ms (for 10Mb,s 100Mbps, 2.5 Gbps, 20Gbps) as today and remaining it should return calculated value?
Or
Function needs a fix for all these speeds (10Mbps, 100Mbs, 20Gbps too)?
^ permalink raw reply
* Re: [XFRM][RFC v1] Fix unexpected SA hard expiration after setting new date
From: David Miller @ 2012-06-19 7:34 UTC (permalink / raw)
To: herbert; +Cc: fan.du, netdev, fdu
In-Reply-To: <20120618084021.GA24902@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Mon, 18 Jun 2012 16:40:21 +0800
> I guess I can live with your workaround if Dave is happy with
> it. But IMHO we should just go back to relative time and fix
> the suspend/resume user-space scripts instead.
In the short term I'm happy with it too.
But I seem to remember that last time this issue came up the
suggestion was to use highres timers. Someone tried but they did an
amazingly poor job so the effort just died off. It takes someone with
some skill because highres timers operate with different context
requirements than normal timers.
^ permalink raw reply
* Re: [PATCH] net: added support for 40GbE link.
From: David Miller @ 2012-06-19 7:35 UTC (permalink / raw)
To: Parav.Pandit; +Cc: bhutchings, netdev
In-Reply-To: <5D6C0ABE6A236946864C45679362BBE20AC52269@CMEXMB1.ad.emulex.com>
From: <Parav.Pandit@Emulex.Com>
Date: Tue, 19 Jun 2012 07:33:12 +0000
> Should eventually all net driver should remove using SPEED_xxxxxx and start using hard coded value of 10, 100, 1000, 20000?
No, the ones that exist can stay, just no new ones.
> That means ethtool_cmd_speed() should not be called in this function?
Ben said that it must be called, what are you talking about?
^ 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