* Re: Micrel Phy - Is there a way to configure the Phy not to do 802.3x flow control?
From: Florian Fainelli @ 2016-03-10 18:05 UTC (permalink / raw)
To: Murali Karicheri, johan, open list:TI NETCP ETHERNET DRIVER,
Kwok, WingMan
In-Reply-To: <56E1A55F.3090906@ti.com>
On 10/03/16 08:48, Murali Karicheri wrote:
> On 03/03/2016 07:16 PM, Florian Fainelli wrote:
>> On 03/03/16 14:18, Murali Karicheri wrote:
>>> Hi,
>>>
>>> We are using Micrel Phy in one of our board and wondering if we can force the
>>> Phy to disable flow control at start. I have a 1G ethernet switch connected
>>> to Phy and the phy always enable flow control. I would like to configure the
>>> phy not to flow control. Is that possible and if yes, what should I do in the
>>> my Ethernet driver to tell the Phy not to enable flow control?
>>
>> The PHY is not doing flow control per-se, your pseudo Ethernet MAC in
>> the switch is doing, along with the link partner advertising support for
>> it. You would want to make sure that your PHY device interface (provided
>> that you are using the PHY library) is not starting with Pause
>> advertised, but it could be supported.
>
> Understood that Phy is just advertise FC. The Micrel phy for 9031 advertise
> by default FC supported. After negotiation, I see that Phylib provide the
> link status with parameter pause = 1, asym_pause = 1. How do I tell the Phy not
> to advertise?
>
> I call following sequence in the Ethernet driver.
>
> of_phy_connect(x,y,hndlr,a,z);
Here you should be able to change phydev->advertising and
phydev->supported to mask the ADVERTISED_Pause | ADVERTISED_AsymPause
bits and have phy_start() restart with that which should disable pause
and asym_pause as seen by your adjust_link handler.
> phy_start()
>
> Now in hndlr() I have pause = 1, asym_pause = 1, in phy_device ptr. How can
> I tell the phy not to advertise initially?
--
Florian
^ permalink raw reply
* Re: [RFC] net: ipv4 -- Introduce ifa limit per net
From: David Miller @ 2016-03-10 18:01 UTC (permalink / raw)
To: gorcunov
Cc: alexei.starovoitov, eric.dumazet, netdev, solar, vvs, avagin,
xemul, vdavydov, khorenko, pablo, netfilter-devel
In-Reply-To: <20160310150920.GC21154@uranus.lan>
From: Cyrill Gorcunov <gorcunov@gmail.com>
Date: Thu, 10 Mar 2016 18:09:20 +0300
> On Thu, Mar 10, 2016 at 02:03:24PM +0300, Cyrill Gorcunov wrote:
>> On Thu, Mar 10, 2016 at 01:20:18PM +0300, Cyrill Gorcunov wrote:
>> > On Thu, Mar 10, 2016 at 12:16:29AM +0300, Cyrill Gorcunov wrote:
>> > >
>> > > Thanks for explanation, Dave! I'll continue on this task tomorrow
>> > > tryin to implement optimization you proposed.
>> >
>> > OK, here are the results for the preliminary patch with conntrack running
>> ...
>> > net/ipv4/devinet.c | 13 ++++++++++++-
>> > 1 file changed, 12 insertions(+), 1 deletion(-)
>> >
>> > Index: linux-ml.git/net/ipv4/devinet.c
>> > ===================================================================
>> > --- linux-ml.git.orig/net/ipv4/devinet.c
>> > +++ linux-ml.git/net/ipv4/devinet.c
>> > @@ -403,7 +403,18 @@ no_promotions:
>> > So that, this order is correct.
>> > */
>>
>> This patch is wrong, so drop it please. I'll do another.
>
> Here I think is a better variant. The resulst are good
> enough -- 1 sec for cleanup. Does the patch look sane?
I'm tempted to say that we should provide these notifier handlers with
the information they need, explicitly, to handle this case.
Most intdev notifiers actually want to know the individual addresses
that get removed, one by one. That's handled by the existing
NETDEV_DOWN event and the ifa we pass to that.
But some, like this netfilter masq case, would be satisfied with a
single event that tells them the whole inetdev instance is being torn
down. Which is the case we care about here.
We currently don't use NETDEV_UNREGISTER for inetdev notifiers, so
maybe we could use that.
And that is consistent with the core netdev notifier that triggers
this call chain in the first place.
Roughly, something like this:
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index 8c3df2c..6eee5cb 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -292,6 +292,11 @@ static void inetdev_destroy(struct in_device *in_dev)
in_dev->dead = 1;
+ if (in_dev->ifa_list)
+ blocking_notifier_call_chain(&inetaddr_chain,
+ NETDEV_UNREGISTER,
+ in_dev->ifa_list);
+
ip_mc_destroy_dev(in_dev);
while ((ifa = in_dev->ifa_list) != NULL) {
diff --git a/net/ipv4/netfilter/nf_nat_masquerade_ipv4.c b/net/ipv4/netfilter/nf_nat_masquerade_ipv4.c
index c6eb421..1bb8026 100644
--- a/net/ipv4/netfilter/nf_nat_masquerade_ipv4.c
+++ b/net/ipv4/netfilter/nf_nat_masquerade_ipv4.c
@@ -111,6 +111,10 @@ static int masq_inet_event(struct notifier_block *this,
struct net_device *dev = ((struct in_ifaddr *)ptr)->ifa_dev->dev;
struct netdev_notifier_info info;
+ if (event != NETDEV_UNREGISTER)
+ return NOTIFY_DONE;
+ event = NETDEV_DOWN;
+
netdev_notifier_info_init(&info, dev);
return masq_device_event(this, event, &info);
}
^ permalink raw reply related
* Re: [PATCH net-next v4] tcp: Add RFC4898 tcpEStatsPerfDataSegsOut/In
From: Martin KaFai Lau @ 2016-03-10 17:58 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev, Kernel Team, Chris Rapier, Marcelo Ricardo Leitner,
Neal Cardwell, Yuchung Cheng
In-Reply-To: <CANn89iJFBqOkD8G1qQDY-p=Z3jSgtPbeSSoiuiAqWXYgXzi5-A@mail.gmail.com>
On Thu, Mar 10, 2016 at 09:43:18AM -0800, Eric Dumazet wrote:
> On Thu, Mar 10, 2016 at 9:39 AM, Eric Dumazet <edumazet@google.com> wrote:
> > On Thu, Mar 10, 2016 at 9:29 AM, Martin KaFai Lau <kafai@fb.com> wrote:
> >> Per RFC4898, they count segments sent/received
> >> containing a positive length data segment (that includes
> >> retransmission segments carrying data). Unlike
> >> tcpi_segs_out/in, tcpi_data_segs_out/in excludes segments
> >> carrying no data (e.g. pure ack).
> >>
> >> The patch also updates the segs_in in tcp_fastopen_add_skb()
> >> so that segs_in >= data_segs_in property is kept. If
> >> tcp_segs_in() helper is used in this fastopen case, tp->segs_in
> >> has to be 0 reset first to avoid double counting. Also, it has
> >> to be done before __skb_pull(skb, tcp_hdrlen(skb)) while
> >> there is no need to check skb->len since skb has already
> >> been confirmed carrying data. I found it more confusing
> >> and chose to directly set segs_in and data_segs_in in
> >> this special case.
> >
> > Note that on my TODO list after commit e11ecddf5128011c936cc5360780190cbc901fdc
> > I had the project of pulling TCP headers much earlier in input path
> > so that we do not have all these special cases.
> >
> > Acked-by: Eric Dumazet <edumazet@google.com>
>
> Actually, tcp_fastopen_add_skb() can queue a packet with a FIN only,
> but no data.
Thanks for pointing it out. Didn't know it is allowed and
the above end_seq check could also be +1 by the FIN.
>
> I believe you need to test skb->len before setting tp->data_segs_in
In that case, I will try to 0 reset segs_in with comment explanation and call
tcp_segs_in() before the skb_pull. I will spin another version.
^ permalink raw reply
* Re: [PATCH] b43: fix memory leak
From: Sudip Mukherjee @ 2016-03-10 17:56 UTC (permalink / raw)
To: Michael Büsch
Cc: Kalle Valo, netdev, Jia-Ju Bai, linux-wireless, linux-kernel,
b43-dev
In-Reply-To: <20160310184313.06eb8b91@wiggum>
On Thursday 10 March 2016 11:13 PM, Michael Büsch wrote:
> On Fri, 19 Feb 2016 20:37:18 +0530
> Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote:
>
>>> https://patchwork.kernel.org/patch/8049041/
>>
>> I have an old laptop running on 800Mhz CPU. It has "Broadcom BCM4311
>> [14e4:4311] (rev 01)".
>> I will try to test it on this weekend.
>
> Any news on this one?
No. Sorry. I was trying to install ubuntu 14.04 in it, but for some
reason the usb stick is not moving past the boot screen. Give me two
more days and I will let you all know by this Saturday.
regards
sudip
^ permalink raw reply
* Re: [PATCH v2] phy: remove documentation of removed members of phy_device structure
From: Florian Fainelli @ 2016-03-10 17:53 UTC (permalink / raw)
To: LABBE Corentin; +Cc: netdev, linux-kernel
In-Reply-To: <1457614738-17337-1-git-send-email-clabbe.montjoie@gmail.com>
On 10/03/16 04:58, LABBE Corentin wrote:
> Commit e5a03bfd873c ("phy: Add an mdio_device structure") removed addr,
> bus and dev member of the phy_device structure.
> This patch remove the documentation about those members.
>
> Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH 1/2] net: thunderx: Set recevie buffer page usage count in bulk
From: David Miller @ 2016-03-10 17:44 UTC (permalink / raw)
To: sunil.kovvuri
Cc: netdev, linux-kernel, linux-arm-kernel, sgoutham, robert.richter
In-Reply-To: <CA+sq2Cc44v_ggy=QLOX_FGt6uTv3Qo1KmqCeZ8=3G1COuWxAHw@mail.gmail.com>
From: Sunil Kovvuri <sunil.kovvuri@gmail.com>
Date: Thu, 10 Mar 2016 16:13:28 +0530
> Hi David,
>
>
>>> So if you know ahead of time how the page will be split up, just
>>> calculate that when you get the page and increment the page count
>>> appropriately.
>>>
>>> That's what we do in the NIU driver.
>>
>> Thanks for the suggestion, will check and get back.
>>
>
> I looked at the NIU driver and in fn() niu_rbr_refill()
> static void niu_rbr_refill(struct niu *np, struct rx_ring_info *rp, gfp_t mask)
> {
> int index = rp->rbr_index;
>
> rp->rbr_pending++;
> if ((rp->rbr_pending % rp->rbr_blocks_per_page) == 0) {
>
> Here it's been checked whether rbr_pending is a exact multiple of page
> split count.
> And hence updating page count based on fixed calculation is right.
>
> On my platform driver receives a interrupt when free buffer count
> falls below a threshold
> and by the time SW reads count of buffers to be refilled it can be any
> number i.e
> may or may not be a exact multiple of page split count.
So calculate the modulus on the page split count and optimize the
increment ahead of time when possible, and for the sub page split
pieces do it one at a time.
I don't understand what the problem is.
^ permalink raw reply
* Re: [PATCH net-next v4] tcp: Add RFC4898 tcpEStatsPerfDataSegsOut/In
From: Eric Dumazet @ 2016-03-10 17:43 UTC (permalink / raw)
To: Martin KaFai Lau
Cc: netdev, Kernel Team, Chris Rapier, Marcelo Ricardo Leitner,
Neal Cardwell, Yuchung Cheng
In-Reply-To: <CANn89iJF2mw-2qFJ1r2xLo0FuH9JCNVPgTOAfnxL7nOX4qg2tg@mail.gmail.com>
On Thu, Mar 10, 2016 at 9:39 AM, Eric Dumazet <edumazet@google.com> wrote:
> On Thu, Mar 10, 2016 at 9:29 AM, Martin KaFai Lau <kafai@fb.com> wrote:
>> Per RFC4898, they count segments sent/received
>> containing a positive length data segment (that includes
>> retransmission segments carrying data). Unlike
>> tcpi_segs_out/in, tcpi_data_segs_out/in excludes segments
>> carrying no data (e.g. pure ack).
>>
>> The patch also updates the segs_in in tcp_fastopen_add_skb()
>> so that segs_in >= data_segs_in property is kept. If
>> tcp_segs_in() helper is used in this fastopen case, tp->segs_in
>> has to be 0 reset first to avoid double counting. Also, it has
>> to be done before __skb_pull(skb, tcp_hdrlen(skb)) while
>> there is no need to check skb->len since skb has already
>> been confirmed carrying data. I found it more confusing
>> and chose to directly set segs_in and data_segs_in in
>> this special case.
>
> Note that on my TODO list after commit e11ecddf5128011c936cc5360780190cbc901fdc
> I had the project of pulling TCP headers much earlier in input path
> so that we do not have all these special cases.
>
> Acked-by: Eric Dumazet <edumazet@google.com>
Actually, tcp_fastopen_add_skb() can queue a packet with a FIN only,
but no data.
I believe you need to test skb->len before setting tp->data_segs_in
^ permalink raw reply
* Re: [PATCH] b43: fix memory leak
From: Michael Büsch @ 2016-03-10 17:43 UTC (permalink / raw)
To: Sudip Mukherjee
Cc: Kalle Valo, netdev-u79uwXL29TY76Z2rM5mHXA, Jia-Ju Bai,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
b43-dev-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <56C72FA6.3090102-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 360 bytes --]
On Fri, 19 Feb 2016 20:37:18 +0530
Sudip Mukherjee <sudipm.mukherjee-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > https://patchwork.kernel.org/patch/8049041/
>
> I have an old laptop running on 800Mhz CPU. It has "Broadcom BCM4311
> [14e4:4311] (rev 01)".
> I will try to test it on this weekend.
Any news on this one?
--
Michael
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: pull-request: can-next 2016-03-10,pull-request: can-next 2016-03-10
From: David Miller @ 2016-03-10 17:42 UTC (permalink / raw)
To: mkl; +Cc: netdev, kernel, linux-can
In-Reply-To: <56E13F68.900@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Thu, 10 Mar 2016 10:33:28 +0100
> this is a pull request of 5 patch for net-next/master.
>
> Marek Vasut contributes 4 patches for the ifi CAN driver, which makes
> it work on real hardware. There is one patch by Ramesh Shanmugasundaram
> for the rcar_can driver that adds support for the 3rd generation IP
> core.
Pulled, thanks Marc.
^ permalink raw reply
* Re: [PATCH net-next v4] tcp: Add RFC4898 tcpEStatsPerfDataSegsOut/In
From: Eric Dumazet @ 2016-03-10 17:39 UTC (permalink / raw)
To: Martin KaFai Lau
Cc: netdev, Kernel Team, Chris Rapier, Marcelo Ricardo Leitner,
Neal Cardwell, Yuchung Cheng
In-Reply-To: <1457630961-2809690-1-git-send-email-kafai@fb.com>
On Thu, Mar 10, 2016 at 9:29 AM, Martin KaFai Lau <kafai@fb.com> wrote:
> Per RFC4898, they count segments sent/received
> containing a positive length data segment (that includes
> retransmission segments carrying data). Unlike
> tcpi_segs_out/in, tcpi_data_segs_out/in excludes segments
> carrying no data (e.g. pure ack).
>
> The patch also updates the segs_in in tcp_fastopen_add_skb()
> so that segs_in >= data_segs_in property is kept. If
> tcp_segs_in() helper is used in this fastopen case, tp->segs_in
> has to be 0 reset first to avoid double counting. Also, it has
> to be done before __skb_pull(skb, tcp_hdrlen(skb)) while
> there is no need to check skb->len since skb has already
> been confirmed carrying data. I found it more confusing
> and chose to directly set segs_in and data_segs_in in
> this special case.
Note that on my TODO list after commit e11ecddf5128011c936cc5360780190cbc901fdc
I had the project of pulling TCP headers much earlier in input path
so that we do not have all these special cases.
Acked-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [PATCH net-next v4] tcp: Add RFC4898 tcpEStatsPerfDataSegsOut/In
From: Yuchung Cheng @ 2016-03-10 17:37 UTC (permalink / raw)
To: Martin KaFai Lau
Cc: netdev, Kernel Team, Chris Rapier, Eric Dumazet,
Marcelo Ricardo Leitner, Neal Cardwell
In-Reply-To: <1457630961-2809690-1-git-send-email-kafai@fb.com>
On Thu, Mar 10, 2016 at 9:29 AM, Martin KaFai Lau <kafai@fb.com> wrote:
> Per RFC4898, they count segments sent/received
> containing a positive length data segment (that includes
> retransmission segments carrying data). Unlike
> tcpi_segs_out/in, tcpi_data_segs_out/in excludes segments
> carrying no data (e.g. pure ack).
>
> The patch also updates the segs_in in tcp_fastopen_add_skb()
> so that segs_in >= data_segs_in property is kept. If
> tcp_segs_in() helper is used in this fastopen case, tp->segs_in
> has to be 0 reset first to avoid double counting. Also, it has
> to be done before __skb_pull(skb, tcp_hdrlen(skb)) while
> there is no need to check skb->len since skb has already
> been confirmed carrying data. I found it more confusing
> and chose to directly set segs_in and data_segs_in in
> this special case.
>
> Together with retransmission data, tcpi_data_segs_out
> gives a better signal on the rxmit rate.
>
> v4: Add comment to the changes in tcp_fastopen_add_skb()
> and also add remark on this case in the commit message.
>
> v3: Add const modifier to the skb parameter in tcp_segs_in()
>
> v2: Rework based on recent fix by Eric:
> commit a9d99ce28ed3 ("tcp: fix tcpi_segs_in after connection establishment")
>
> Signed-off-by: Martin KaFai Lau <kafai@fb.com>
> Cc: Chris Rapier <rapier@psc.edu>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Marcelo Ricardo Leitner <mleitner@redhat.com>
> Cc: Neal Cardwell <ncardwell@google.com>
> Cc: Yuchung Cheng <ycheng@google.com>
> ---
Acked-by: Yuchung Cheng <ycheng@google.com>
Thanks for the clarification.
> include/linux/tcp.h | 6 ++++++
> include/net/tcp.h | 10 ++++++++++
> include/uapi/linux/tcp.h | 2 ++
> net/ipv4/tcp.c | 2 ++
> net/ipv4/tcp_fastopen.c | 10 ++++++++++
> net/ipv4/tcp_ipv4.c | 2 +-
> net/ipv4/tcp_minisocks.c | 2 +-
> net/ipv4/tcp_output.c | 4 +++-
> net/ipv6/tcp_ipv6.c | 2 +-
> 9 files changed, 36 insertions(+), 4 deletions(-)
>
> diff --git a/include/linux/tcp.h b/include/linux/tcp.h
> index bcbf51d..7be9b12 100644
> --- a/include/linux/tcp.h
> +++ b/include/linux/tcp.h
> @@ -158,6 +158,9 @@ struct tcp_sock {
> u32 segs_in; /* RFC4898 tcpEStatsPerfSegsIn
> * total number of segments in.
> */
> + u32 data_segs_in; /* RFC4898 tcpEStatsPerfDataSegsIn
> + * total number of data segments in.
> + */
> u32 rcv_nxt; /* What we want to receive next */
> u32 copied_seq; /* Head of yet unread data */
> u32 rcv_wup; /* rcv_nxt on last window update sent */
> @@ -165,6 +168,9 @@ struct tcp_sock {
> u32 segs_out; /* RFC4898 tcpEStatsPerfSegsOut
> * The total number of segments sent.
> */
> + u32 data_segs_out; /* RFC4898 tcpEStatsPerfDataSegsOut
> + * total number of data segments sent.
> + */
> u64 bytes_acked; /* RFC4898 tcpEStatsAppHCThruOctetsAcked
> * sum(delta(snd_una)), or how many bytes
> * were acked.
> diff --git a/include/net/tcp.h b/include/net/tcp.h
> index e90db85..24557a8 100644
> --- a/include/net/tcp.h
> +++ b/include/net/tcp.h
> @@ -1816,4 +1816,14 @@ static inline void skb_set_tcp_pure_ack(struct sk_buff *skb)
> skb->truesize = 2;
> }
>
> +static inline void tcp_segs_in(struct tcp_sock *tp, const struct sk_buff *skb)
> +{
> + u16 segs_in;
> +
> + segs_in = max_t(u16, 1, skb_shinfo(skb)->gso_segs);
> + tp->segs_in += segs_in;
> + if (skb->len > tcp_hdrlen(skb))
> + tp->data_segs_in += segs_in;
> +}
> +
> #endif /* _TCP_H */
> diff --git a/include/uapi/linux/tcp.h b/include/uapi/linux/tcp.h
> index fe95446..53e8e3f 100644
> --- a/include/uapi/linux/tcp.h
> +++ b/include/uapi/linux/tcp.h
> @@ -199,6 +199,8 @@ struct tcp_info {
>
> __u32 tcpi_notsent_bytes;
> __u32 tcpi_min_rtt;
> + __u32 tcpi_data_segs_in; /* RFC4898 tcpEStatsDataSegsIn */
> + __u32 tcpi_data_segs_out; /* RFC4898 tcpEStatsDataSegsOut */
> };
>
> /* for TCP_MD5SIG socket option */
> diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
> index f9faadb..6b01b48 100644
> --- a/net/ipv4/tcp.c
> +++ b/net/ipv4/tcp.c
> @@ -2728,6 +2728,8 @@ void tcp_get_info(struct sock *sk, struct tcp_info *info)
> info->tcpi_notsent_bytes = max(0, notsent_bytes);
>
> info->tcpi_min_rtt = tcp_min_rtt(tp);
> + info->tcpi_data_segs_in = tp->data_segs_in;
> + info->tcpi_data_segs_out = tp->data_segs_out;
> }
> EXPORT_SYMBOL_GPL(tcp_get_info);
>
> diff --git a/net/ipv4/tcp_fastopen.c b/net/ipv4/tcp_fastopen.c
> index fdb286d..74068e6 100644
> --- a/net/ipv4/tcp_fastopen.c
> +++ b/net/ipv4/tcp_fastopen.c
> @@ -131,6 +131,7 @@ static bool tcp_fastopen_cookie_gen(struct request_sock *req,
> void tcp_fastopen_add_skb(struct sock *sk, struct sk_buff *skb)
> {
> struct tcp_sock *tp = tcp_sk(sk);
> + u16 segs_in;
>
> if (TCP_SKB_CB(skb)->end_seq == tp->rcv_nxt)
> return;
> @@ -154,6 +155,15 @@ void tcp_fastopen_add_skb(struct sock *sk, struct sk_buff *skb)
> * as we certainly are not changing upper 32bit value (0)
> */
> tp->bytes_received = skb->len;
> + /* If tcp_segs_in() is used, we need
> + * to reset segs_in = 0 first to avoid double counting.
> + * Hence, segs_in and data_segs_in are direclty set here.
> + * Also, there is no need to check the skb->len as tcp_segs_in()
> + * does because skb is confirmed carrying data here.
> + */
> + segs_in = max_t(u16, 1, skb_shinfo(skb)->gso_segs);
> + tp->segs_in = segs_in;
> + tp->data_segs_in = segs_in;
>
> if (TCP_SKB_CB(skb)->tcp_flags & TCPHDR_FIN)
> tcp_fin(sk);
> diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
> index 4c8d58d..0b02ef7 100644
> --- a/net/ipv4/tcp_ipv4.c
> +++ b/net/ipv4/tcp_ipv4.c
> @@ -1650,7 +1650,7 @@ process:
> sk_incoming_cpu_update(sk);
>
> bh_lock_sock_nested(sk);
> - tcp_sk(sk)->segs_in += max_t(u16, 1, skb_shinfo(skb)->gso_segs);
> + tcp_segs_in(tcp_sk(sk), skb);
> ret = 0;
> if (!sock_owned_by_user(sk)) {
> if (!tcp_prequeue(sk, skb))
> diff --git a/net/ipv4/tcp_minisocks.c b/net/ipv4/tcp_minisocks.c
> index ae90e4b..acb366d 100644
> --- a/net/ipv4/tcp_minisocks.c
> +++ b/net/ipv4/tcp_minisocks.c
> @@ -812,7 +812,7 @@ int tcp_child_process(struct sock *parent, struct sock *child,
> int ret = 0;
> int state = child->sk_state;
>
> - tcp_sk(child)->segs_in += max_t(u16, 1, skb_shinfo(skb)->gso_segs);
> + tcp_segs_in(tcp_sk(child), skb);
> if (!sock_owned_by_user(child)) {
> ret = tcp_rcv_state_process(child, skb);
> /* Wakeup parent, send SIGIO */
> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> index 7d2c7a4..7d2dc01 100644
> --- a/net/ipv4/tcp_output.c
> +++ b/net/ipv4/tcp_output.c
> @@ -1003,8 +1003,10 @@ static int tcp_transmit_skb(struct sock *sk, struct sk_buff *skb, int clone_it,
> if (likely(tcb->tcp_flags & TCPHDR_ACK))
> tcp_event_ack_sent(sk, tcp_skb_pcount(skb));
>
> - if (skb->len != tcp_header_size)
> + if (skb->len != tcp_header_size) {
> tcp_event_data_sent(tp, sk);
> + tp->data_segs_out += tcp_skb_pcount(skb);
> + }
>
> if (after(tcb->end_seq, tp->snd_nxt) || tcb->seq == tcb->end_seq)
> TCP_ADD_STATS(sock_net(sk), TCP_MIB_OUTSEGS,
> diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
> index 33f2820..9c16565 100644
> --- a/net/ipv6/tcp_ipv6.c
> +++ b/net/ipv6/tcp_ipv6.c
> @@ -1443,7 +1443,7 @@ process:
> sk_incoming_cpu_update(sk);
>
> bh_lock_sock_nested(sk);
> - tcp_sk(sk)->segs_in += max_t(u16, 1, skb_shinfo(skb)->gso_segs);
> + tcp_segs_in(tcp_sk(sk), skb);
> ret = 0;
> if (!sock_owned_by_user(sk)) {
> if (!tcp_prequeue(sk, skb))
> --
> 2.5.1
>
^ permalink raw reply
* [PATCH net-next v4] tcp: Add RFC4898 tcpEStatsPerfDataSegsOut/In
From: Martin KaFai Lau @ 2016-03-10 17:29 UTC (permalink / raw)
To: netdev
Cc: Kernel Team, Chris Rapier, Eric Dumazet, Marcelo Ricardo Leitner,
Neal Cardwell, Yuchung Cheng
Per RFC4898, they count segments sent/received
containing a positive length data segment (that includes
retransmission segments carrying data). Unlike
tcpi_segs_out/in, tcpi_data_segs_out/in excludes segments
carrying no data (e.g. pure ack).
The patch also updates the segs_in in tcp_fastopen_add_skb()
so that segs_in >= data_segs_in property is kept. If
tcp_segs_in() helper is used in this fastopen case, tp->segs_in
has to be 0 reset first to avoid double counting. Also, it has
to be done before __skb_pull(skb, tcp_hdrlen(skb)) while
there is no need to check skb->len since skb has already
been confirmed carrying data. I found it more confusing
and chose to directly set segs_in and data_segs_in in
this special case.
Together with retransmission data, tcpi_data_segs_out
gives a better signal on the rxmit rate.
v4: Add comment to the changes in tcp_fastopen_add_skb()
and also add remark on this case in the commit message.
v3: Add const modifier to the skb parameter in tcp_segs_in()
v2: Rework based on recent fix by Eric:
commit a9d99ce28ed3 ("tcp: fix tcpi_segs_in after connection establishment")
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Cc: Chris Rapier <rapier@psc.edu>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Marcelo Ricardo Leitner <mleitner@redhat.com>
Cc: Neal Cardwell <ncardwell@google.com>
Cc: Yuchung Cheng <ycheng@google.com>
---
include/linux/tcp.h | 6 ++++++
include/net/tcp.h | 10 ++++++++++
include/uapi/linux/tcp.h | 2 ++
net/ipv4/tcp.c | 2 ++
net/ipv4/tcp_fastopen.c | 10 ++++++++++
net/ipv4/tcp_ipv4.c | 2 +-
net/ipv4/tcp_minisocks.c | 2 +-
net/ipv4/tcp_output.c | 4 +++-
net/ipv6/tcp_ipv6.c | 2 +-
9 files changed, 36 insertions(+), 4 deletions(-)
diff --git a/include/linux/tcp.h b/include/linux/tcp.h
index bcbf51d..7be9b12 100644
--- a/include/linux/tcp.h
+++ b/include/linux/tcp.h
@@ -158,6 +158,9 @@ struct tcp_sock {
u32 segs_in; /* RFC4898 tcpEStatsPerfSegsIn
* total number of segments in.
*/
+ u32 data_segs_in; /* RFC4898 tcpEStatsPerfDataSegsIn
+ * total number of data segments in.
+ */
u32 rcv_nxt; /* What we want to receive next */
u32 copied_seq; /* Head of yet unread data */
u32 rcv_wup; /* rcv_nxt on last window update sent */
@@ -165,6 +168,9 @@ struct tcp_sock {
u32 segs_out; /* RFC4898 tcpEStatsPerfSegsOut
* The total number of segments sent.
*/
+ u32 data_segs_out; /* RFC4898 tcpEStatsPerfDataSegsOut
+ * total number of data segments sent.
+ */
u64 bytes_acked; /* RFC4898 tcpEStatsAppHCThruOctetsAcked
* sum(delta(snd_una)), or how many bytes
* were acked.
diff --git a/include/net/tcp.h b/include/net/tcp.h
index e90db85..24557a8 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -1816,4 +1816,14 @@ static inline void skb_set_tcp_pure_ack(struct sk_buff *skb)
skb->truesize = 2;
}
+static inline void tcp_segs_in(struct tcp_sock *tp, const struct sk_buff *skb)
+{
+ u16 segs_in;
+
+ segs_in = max_t(u16, 1, skb_shinfo(skb)->gso_segs);
+ tp->segs_in += segs_in;
+ if (skb->len > tcp_hdrlen(skb))
+ tp->data_segs_in += segs_in;
+}
+
#endif /* _TCP_H */
diff --git a/include/uapi/linux/tcp.h b/include/uapi/linux/tcp.h
index fe95446..53e8e3f 100644
--- a/include/uapi/linux/tcp.h
+++ b/include/uapi/linux/tcp.h
@@ -199,6 +199,8 @@ struct tcp_info {
__u32 tcpi_notsent_bytes;
__u32 tcpi_min_rtt;
+ __u32 tcpi_data_segs_in; /* RFC4898 tcpEStatsDataSegsIn */
+ __u32 tcpi_data_segs_out; /* RFC4898 tcpEStatsDataSegsOut */
};
/* for TCP_MD5SIG socket option */
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index f9faadb..6b01b48 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -2728,6 +2728,8 @@ void tcp_get_info(struct sock *sk, struct tcp_info *info)
info->tcpi_notsent_bytes = max(0, notsent_bytes);
info->tcpi_min_rtt = tcp_min_rtt(tp);
+ info->tcpi_data_segs_in = tp->data_segs_in;
+ info->tcpi_data_segs_out = tp->data_segs_out;
}
EXPORT_SYMBOL_GPL(tcp_get_info);
diff --git a/net/ipv4/tcp_fastopen.c b/net/ipv4/tcp_fastopen.c
index fdb286d..74068e6 100644
--- a/net/ipv4/tcp_fastopen.c
+++ b/net/ipv4/tcp_fastopen.c
@@ -131,6 +131,7 @@ static bool tcp_fastopen_cookie_gen(struct request_sock *req,
void tcp_fastopen_add_skb(struct sock *sk, struct sk_buff *skb)
{
struct tcp_sock *tp = tcp_sk(sk);
+ u16 segs_in;
if (TCP_SKB_CB(skb)->end_seq == tp->rcv_nxt)
return;
@@ -154,6 +155,15 @@ void tcp_fastopen_add_skb(struct sock *sk, struct sk_buff *skb)
* as we certainly are not changing upper 32bit value (0)
*/
tp->bytes_received = skb->len;
+ /* If tcp_segs_in() is used, we need
+ * to reset segs_in = 0 first to avoid double counting.
+ * Hence, segs_in and data_segs_in are direclty set here.
+ * Also, there is no need to check the skb->len as tcp_segs_in()
+ * does because skb is confirmed carrying data here.
+ */
+ segs_in = max_t(u16, 1, skb_shinfo(skb)->gso_segs);
+ tp->segs_in = segs_in;
+ tp->data_segs_in = segs_in;
if (TCP_SKB_CB(skb)->tcp_flags & TCPHDR_FIN)
tcp_fin(sk);
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 4c8d58d..0b02ef7 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1650,7 +1650,7 @@ process:
sk_incoming_cpu_update(sk);
bh_lock_sock_nested(sk);
- tcp_sk(sk)->segs_in += max_t(u16, 1, skb_shinfo(skb)->gso_segs);
+ tcp_segs_in(tcp_sk(sk), skb);
ret = 0;
if (!sock_owned_by_user(sk)) {
if (!tcp_prequeue(sk, skb))
diff --git a/net/ipv4/tcp_minisocks.c b/net/ipv4/tcp_minisocks.c
index ae90e4b..acb366d 100644
--- a/net/ipv4/tcp_minisocks.c
+++ b/net/ipv4/tcp_minisocks.c
@@ -812,7 +812,7 @@ int tcp_child_process(struct sock *parent, struct sock *child,
int ret = 0;
int state = child->sk_state;
- tcp_sk(child)->segs_in += max_t(u16, 1, skb_shinfo(skb)->gso_segs);
+ tcp_segs_in(tcp_sk(child), skb);
if (!sock_owned_by_user(child)) {
ret = tcp_rcv_state_process(child, skb);
/* Wakeup parent, send SIGIO */
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 7d2c7a4..7d2dc01 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1003,8 +1003,10 @@ static int tcp_transmit_skb(struct sock *sk, struct sk_buff *skb, int clone_it,
if (likely(tcb->tcp_flags & TCPHDR_ACK))
tcp_event_ack_sent(sk, tcp_skb_pcount(skb));
- if (skb->len != tcp_header_size)
+ if (skb->len != tcp_header_size) {
tcp_event_data_sent(tp, sk);
+ tp->data_segs_out += tcp_skb_pcount(skb);
+ }
if (after(tcb->end_seq, tp->snd_nxt) || tcb->seq == tcb->end_seq)
TCP_ADD_STATS(sock_net(sk), TCP_MIB_OUTSEGS,
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index 33f2820..9c16565 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -1443,7 +1443,7 @@ process:
sk_incoming_cpu_update(sk);
bh_lock_sock_nested(sk);
- tcp_sk(sk)->segs_in += max_t(u16, 1, skb_shinfo(skb)->gso_segs);
+ tcp_segs_in(tcp_sk(sk), skb);
ret = 0;
if (!sock_owned_by_user(sk)) {
if (!tcp_prequeue(sk, skb))
--
2.5.1
^ permalink raw reply related
* Re: [PATCH net-next 2/3] xen-netback: support multiple extra info fragments passed from frontend
From: Wei Liu @ 2016-03-10 17:23 UTC (permalink / raw)
To: Paul Durrant; +Cc: netdev, xen-devel, Wei Liu
In-Reply-To: <1457613028-10381-3-git-send-email-paul.durrant@citrix.com>
On Thu, Mar 10, 2016 at 12:30:27PM +0000, Paul Durrant wrote:
> The code does not currently support a frontend passing multiple extra info
> fragments to the backend in a tx request. The xenvif_get_extras() function
> handles multiple extra_info fragments but make_tx_response() assumes there
> is only ever a single extra info fragment.
>
> This patch modifies xenvif_get_extras() to pass back a count of extra
> info fragments, which is then passed to make_tx_response() (after
> possibly being stashed in pending_tx_info for deferred responses).
>
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> Cc: Wei Liu <wei.liu2@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
^ permalink raw reply
* Re: [PATCH net-next 1/3] xen-netback: re-import canonical netif header
From: Wei Liu @ 2016-03-10 17:23 UTC (permalink / raw)
To: Paul Durrant
Cc: netdev, xen-devel, Konrad Rzeszutek Wilk, Boris Ostrovsky,
David Vrabel, Wei Liu
In-Reply-To: <1457613028-10381-2-git-send-email-paul.durrant@citrix.com>
On Thu, Mar 10, 2016 at 12:30:26PM +0000, Paul Durrant wrote:
> The canonical netif header (in the Xen source repo) and the Linux variant
> have diverged significantly. Recently much documentation has been added to
> the canonical header which is highly useful for developers making
> modifications to either xen-netfront or xen-netback. This patch therefore
> re-imports the canonical header in its entirity.
>
> To maintain compatibility and some style consistency with the old Linux
> variant, the header was stripped of its emacs boilerplate, and
> post-processed and copied into place with the following commands:
>
> ed -s netif.h << EOF
> H
> ,s/NETTXF_/XEN_NETTXF_/g
> ,s/NETRXF_/XEN_NETRXF_/g
> ,s/NETIF_/XEN_NETIF_/g
> ,s/XEN_XEN_/XEN_/g
> ,s/netif/xen_netif/g
> ,s/xen_xen_/xen_/g
> ,s/^typedef.*$//g
> ,s/^ /${TAB}/g
> w
> $
> w
> EOF
>
> indent --line-length 80 --linux-style netif.h \
> -o include/xen/interface/io/netif.h
>
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Cc: David Vrabel <david.vrabel@citrix.com>
> Cc: Wei Liu <wei.liu2@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
^ permalink raw reply
* Re: [PATCH net-next 3/3] xen-netback: reduce log spam
From: Wei Liu @ 2016-03-10 17:23 UTC (permalink / raw)
To: Paul Durrant; +Cc: netdev, xen-devel, Wei Liu
In-Reply-To: <1457613028-10381-4-git-send-email-paul.durrant@citrix.com>
On Thu, Mar 10, 2016 at 12:30:28PM +0000, Paul Durrant wrote:
> Remove the "prepare for reconnect" pr_info in xenbus.c. It's largely
> uninteresting and the states of the frontend and backend can easily be
> observed by watching the (o)xenstored log.
>
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> Cc: Wei Liu <wei.liu2@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
> ---
> drivers/net/xen-netback/xenbus.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
> index 39a303d..bd182cd 100644
> --- a/drivers/net/xen-netback/xenbus.c
> +++ b/drivers/net/xen-netback/xenbus.c
> @@ -511,8 +511,6 @@ static void set_backend_state(struct backend_info *be,
> switch (state) {
> case XenbusStateInitWait:
> case XenbusStateConnected:
> - pr_info("%s: prepare for reconnect\n",
> - be->dev->nodename);
> backend_switch_state(be, XenbusStateInitWait);
> break;
> case XenbusStateClosing:
> --
> 2.1.4
>
^ permalink raw reply
* Re: [net-next PATCH V3 1/3] net: adjust napi_consume_skb to handle none-NAPI callers
From: Sergei Shtylyov @ 2016-03-10 17:21 UTC (permalink / raw)
To: Jesper Dangaard Brouer, netdev, David S. Miller
Cc: eugenia, Alexander Duyck, alexei.starovoitov, saeedm, gerlitz.or
In-Reply-To: <20160310145911.22901.28762.stgit@firesoul>
Hello.
On 03/10/2016 05:59 PM, Jesper Dangaard Brouer wrote:
> Some drivers reuse/share code paths that free SKBs between NAPI
> and none-NAPI calls. Adjust napi_consume_skb to handle this
> use-case.
>
> Before, calls from netpoll (w/ IRQs disabled) was handled and
> indicated with a budget zero indication. Use the same zero
> indication to handle calls not originating from NAPI/softirq.
> Simply handled by using dev_consume_skb_any().
>
> This adds an extra branch+call for the netpoll case (checking
> in_irq() + irqs_disabled()), but that is okay as this is a slowpath.
>
> Suggested-by: Alexander Duyck <aduyck@mirantis.com>
> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
> ---
> net/core/skbuff.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 7af7ec635d90..bc62baa54ceb 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -801,9 +801,9 @@ void napi_consume_skb(struct sk_buff *skb, int budget)
> if (unlikely(!skb))
> return;
>
> - /* if budget is 0 assume netpoll w/ IRQs disabled */
> + /* Zero budget indicate none-NAPI context called us, like netpoll */
Non-NAPI?
[...]
MBR, Sergei
^ permalink raw reply
* Re: Micrel Phy - Is there a way to configure the Phy not to do 802.3x flow control?
From: Murali Karicheri @ 2016-03-10 16:48 UTC (permalink / raw)
To: Florian Fainelli, johan, open list:TI NETCP ETHERNET DRIVER,
Kwok, WingMan
In-Reply-To: <56D8D3D7.6070900@gmail.com>
On 03/03/2016 07:16 PM, Florian Fainelli wrote:
> On 03/03/16 14:18, Murali Karicheri wrote:
>> Hi,
>>
>> We are using Micrel Phy in one of our board and wondering if we can force the
>> Phy to disable flow control at start. I have a 1G ethernet switch connected
>> to Phy and the phy always enable flow control. I would like to configure the
>> phy not to flow control. Is that possible and if yes, what should I do in the
>> my Ethernet driver to tell the Phy not to enable flow control?
>
> The PHY is not doing flow control per-se, your pseudo Ethernet MAC in
> the switch is doing, along with the link partner advertising support for
> it. You would want to make sure that your PHY device interface (provided
> that you are using the PHY library) is not starting with Pause
> advertised, but it could be supported.
Understood that Phy is just advertise FC. The Micrel phy for 9031 advertise
by default FC supported. After negotiation, I see that Phylib provide the
link status with parameter pause = 1, asym_pause = 1. How do I tell the Phy not
to advertise?
I call following sequence in the Ethernet driver.
of_phy_connect(x,y,hndlr,a,z);
phy_start()
Now in hndlr() I have pause = 1, asym_pause = 1, in phy_device ptr. How can
I tell the phy not to advertise initially?
Murali
>
> As Andrew indicated the proper way to do this is do to use ethtool if
> you need to this dynamically.
>
--
Murali Karicheri
Linux Kernel, Keystone
^ permalink raw reply
* Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement
From: Dinh Nguyen @ 2016-03-10 16:47 UTC (permalink / raw)
To: Giuseppe CAVALLARO
Cc: Tomeu Vizoso, Andreas Färber, Fabrice GASNIER,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Heiko Stübner, netdev-u79uwXL29TY76Z2rM5mHXA,
open list:ARM/Rockchip SoC..., LAKML, Gabriel Fernandez,
Alexandre TORGUE, Frank Schäfer, LKML
In-Reply-To: <56E13AAB.2080900-qxv4g6HH51o@public.gmane.org>
On Thu, Mar 10, 2016 at 3:13 AM, Giuseppe CAVALLARO
<peppe.cavallaro-qxv4g6HH51o@public.gmane.org> wrote:
> On 3/9/2016 5:31 PM, Dinh Nguyen wrote:
>>
>> On Wed, Mar 9, 2016 at 8:53 AM, Giuseppe CAVALLARO
>> <peppe.cavallaro-qxv4g6HH51o@public.gmane.org> wrote:
>>>
>>> Hi Tomeu, Dinh, Andreas
>>>
>>> I need a sum and help from you to go ahead on the
>>> tx timeout.
>>>
>>> The "stmmac: MDIO fixes" seems to be the candidate to
>>> fix the phy connection and I will send the V2 asap (Andreas' comment).
>>>
>>> So, supposing the probe is ok and phy is connected,
>>> I need your input ...
>>>
>>> Tomeu: after revering the 0e80bdc9a72d (stmmac: first frame
>>> prep at the end of xmit routine) the network is
>>> not stable and there is a timeout after a while.
>>> The box has 3.50 with normal desc settings.
>>>
>>> Dinh: the network is ok, I wonder if you can share a boot
>>> log just to understand if the normal or enhanced
>>> descriptors are used.
>>>
>>
>> Here it is:
>
> ...
>>
>> [ 0.850523] stmmac - user ID: 0x10, Synopsys ID: 0x37
>> [ 0.855570] Ring mode enabled
>> [ 0.858611] DMA HW capability register supported
>> [ 0.863128] Enhanced/Alternate descriptors
>> [ 0.867482] Enabled extended descriptors
>> [ 0.871482] RX Checksum Offload Engine supported (type 2)
>> [ 0.876948] TX Checksum insertion supported
>> [ 0.881204] Enable RX Mitigation via HW Watchdog Timer
>> [ 0.886863] socfpga-dwmac ff702000.ethernet eth0: No MDIO subnode found
>> [ 0.899090] libphy: stmmac: probed
>> [ 0.902484] eth0: PHY ID 00221611 at 4 IRQ POLL (stmmac-0:04) active
>
>
> Thx Dinh, so you are using the Enhanced/Alternate descriptors
> I am debugging on my side on a setup with normal descriptors, I let you
> know
>
Doesn't the printout "Enhanced/Alternate descriptors" mean that I'm using
Enhanced/Alternate descriptors?
Dinh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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 2/2] isdn: i4l: move active-isdn drivers to staging
From: isdn @ 2016-03-10 16:41 UTC (permalink / raw)
To: Paul Bolle
Cc: devel, Arnd Bergmann, linux-doc, Greg Kroah-Hartman,
Jonathan Corbet, linux-kernel, Tilman Schmidt, netdev,
Christoph Biedl, David S. Miller, linux-arm-kernel
In-Reply-To: <1457614704.2478.11.camel@tiscali.nl>
Am 10.03.2016 um 13:58 schrieb Paul Bolle:
> Hi Karsten,
>
> On do, 2016-03-10 at 11:53 +0100, isdn@linux-pingi.de wrote:
>> mISDN with CAPI support works just fine with pppd and pppdcapiplugin
>> and the CAPI works for all mISDN HW.
>
> In the mainline tree the mISDN and CAPI stacks are effectively separate.
> Do you perhaps refer to a mISDN + Asterisk + chan-capi setup? (That's
> the closest to mISDN with CAPI support that I could find. Did I miss
> something?)
http://listserv.isdn4linux.de/pipermail/isdn4linux/2012-January/005580.html
Since 2012 mISDN has a cAPI20 interface, pure in userspace.
Everything is in the capi20 subdirectory of mISDNuser.
The capi20 support need to be enabled with ./configure.
Has nothing to do with Asterisk, but for FAX it is useing the same DSP
library, spandsp.
Best
Karsten Keil
^ permalink raw reply
* Re: [PATCH] mrf24j40: fix security-enabled processing on inbound frames
From: Stefan Schmidt @ 2016-03-10 16:40 UTC (permalink / raw)
To: Alan Ott, zopieux, linux-wpan; +Cc: netdev, Alexander Aring
In-Reply-To: <56D4A0C2.5090605@signal11.us>
Hello.
On 29/02/16 20:49, Alan Ott wrote:
> On 02/18/2016 01:34 PM, zopieux wrote:
>> Fix the MRF24J40 handling of security-enabled frames so it does not
>> block upon receiving such frames.
>>
>> Signed-off-by: Alexander Aring <aar@pengutronix.de>
>> Reported-by: Alexandre Macabies <web+oss@zopieux.com>
>> Tested-by: Alexandre Macabies <web+oss@zopieux.com>
>> ---
>> When receiving a security-enabled IEEE 802.15.4 frame, the MRF24J40
>> triggers a SECIF interrupt that needs to be handled for RX processing
>> to keep functioning properly.
>>
>> This patch enables the SECIF interrupt and makes the MRF ignores all
>> hardware processing of security-enabled frames, that is handled by the
>> ieee802154 stack instead.
>> ---
>
> The "From" field of the email needs to have your real name in it. This
> will be where the "Author" field in git comes from.
>
> It looks like there are a few separate things happening in this patch.
> Maybe they should be broken out in to separate patches. I see:
>
> 1. The ieee802154.h part,
> 2. The TX part,
> 3. The RX part.
>
> The patch description only really describes the RX part.
>
zopieux, could you split the patch as Alan suggested and re-submitted
the series?
regards
Stefan Schmidt
^ permalink raw reply
* Re: [GIT PULL v2 0/4] IPVS Fixes for v4.5
From: Pablo Neira Ayuso @ 2016-03-10 16:39 UTC (permalink / raw)
To: Simon Horman
Cc: lvs-devel, netdev, netfilter-devel, Wensong Zhang,
Julian Anastasov
In-Reply-To: <1457319814-8027-1-git-send-email-horms@verge.net.au>
On Mon, Mar 07, 2016 at 12:03:30PM +0900, Simon Horman wrote:
> Hi Pablo,
>
> please consider these IPVS fixes for v4.5 or
> if it is too late please consider them for v4.6.
Pulled into nf-next, thanks Simon!
^ permalink raw reply
* [PATCH v2 net-next] ovs: allow nl 'flow set' to use ufid without flow key
From: Samuel Gauthier @ 2016-03-10 16:14 UTC (permalink / raw)
To: Pravin Shelar, David S. Miller; +Cc: netdev, dev, Samuel Gauthier
In-Reply-To: <CAMEOZhK0kBpdS8uOqYqzQs+6LyWh5K3MWL__CRoThmNRnBN2MQ@mail.gmail.com>
When we want to change a flow using netlink, we have to identify it to
be able to perform a lookup. Both the flow key and unique flow ID
(ufid) are valid identifiers, but we always have to specify the flow
key in the netlink message. When both attributes are there, the ufid
is used. The flow key is used to validate the actions provided by
the userland.
This commit allows to use the ufid without having to provide the flow
key, as it is already done in the netlink 'flow get' and 'flow del'
path. The flow key remains mandatory when an action is provided.
Signed-off-by: Samuel Gauthier <samuel.gauthier@6wind.com>
---
v2:
- Restore mask init and parsing
- Keep the flow key mandatory when an action is provided
net/openvswitch/datapath.c | 28 +++++++++++++++++-----------
1 file changed, 17 insertions(+), 11 deletions(-)
diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
index deadfdab1bc3..db6858f2f67a 100644
--- a/net/openvswitch/datapath.c
+++ b/net/openvswitch/datapath.c
@@ -1100,26 +1100,32 @@ static int ovs_flow_cmd_set(struct sk_buff *skb, struct genl_info *info)
struct sw_flow_match match;
struct sw_flow_id sfid;
u32 ufid_flags = ovs_nla_get_ufid_flags(a[OVS_FLOW_ATTR_UFID_FLAGS]);
- int error;
+ int error = 0;
bool log = !a[OVS_FLOW_ATTR_PROBE];
bool ufid_present;
- /* Extract key. */
- error = -EINVAL;
- if (!a[OVS_FLOW_ATTR_KEY]) {
- OVS_NLERR(log, "Flow key attribute not present in set flow.");
- goto error;
- }
-
ufid_present = ovs_nla_get_ufid(&sfid, a[OVS_FLOW_ATTR_UFID], log);
- ovs_match_init(&match, &key, &mask);
- error = ovs_nla_get_match(net, &match, a[OVS_FLOW_ATTR_KEY],
- a[OVS_FLOW_ATTR_MASK], log);
+ if (a[OVS_FLOW_ATTR_KEY]) {
+ ovs_match_init(&match, &key, &mask);
+ error = ovs_nla_get_match(net, &match, a[OVS_FLOW_ATTR_KEY],
+ a[OVS_FLOW_ATTR_MASK], log);
+ } else if (!ufid_present) {
+ OVS_NLERR(log,
+ "Flow set message rejected, Key attribute missing.");
+ error = -EINVAL;
+ }
if (error)
goto error;
/* Validate actions. */
if (a[OVS_FLOW_ATTR_ACTIONS]) {
+ if (!a[OVS_FLOW_ATTR_KEY]) {
+ OVS_NLERR(log,
+ "Flow key attribute not present in set flow.");
+ error = -EINVAL;
+ goto error;
+ }
+
acts = get_flow_actions(net, a[OVS_FLOW_ATTR_ACTIONS], &key,
&mask, log);
if (IS_ERR(acts)) {
--
2.2.1.62.g3f15098
^ permalink raw reply related
* Re: [PATCH 2/2] net/forcedeth: add wol p support
From: Karol Herbst @ 2016-03-10 16:13 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev, David S . Miller
In-Reply-To: <1457621884-2479-3-git-send-email-git@karolherbst.de>
one note though:
I am not _really_ sure it is the right flag. I've contacted somebody at nvidia
and asked for documentation regarding this mmio reg.
I still get some random wakeups and I don't know where they are comming from.
> Karol Herbst <git@karolherbst.de> hat am 10. März 2016 um 15:58 geschrieben:
>
>
> REd on my mac mini. No idea if that also works on other ethernet cards
> supported by forcedeth, but I doubt anybody cares at all, otherwise somebody
> else would have REd it already.
>
> Signed-off-by: Karol Herbst <nouveau@karolherbst.de>
> ---
> drivers/net/ethernet/nvidia/forcedeth.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/nvidia/forcedeth.c
> b/drivers/net/ethernet/nvidia/forcedeth.c
> index bdce33b..8e4e894 100644
> --- a/drivers/net/ethernet/nvidia/forcedeth.c
> +++ b/drivers/net/ethernet/nvidia/forcedeth.c
> @@ -291,6 +291,7 @@ enum {
> #define NVREG_WAKEUPFLAGS_ACCEPT_WAKEUPPAT 0x02
> #define NVREG_WAKEUPFLAGS_ACCEPT_LINKCHANGE 0x04
> #define NVREG_WAKEUPFLAGS_ENABLE_G 0x01111
> +#define NVREG_WAKEUPFLAGS_ENABLE_P 0x12000
>
> NvRegMgmtUnitGetVersion = 0x204,
> #define NVREG_MGMTUNITGETVERSION 0x01
> @@ -4216,12 +4217,14 @@ static void nv_get_drvinfo(struct net_device *dev,
> struct ethtool_drvinfo *info)
> static void nv_get_wol(struct net_device *dev, struct ethtool_wolinfo
> *wolinfo)
> {
> struct fe_priv *np = netdev_priv(dev);
> - wolinfo->supported = WAKE_MAGIC;
> + wolinfo->supported = WAKE_MAGIC | WAKE_PHY;
>
> spin_lock_irq(&np->lock);
> wolinfo->wolopts = 0;
> if (np->wolenabled & WAKE_MAGIC)
> wolinfo->wolopts |= WAKE_MAGIC;
> + if (np->wolenabled & WAKE_PHY)
> + wolinfo->wolopts |= WAKE_PHY;
> spin_unlock_irq(&np->lock);
> }
>
> @@ -4236,6 +4239,10 @@ static int nv_set_wol(struct net_device *dev, struct
> ethtool_wolinfo *wolinfo)
> np->wolenabled |= WAKE_MAGIC;
> np->wol_flags |= NVREG_WAKEUPFLAGS_ENABLE_G;
> }
> + if (wolinfo->wolopts & WAKE_PHY) {
> + np->wolenabled |= WAKE_PHY;
> + np->wol_flags |= NVREG_WAKEUPFLAGS_ENABLE_P;
> + }
> if (netif_running(dev)) {
> spin_lock_irq(&np->lock);
> writel(np->wol_flags, base + NvRegWakeUpFlags);
> --
> 2.7.2
>
^ permalink raw reply
* [PATCH] net: macb: fix default configuration for GMAC on AT91
From: Nicolas Ferre @ 2016-03-10 15:44 UTC (permalink / raw)
To: linux-arm-kernel, David S. Miller, netdev, Cyrille Pitchen
Cc: linux-kernel, Alexandre Belloni, Boris BREZILLON, romain.henriet,
michal.simek, punnaia, Nicolas Ferre
On AT91 SoCs, the User Register (USRIO) exposes a switch to configure the
"Reduced" or "Traditional" version of the Media Independent Interface
(RMII vs. MII or RGMII vs. GMII).
As on the older EMAC version, on GMAC, this switch is set by default to the
non-reduced type of interface, so use the existing capability and extend it to
GMII as well. We then keep the current logic in the macb_init() function.
The capabilities of sama5d2, sama5d4 and sama5d3 GEM interface are updated in
the macb_config structure to be able to properly enable them with a traditional
interface (GMII or MII).
Reported-by: Romain HENRIET <romain.henriet@l-acoustics.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
drivers/net/ethernet/cadence/macb.c | 13 +++++++------
drivers/net/ethernet/cadence/macb.h | 2 +-
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
index 7ccf2298a5fa..3ce6095ced3d 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -2440,9 +2440,9 @@ static int macb_init(struct platform_device *pdev)
if (bp->phy_interface == PHY_INTERFACE_MODE_RGMII)
val = GEM_BIT(RGMII);
else if (bp->phy_interface == PHY_INTERFACE_MODE_RMII &&
- (bp->caps & MACB_CAPS_USRIO_DEFAULT_IS_MII))
+ (bp->caps & MACB_CAPS_USRIO_DEFAULT_IS_MII_GMII))
val = MACB_BIT(RMII);
- else if (!(bp->caps & MACB_CAPS_USRIO_DEFAULT_IS_MII))
+ else if (!(bp->caps & MACB_CAPS_USRIO_DEFAULT_IS_MII_GMII))
val = MACB_BIT(MII);
if (bp->caps & MACB_CAPS_USRIO_HAS_CLKEN)
@@ -2774,7 +2774,7 @@ static int at91ether_init(struct platform_device *pdev)
}
static const struct macb_config at91sam9260_config = {
- .caps = MACB_CAPS_USRIO_HAS_CLKEN | MACB_CAPS_USRIO_DEFAULT_IS_MII,
+ .caps = MACB_CAPS_USRIO_HAS_CLKEN | MACB_CAPS_USRIO_DEFAULT_IS_MII_GMII,
.clk_init = macb_clk_init,
.init = macb_init,
};
@@ -2787,21 +2787,22 @@ static const struct macb_config pc302gem_config = {
};
static const struct macb_config sama5d2_config = {
- .caps = 0,
+ .caps = MACB_CAPS_USRIO_DEFAULT_IS_MII_GMII,
.dma_burst_length = 16,
.clk_init = macb_clk_init,
.init = macb_init,
};
static const struct macb_config sama5d3_config = {
- .caps = MACB_CAPS_SG_DISABLED | MACB_CAPS_GIGABIT_MODE_AVAILABLE,
+ .caps = MACB_CAPS_SG_DISABLED | MACB_CAPS_GIGABIT_MODE_AVAILABLE
+ | MACB_CAPS_USRIO_DEFAULT_IS_MII_GMII,
.dma_burst_length = 16,
.clk_init = macb_clk_init,
.init = macb_init,
};
static const struct macb_config sama5d4_config = {
- .caps = 0,
+ .caps = MACB_CAPS_USRIO_DEFAULT_IS_MII_GMII,
.dma_burst_length = 4,
.clk_init = macb_clk_init,
.init = macb_init,
diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h
index 9ba416d5afff..8a13824ef802 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -400,7 +400,7 @@
/* Capability mask bits */
#define MACB_CAPS_ISR_CLEAR_ON_WRITE 0x00000001
#define MACB_CAPS_USRIO_HAS_CLKEN 0x00000002
-#define MACB_CAPS_USRIO_DEFAULT_IS_MII 0x00000004
+#define MACB_CAPS_USRIO_DEFAULT_IS_MII_GMII 0x00000004
#define MACB_CAPS_NO_GIGABIT_HALF 0x00000008
#define MACB_CAPS_USRIO_DISABLED 0x00000010
#define MACB_CAPS_FIFO_MODE 0x10000000
--
2.1.3
^ permalink raw reply related
* Re: [RFC] net: ipv4 -- Introduce ifa limit per net
From: Cyrill Gorcunov @ 2016-03-10 15:09 UTC (permalink / raw)
To: David Miller, alexei.starovoitov, eric.dumazet
Cc: netdev, solar, vvs, avagin, xemul, vdavydov, khorenko, pablo,
netfilter-devel
In-Reply-To: <20160310110324.GB21154@uranus.lan>
On Thu, Mar 10, 2016 at 02:03:24PM +0300, Cyrill Gorcunov wrote:
> On Thu, Mar 10, 2016 at 01:20:18PM +0300, Cyrill Gorcunov wrote:
> > On Thu, Mar 10, 2016 at 12:16:29AM +0300, Cyrill Gorcunov wrote:
> > >
> > > Thanks for explanation, Dave! I'll continue on this task tomorrow
> > > tryin to implement optimization you proposed.
> >
> > OK, here are the results for the preliminary patch with conntrack running
> ...
> > net/ipv4/devinet.c | 13 ++++++++++++-
> > 1 file changed, 12 insertions(+), 1 deletion(-)
> >
> > Index: linux-ml.git/net/ipv4/devinet.c
> > ===================================================================
> > --- linux-ml.git.orig/net/ipv4/devinet.c
> > +++ linux-ml.git/net/ipv4/devinet.c
> > @@ -403,7 +403,18 @@ no_promotions:
> > So that, this order is correct.
> > */
>
> This patch is wrong, so drop it please. I'll do another.
Here I think is a better variant. The resulst are good
enough -- 1 sec for cleanup. Does the patch look sane?
---
net/ipv4/netfilter/nf_nat_masquerade_ipv4.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
Index: linux-ml.git/net/ipv4/netfilter/nf_nat_masquerade_ipv4.c
===================================================================
--- linux-ml.git.orig/net/ipv4/netfilter/nf_nat_masquerade_ipv4.c
+++ linux-ml.git/net/ipv4/netfilter/nf_nat_masquerade_ipv4.c
@@ -108,9 +108,22 @@ static int masq_inet_event(struct notifi
unsigned long event,
void *ptr)
{
- struct net_device *dev = ((struct in_ifaddr *)ptr)->ifa_dev->dev;
+ struct in_ifaddr *ifa = ptr;
+ struct net_device *dev = ifa->ifa_dev->dev;
struct netdev_notifier_info info;
+ if (event == NETDEV_DOWN) {
+ /*
+ * When we meet dead device which is
+ * being released with dozeon of addresses
+ * assigned -- we can optimize calls
+ * to conntrack cleanups and do it only
+ * once.
+ */
+ if (ifa->ifa_dev->dead && ifa->ifa_next)
+ return NOTIFY_DONE;
+ }
+
netdev_notifier_info_init(&info, dev);
return masq_device_event(this, event, &info);
}
^ 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