* Re: davinci-mdio: failing to connect to PHY
From: Andrew Lunn @ 2016-04-04 13:58 UTC (permalink / raw)
To: Petr Kulhavy; +Cc: netdev
In-Reply-To: <5702710A.5010804@barix.com>
On Mon, Apr 04, 2016 at 03:50:02PM +0200, Petr Kulhavy wrote:
>
>
> On 04.04.2016 14:31, Andrew Lunn wrote:
> >Hi Petr
> >
> >You might want to take a look at:
> >
> >http://lxr.free-electrons.com/source/drivers/net/ethernet/ti/davinci_mdio.c#L137
> >
> >It seems to be asking the hardware about the phy mask.
> >
> > Andrew
>
> Hi Andrew,
>
> thanks a lot for the link. In the meantime I've understood the issue
> better. It is due to the fact that the PHY is pin-strapped to
> address 1 and broadcast (at address 0) is enabled. The Micrel
> driver's config_init() disables the broadcast and the PHY stops
> responding, which causes the troubles. The kernel 3.17 didn't
> disable the broadcast and therefore it worked.
>
> I'm wondering how to solve or workaround this...
One option is in your device tree is to explicitly list the phy on
your mdio bus. Something like:
&mdio {
status = "okay";
ethphy0: ethernet-phy@1 {
reg = <1>;
};
};
This alone might be sufficient. If not, you need to reference the phy
via a phandle in the ethernet node.
ð0 {
status = "okay";
phy-handle = <ðphy0>;
};
Andrew
^ permalink raw reply
* Re: davinci-mdio: failing to connect to PHY
From: Petr Kulhavy @ 2016-04-04 13:50 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev
In-Reply-To: <20160404123145.GE21828@lunn.ch>
On 04.04.2016 14:31, Andrew Lunn wrote:
>
> Hi Petr
>
> You might want to take a look at:
>
> http://lxr.free-electrons.com/source/drivers/net/ethernet/ti/davinci_mdio.c#L137
>
> It seems to be asking the hardware about the phy mask.
>
> Andrew
Hi Andrew,
thanks a lot for the link. In the meantime I've understood the issue
better. It is due to the fact that the PHY is pin-strapped to address 1
and broadcast (at address 0) is enabled. The Micrel driver's
config_init() disables the broadcast and the PHY stops responding, which
causes the troubles. The kernel 3.17 didn't disable the broadcast and
therefore it worked.
I'm wondering how to solve or workaround this...
Petr
^ permalink raw reply
* Your Urgent Respond,
From: Mr Michael Gary @ 2016-04-04 13:44 UTC (permalink / raw)
To: DHS
Urgent Founds!!
We wish to inform you that your over due Inheritance funds which we agreed to pay you in cash is already sealed and package with a security proof box. The funds worth of $7.5 millions US Dollar,in the package will be conveyed to you by an Int'l diplomatic agent, Mr. Jeff Bernard. He will be leaving for your country any time from now, therefore reach us with the details below.
Using a Diplomatic agent this time is because of the failure that were recorded in the other transfer options. Just try and give the diplomat your information and offer him all assistance he may need, especially directive assistance so that he will be able to get your consignment box to you in the couple of days.
Please contact him with your full information, such as your.
1) Full name: ......
2) Resident address:......
3) Phone number:.....
4) The name of your nearest airport:....
Send him the information above for him to locate your home with your package.
Below is some of his contact information:
Name: Jeff Bernard
Email: (dipjeffbernard@hotmail.com).
Feel free and call your fund's original bank at +229-982-92-026, any time you wish for more explanation.
Best Regard
Mr Michael Gary
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
^ permalink raw reply
* Re: [RFC PATCH 1/5] bpf: add PHYS_DEV prog type for early driver filter
From: Daniel Borkmann @ 2016-04-04 13:36 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Brenden Blanco, davem, netdev, tom, alexei.starovoitov, gerlitz,
john.fastabend
In-Reply-To: <20160404150700.1456ae80@redhat.com>
On 04/04/2016 03:07 PM, Jesper Dangaard Brouer wrote:
> On Mon, 04 Apr 2016 10:49:09 +0200 Daniel Borkmann <daniel@iogearbox.net> wrote:
>> On 04/02/2016 03:21 AM, Brenden Blanco wrote:
>>> Add a new bpf prog type that is intended to run in early stages of the
>>> packet rx path. Only minimal packet metadata will be available, hence a new
>>> context type, struct xdp_metadata, is exposed to userspace. So far only
>>> expose the readable packet length, and only in read mode.
>>>
>>> The PHYS_DEV name is chosen to represent that the program is meant only
>>> for physical adapters, rather than all netdevs.
>>>
>>> While the user visible struct is new, the underlying context must be
>>> implemented as a minimal skb in order for the packet load_* instructions
>>> to work. The skb filled in by the driver must have skb->len, skb->head,
>>> and skb->data set, and skb->data_len == 0.
>>>
> [...]
>>
>> Do you plan to support bpf_skb_load_bytes() as well? I like using
>> this API especially when dealing with larger chunks (>4 bytes) to
>> load into stack memory, plus content is kept in network byte order.
>>
>> What about other helpers such as bpf_skb_store_bytes() et al that
>> work on skbs. Do you intent to reuse them as is and thus populate
>> the per cpu skb with needed fields (faking linear data), or do you
>> see larger obstacles that prevent for this?
>
> Argh... maybe the minimal pseudo/fake SKB is the wrong "signal" to send
> to users of this API.
>
> The hole idea is that an SKB is NOT allocated yet, and not needed at
> this level. If we start supporting calling underlying SKB functions,
> then we will end-up in the same place (performance wise).
I'm talking about the current skb-related BPF helper functions we have,
so the question is how much from that code we have we can reuse under
these constraints (obviously things like the tunnel helpers are a different
story) and if that trade-off is acceptable for us. I'm also thinking
that, for example, if you need to parse the packet data anyway for a drop
verdict, you might as well pass some meta data (that is set in the real
skb later on) for those packets that go up the stack.
^ permalink raw reply
* Re: Best way to reduce system call overhead for tun device I/O?
From: ValdikSS @ 2016-04-04 13:35 UTC (permalink / raw)
To: Guus Sliepen
Cc: Stephen Hemminger, Willem de Bruijn, David Miller, Tom Herbert,
netdev
I'm trying to increase OpenVPN throughput by optimizing tun manipulations, too.
Right now I have more questions than answers.
I get about 800 Mbit/s speeds via OpenVPN with authentication and encryption disabled on a local machine with OpenVPN server and client running in a different
network namespaces, which use veth for networking, with 1500 MTU on a TUN interface. This is rather limiting. Low-end devices like SOHO routers could only
achieve 15-20 Mbit/s via OpenVPN with encryption with a 560 MHz CPU.
Increasing MTU reduces overhead. You can get > 5GBit/s if you set 16000 MTU on a TUN interface.
That's not only OpenVPN related. All the tunneling software I tried can't achieve gigabit speeds without encryption on my machine with MTU 1500. Didn't test
tinc though.
TUN supports various offloading techniques: GSO, TSO, UFO, just as hardware NICs. From what I understand, if we use GSO/GRO for TUN, we would be able to receive
send small packets combined in a huge one with one send/recv call with MTU 1500 on a TUN interface, and the performance should increase and be just as it now
with increased MTU. But there is a very little information of how to use offloading with TUN.
I've found an old example code which creates TUN interface with GSO support (TUN_VNET_HDR), does NAT and echoes TUN data to stdout, and a script to run two
instances of this software connected with a pipe. But it doesn't work for me, I never see any combined frames (gso_type is always 0 in a virtio_net_hdr header).
Probably I did something wrong, but I'm not sure what exactly is wrong.
Here's said application: http://ovrload.ru/f/68996_tun.tar.gz
The questions are as follows:
1. Do I understand correctly that GSO/GRO would have the same effect as increasing MTU on TUN interface?
2. How GRO/GSO is different from TSO, UFO?
3. Can we get and send combined frames directly from/to NIC with offloading support?
4. How to implement GRO/GSO, TSO, UFO? What should be the logic behind it?
Any reply is greatly appreciated.
P.S. this could be helpful: https://ldpreload.com/p/tuntap-notes.txt
> I'm trying to reduce system call overhead when reading/writing to/from a
> tun device in userspace. For sockets, one can use sendmmsg()/recvmmsg(),
> but a tun fd is not a socket fd, so this doesn't work. I'm see several
> options to allow userspace to read/write multiple packets with one
> syscall:
>
> - Implement a TX/RX ring buffer that is mmap()ed, like with AF_PACKET
> sockets.
>
> - Implement a ioctl() to emulate sendmmsg()/recvmmsg().
>
> - Add a flag that can be set using TUNSETIFF that makes regular
> read()/write() calls handle multiple packets in one go.
>
> - Expose a socket fd to userspace, so regular sendmmsg()/recvmmsg() can
> be used. There is tun_get_socket() which is used internally in the
> kernel, but this is not exposed to userspace, and doesn't look trivial
> to do either.
>
> What would be the right way to do this?
>
> --
> Met vriendelijke groet / with kind regards,
> Guus Sliepen <guus@tinc-vpn.org>
^ permalink raw reply
* Re: [PATCH v5 net-next] net: ipv4: Consider failed nexthops in multipath routes
From: David Ahern @ 2016-04-04 13:29 UTC (permalink / raw)
To: Julian Anastasov; +Cc: netdev
In-Reply-To: <alpine.LFD.2.11.1604040917390.2182@ja.home.ssi.bg>
On 4/4/16 12:29 AM, Julian Anastasov wrote:
> Reviewed-by: Julian Anastasov <ja@ssi.bg>
>
> With one comment: the fallback strategy is simplified,
> we do not fallback to all possible reachable nexthops.
>
Right. I will send a second patch that examines other nexthops (hash <=
nh_upper_bound).
^ permalink raw reply
* FWD: [PATCH v2] Marvell phy: add fiber status check for some components
From: Andrew Lunn @ 2016-04-04 13:25 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev, charles-antoine.couret
> >From 564b767163d19355a3b5efaad195e93796570c71 Mon Sep 17 00:00:00 2001
> From: Charles-Antoine Couret <charles-antoine.couret@nexvision.fr>
> Date: Fri, 1 Apr 2016 16:16:35 +0200
> Subject: [PATCH] Marvell phy: add fiber status check for some components
>
> Marvell's phy could have two modes: fiber and copper. Currently, the driver
> checks only the copper mode registers to get the status link which could be
> wrong.
>
> This commit add a handler to check fiber then copper status link.
> If the fiber link is activated, the driver would use this information.
> Else, it would use the copper status.
Hi Florian
What do you think about this?
This works for basic status information. But what about other ethtool
options? Setting the speed and duplex, turning pause on/off, etc.
Do we actually need to stay on page 1 if fibre is in use? How do we
initially change to page 1 when the fibre link is still down?
Should we be using the old mechanism to swap between TP, BNC and AUI
to swap between copper and fibre?
Andrew
>
> This patch is not tested with all Marvell's phy.
> The new function is actived only for tested phys.
>
> Signed-off-by: Charles-Antoine Couret <charles-antoine.couret@nexvision.fr>
> ---
> drivers/net/phy/marvell.c | 43 +++++++++++++++++++++++++++++++++++++++++--
> 1 file changed, 41 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
> index ab1d0fc..22552ab 100644
> --- a/drivers/net/phy/marvell.c
> +++ b/drivers/net/phy/marvell.c
> @@ -890,6 +890,45 @@ static int marvell_read_status(struct phy_device *phydev)
> return 0;
> }
>
> +/* marvell_read_fiber_status
> + *
> + * Some Marvell's phys have two modes: fiber and copper.
> + * Both need status checked.
> + * Description:
> + * First, check the fiber link and status.
> + * If the fiber link is down, check the copper link and status which
> + * will be the default value if both link are down.
> + */
> +static int marvell_read_fiber_status(struct phy_device *phydev)
> +{
> + int err;
> +
> + /* Check the fiber mode first */
> + err = phy_write(phydev, MII_MARVELL_PHY_PAGE, MII_M1111_FIBER);
> + if (err < 0)
> + goto error;
> +
> + err = marvell_read_status(phydev);
> + if (err < 0)
> + goto error;
> +
> + if (phydev->link) {
> + phy_write(phydev, MII_MARVELL_PHY_PAGE, MII_M1111_COPPER);
> + return 0;
> + }
> +
> + /* If fiber link is down, check and save copper mode state */
> + err = phy_write(phydev, MII_MARVELL_PHY_PAGE, MII_M1111_COPPER);
> + if (err < 0)
> + goto error;
> +
> + return marvell_read_status(phydev);
> +
> +error:
> + phy_write(phydev, MII_MARVELL_PHY_PAGE, MII_M1111_COPPER);
> + return err;
> +}
> +
> static int marvell_aneg_done(struct phy_device *phydev)
> {
> int retval = phy_read(phydev, MII_M1011_PHY_STATUS);
> @@ -1122,7 +1161,7 @@ static struct phy_driver marvell_drivers[] = {
> .probe = marvell_probe,
> .config_init = &m88e1111_config_init,
> .config_aneg = &marvell_config_aneg,
> - .read_status = &marvell_read_status,
> + .read_status = &marvell_read_fiber_status,
> .ack_interrupt = &marvell_ack_interrupt,
> .config_intr = &marvell_config_intr,
> .resume = &genphy_resume,
> @@ -1270,7 +1309,7 @@ static struct phy_driver marvell_drivers[] = {
> .probe = marvell_probe,
> .config_init = &marvell_config_init,
> .config_aneg = &m88e1510_config_aneg,
> - .read_status = &marvell_read_status,
> + .read_status = &marvell_read_fiber_status,
> .ack_interrupt = &marvell_ack_interrupt,
> .config_intr = &marvell_config_intr,
> .did_interrupt = &m88e1121_did_interrupt,
> --
> 2.5.5
>
>
>
> ----- End forwarded message -----
>
^ permalink raw reply
* Re: [PATCH v2] Marvell phy: add fiber status check for some components
From: Andrew Lunn @ 2016-04-04 13:14 UTC (permalink / raw)
To: Charles-Antoine Couret; +Cc: netdev
In-Reply-To: <570266F3.4000400@nexvision.fr>
On Mon, Apr 04, 2016 at 03:06:59PM +0200, Charles-Antoine Couret wrote:
> Hi,
> I took into account previous remark from Andrew to return in MII_M1111_COPPER page in all cases.
> I completed the description of patch.
Hi Charles
Please do not send patches as attachments.
Andrew
^ permalink raw reply
* Re: [RFC PATCH 1/5] bpf: add PHYS_DEV prog type for early driver filter
From: Jesper Dangaard Brouer @ 2016-04-04 13:07 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Brenden Blanco, davem, netdev, tom, alexei.starovoitov, gerlitz,
john.fastabend, brouer
In-Reply-To: <57022A85.6040002@iogearbox.net>
On Mon, 04 Apr 2016 10:49:09 +0200 Daniel Borkmann <daniel@iogearbox.net> wrote:
> On 04/02/2016 03:21 AM, Brenden Blanco wrote:
> > Add a new bpf prog type that is intended to run in early stages of the
> > packet rx path. Only minimal packet metadata will be available, hence a new
> > context type, struct xdp_metadata, is exposed to userspace. So far only
> > expose the readable packet length, and only in read mode.
> >
> > The PHYS_DEV name is chosen to represent that the program is meant only
> > for physical adapters, rather than all netdevs.
> >
> > While the user visible struct is new, the underlying context must be
> > implemented as a minimal skb in order for the packet load_* instructions
> > to work. The skb filled in by the driver must have skb->len, skb->head,
> > and skb->data set, and skb->data_len == 0.
> >
[...]
>
> Do you plan to support bpf_skb_load_bytes() as well? I like using
> this API especially when dealing with larger chunks (>4 bytes) to
> load into stack memory, plus content is kept in network byte order.
>
> What about other helpers such as bpf_skb_store_bytes() et al that
> work on skbs. Do you intent to reuse them as is and thus populate
> the per cpu skb with needed fields (faking linear data), or do you
> see larger obstacles that prevent for this?
Argh... maybe the minimal pseudo/fake SKB is the wrong "signal" to send
to users of this API.
The hole idea is that an SKB is NOT allocated yet, and not needed at
this level. If we start supporting calling underlying SKB functions,
then we will end-up in the same place (performance wise).
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* [PATCH v2] Marvell phy: add fiber status check for some components
From: Charles-Antoine Couret @ 2016-04-04 13:06 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev
In-Reply-To: <20160404122219.GD21828@lunn.ch>
[-- Attachment #1: Type: text/plain, Size: 188 bytes --]
Hi,
I took into account previous remark from Andrew to return in MII_M1111_COPPER page in all cases.
I completed the description of patch.
Thanks for all.
Regards,
Charles-Antoine Couret
[-- Attachment #2: marvell.patch --]
[-- Type: text/x-patch, Size: 3038 bytes --]
>From 564b767163d19355a3b5efaad195e93796570c71 Mon Sep 17 00:00:00 2001
From: Charles-Antoine Couret <charles-antoine.couret@nexvision.fr>
Date: Fri, 1 Apr 2016 16:16:35 +0200
Subject: [PATCH] Marvell phy: add fiber status check for some components
Marvell's phy could have two modes: fiber and copper. Currently, the driver
checks only the copper mode registers to get the status link which could be
wrong.
This commit add a handler to check fiber then copper status link.
If the fiber link is activated, the driver would use this information.
Else, it would use the copper status.
This patch is not tested with all Marvell's phy.
The new function is actived only for tested phys.
Signed-off-by: Charles-Antoine Couret <charles-antoine.couret@nexvision.fr>
---
drivers/net/phy/marvell.c | 43 +++++++++++++++++++++++++++++++++++++++++--
1 file changed, 41 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index ab1d0fc..22552ab 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -890,6 +890,45 @@ static int marvell_read_status(struct phy_device *phydev)
return 0;
}
+/* marvell_read_fiber_status
+ *
+ * Some Marvell's phys have two modes: fiber and copper.
+ * Both need status checked.
+ * Description:
+ * First, check the fiber link and status.
+ * If the fiber link is down, check the copper link and status which
+ * will be the default value if both link are down.
+ */
+static int marvell_read_fiber_status(struct phy_device *phydev)
+{
+ int err;
+
+ /* Check the fiber mode first */
+ err = phy_write(phydev, MII_MARVELL_PHY_PAGE, MII_M1111_FIBER);
+ if (err < 0)
+ goto error;
+
+ err = marvell_read_status(phydev);
+ if (err < 0)
+ goto error;
+
+ if (phydev->link) {
+ phy_write(phydev, MII_MARVELL_PHY_PAGE, MII_M1111_COPPER);
+ return 0;
+ }
+
+ /* If fiber link is down, check and save copper mode state */
+ err = phy_write(phydev, MII_MARVELL_PHY_PAGE, MII_M1111_COPPER);
+ if (err < 0)
+ goto error;
+
+ return marvell_read_status(phydev);
+
+error:
+ phy_write(phydev, MII_MARVELL_PHY_PAGE, MII_M1111_COPPER);
+ return err;
+}
+
static int marvell_aneg_done(struct phy_device *phydev)
{
int retval = phy_read(phydev, MII_M1011_PHY_STATUS);
@@ -1122,7 +1161,7 @@ static struct phy_driver marvell_drivers[] = {
.probe = marvell_probe,
.config_init = &m88e1111_config_init,
.config_aneg = &marvell_config_aneg,
- .read_status = &marvell_read_status,
+ .read_status = &marvell_read_fiber_status,
.ack_interrupt = &marvell_ack_interrupt,
.config_intr = &marvell_config_intr,
.resume = &genphy_resume,
@@ -1270,7 +1309,7 @@ static struct phy_driver marvell_drivers[] = {
.probe = marvell_probe,
.config_init = &marvell_config_init,
.config_aneg = &m88e1510_config_aneg,
- .read_status = &marvell_read_status,
+ .read_status = &marvell_read_fiber_status,
.ack_interrupt = &marvell_ack_interrupt,
.config_intr = &marvell_config_intr,
.did_interrupt = &m88e1121_did_interrupt,
--
2.5.5
^ permalink raw reply related
* Re: [PATCH] net: socket: return a proper error code when source address becomes nonlocal
From: Sergei Shtylyov @ 2016-04-04 12:55 UTC (permalink / raw)
To: Liping Zhang, davem; +Cc: netdev, Liping Zhang
In-Reply-To: <1459753769-4290-1-git-send-email-zlpnobody@163.com>
Hello.
On 4/4/2016 10:09 AM, Liping Zhang wrote:
> From: Liping Zhang <liping.zhang@spreadtrum.com>
>
> 1. Socket can use bind(directly) or connect(indirectly) to bind to a local
> ip address, and later if the network becomes down, that cause the source
> address becomes nonlocal, then send() call will fail and return EINVAL.
> But this error code is confusing, acctually we did not pass any invalid
> arguments. Furthermore, send() maybe return ok at first, it now returns
> fail just because of a temporary network problem, i.e. when the network
> recovery, send() call will become ok. Return EADDRNOTAVAIL instead of
> EINVAL in such situation is better.
> 2. We can use IPV6_PKTINFO to specify the ipv6 source address when call
> sendmsg() to send packet, but if the address is not available, call will
> fail and EINVAL is returned. This error code is not very appropriate,
> it failed maybe just because of a temporary network problem. Also
> RFC3542, section 6.6 describe an example returns EADDRNOTAVAIL:
> "ipi6_ifindex specifies an interface but the address ipi6_addr is not
> available for use on that interface.". So return EADDRNOTAVAIL instead
> of EINVAL here.
>
> Signed-off-by: Liping Zhang <liping.zhang@spreadtrum.com>
I think this should be 2 patches as you seem to fix 2 separate problems.
[...]
MBR, Sergei
^ permalink raw reply
* Re: [PATCH net-next] cxgb4/cxgb4vf: Deprecate module parameter dflt_msg_enable
From: Sergei Shtylyov @ 2016-04-04 12:43 UTC (permalink / raw)
To: Hariprasad Shenai, davem; +Cc: netdev, leedom, nirranjan
In-Reply-To: <1459745604-8093-1-git-send-email-hariprasad@chelsio.com>
Hello.
On 4/4/2016 7:53 AM, Hariprasad Shenai wrote:
> Message level can be set through ethtool, so deprecate module parameter
> which is used to set the same.
>
> Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
> ---
> drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 3 ++-
> drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c | 3 ++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
> index d1e3f0997d6b..acefa35b7250 100644
> --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
> +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
> @@ -168,7 +168,8 @@ MODULE_PARM_DESC(force_init, "Forcibly become Master PF and initialize adapter,"
> static int dflt_msg_enable = DFLT_MSG_ENABLE;
>
> module_param(dflt_msg_enable, int, 0644);
> -MODULE_PARM_DESC(dflt_msg_enable, "Chelsio T4 default message enable bitmap");
> +MODULE_PARM_DESC(dflt_msg_enable, "Chelsio T4 default message enable bitmap,"
Need space after the last comma...
> + "deprecated parameter");
>
> /*
> * The driver uses the best interrupt scheme available on a platform in the
> diff --git a/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c b/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c
> index 1cc8a7a69457..730fec73d5a6 100644
> --- a/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c
> +++ b/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c
> @@ -74,7 +74,8 @@ static int dflt_msg_enable = DFLT_MSG_ENABLE;
>
> module_param(dflt_msg_enable, int, 0644);
> MODULE_PARM_DESC(dflt_msg_enable,
> - "default adapter ethtool message level bitmap");
> + "default adapter ethtool message level bitmap, "
... like here.
> + "deprecated parameter");
>
> /*
> * The driver uses the best interrupt scheme available on a platform in the
MBR, Sergei
^ permalink raw reply
* Re: AP firmware for TI wl1251 wifi chip (wl1251-fw-ap.bin)
From: Pali Rohár @ 2016-04-04 12:39 UTC (permalink / raw)
To: Luciano Coelho, Felipe Balbi, kev, Shahar Levi, Kalle Valo,
Andrew F. Davis, Guy Mishol, Yaniv Machani, Arik Nemtsov,
Gery Kahn, Felipe Balbi, Luciano Coelho
Cc: David Woodhouse, Pavel Machek, Aaro Koskinen, Ben Hutchings,
David Gnedt, Ivaylo Dimitrov, Sebastian Reichel, Tony Lindgren,
Nishanth Menon, linux-wireless, netdev, linux-kernel
In-Reply-To: <201603200040.26045@pali>
On Sunday 20 March 2016 00:40:25 Pali Rohár wrote:
> Hi!
>
> In linux-firmware repository [1] is missing AP firmware for TI wl1251
> chip. There is only STA firmware wl1251-fw.bin which supports managed
> and ad-hoc modes.
>
> For other TI wilink chips there are <CHIP>-ap.bin firmware files
> (wl1271-fw-ap.bin and wl128x-fw-ap.bin) which support AP mode. But for
> wl1251 firmware file with guessed name "wl1251-fw-ap.bin" is missing.
>
> Do you have any idea what happened with AP firmware for ti wilink4
> wl1251 wifi chip? Or where can be found? Guys from TI, can you help?
>
> I see that STA firmware was added into linux-firmware tree in year 2013
> by this pull request [2].
>
> [1] - https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/ti-connectivity
>
> [2] - http://thread.gmane.org/gmane.linux.kernel/1566500/focus=1571382
>
Hi! Anybody has some idea about that AP firmware?
--
Pali Rohár
pali.rohar@gmail.com
^ permalink raw reply
* Re: davinci-mdio: failing to connect to PHY
From: Andrew Lunn @ 2016-04-04 12:31 UTC (permalink / raw)
To: Petr Kulhavy; +Cc: netdev
In-Reply-To: <57022356.6010309@barix.com>
On Mon, Apr 04, 2016 at 10:18:30AM +0200, Petr Kulhavy wrote:
> Hi,
>
> I'm experiencing a peculiar problem with PHY communication in the
> current davinci-mdio.c driver.
> After upgrading from kernel 3.17 to 4.5 my DT based AM1808 board
> started having issues with the PHY communication.
> The MAC is detected, the MDIO is detected, the PHY is detected
> (twice?!?!), however there is no data being sent/received and the
> after issuing "ifdown -a" the MDIO starts spitting out messages that
> it cannot connect to the PHY:
>
> net eth0: could not connect to phy davinci_mdio.0:00
> davinci_mdio davinci_mdio.0: resetting idled controller
>
>
> I'm using a single Micrel KSZ8081 PHY connected via RMII using the
> default PHY address 0x01.
> Here is the dmesg excerpt related to mdio:
>
> davinci_mdio davinci_mdio.0: Runtime PM disabled, clock forced on.
> davinci_mdio davinci_mdio.0: davinci mdio revision 1.5
> davinci_mdio davinci_mdio.0: detected phy mask fffffffc
> libphy: davinci_mdio.0: probed
> davinci_mdio davinci_mdio.0: phy[0]: device davinci_mdio.0:00,
> driver Micrel KSZ8081 or KSZ8091
> davinci_mdio davinci_mdio.0: phy[1]: device davinci_mdio.0:01,
> driver Micrel KSZ8081 or KSZ8091
> davinci_mdio davinci_mdio.0: resetting idled controller
> Micrel KSZ8081 or KSZ8091 davinci_mdio.0:00: failed to disable NAND
> tree mode
> Micrel KSZ8081 or KSZ8091 davinci_mdio.0:00: attached PHY driver
> [Micrel KSZ8081 or KSZ8091] (mii_bus:phy_addr=davinci_mdio.0:00,
> irq=-1)
>
>
> After a soft-reboot the MDIO uses a different PHY mask fffffffd,
> detects correctly only one PHY at address 1 (this is the default
> address) and the networking works:
Hi Petr
You might want to take a look at:
http://lxr.free-electrons.com/source/drivers/net/ethernet/ti/davinci_mdio.c#L137
It seems to be asking the hardware about the phy mask.
Andrew
^ permalink raw reply
* Re: [PATCH v2 10/15] wcn36xx: Copy all members in config_sta v1 conversion
From: Sergei Shtylyov @ 2016-04-04 12:25 UTC (permalink / raw)
To: Bjorn Andersson, Eugene Krasnikov, Kalle Valo
Cc: Pontus Fuchs, wcn36xx, linux-wireless, netdev, linux-kernel
In-Reply-To: <1459721806-11817-10-git-send-email-bjorn.andersson@linaro.org>
On 4/4/2016 1:16 AM, Bjorn Andersson wrote:
> From: Pontus Fuchs <pontus.fuchs@gmail.com>
>
> When converting to version 1 of the config_sta struct not all
> members where copied. This fixes the problem of multicast frames
Were.
> not being delivered on an encrypted network.
>
> Signed-off-by: Pontus Fuchs <pontus.fuchs@gmail.com>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[...]
MBR, Sergei
^ permalink raw reply
* Re: [PATCH v2 09/15] wcn36xx: Parse trigger_ba response properly
From: Sergei Shtylyov @ 2016-04-04 12:24 UTC (permalink / raw)
To: Bjorn Andersson, Eugene Krasnikov, Kalle Valo
Cc: Pontus Fuchs, wcn36xx, linux-wireless, netdev, linux-kernel
In-Reply-To: <1459721806-11817-9-git-send-email-bjorn.andersson@linaro.org>
Hello.
On 4/4/2016 1:16 AM, Bjorn Andersson wrote:
> From: Pontus Fuchs <pontus.fuchs@gmail.com>
>
> This message does not follow the canonical format and needs it's own
> parser.
>
> Signed-off-by: Pontus Fuchs <pontus.fuchs@gmail.com>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
> drivers/net/wireless/ath/wcn36xx/smd.c | 14 ++++++++++++--
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/wcn36xx/smd.c b/drivers/net/wireless/ath/wcn36xx/smd.c
> index 76c6856ed932..7f315d098f52 100644
> --- a/drivers/net/wireless/ath/wcn36xx/smd.c
> +++ b/drivers/net/wireless/ath/wcn36xx/smd.c
> @@ -1968,6 +1968,17 @@ out:
> return ret;
> }
>
> +static int wcn36xx_smd_trigger_ba_rsp(void *buf, int len)
> +{
> + struct wcn36xx_hal_trigger_ba_rsp_msg *rsp;
> +
> + if (len < sizeof(*rsp))
> + return -EINVAL;
> +
> + rsp = (struct wcn36xx_hal_trigger_ba_rsp_msg *) buf;
Casts from 'void *' to other pointer types are automatic, no need for the
explicit cast.
[...]
MBR, Sergei
^ permalink raw reply
* Re: [PATCH] Marvell phy: add fiber status check for some components
From: Andrew Lunn @ 2016-04-04 12:22 UTC (permalink / raw)
To: Charles-Antoine Couret; +Cc: netdev
In-Reply-To: <570229B6.4090805@nexvision.fr>
On Mon, Apr 04, 2016 at 10:45:42AM +0200, Charles-Antoine Couret wrote:
> Hi,
>
> > Shouldn't you return to page 0, i.e. MII_M1111_COPPER, under all
> > conditions?
>
> I return marvell_read_status() which returns 0 if it hasn't error during the process.
> In case of right conditions, my function returns 0 for COPPER part (and FIBER part too).
>
> It doesn't change the value returned and behavior.
Hi Charles
Please read my email again. I'm talking about the phy page, not the
function return value.
Andrew
^ permalink raw reply
* Re: [RFC PATCH 4/5] mlx4: add support for fast rx drop bpf program
From: Daniel Borkmann @ 2016-04-04 9:57 UTC (permalink / raw)
To: Johannes Berg, Brenden Blanco
Cc: davem, netdev, tom, alexei.starovoitov, ogerlitz, john.fastabend,
brouer
In-Reply-To: <1459755310.18188.13.camel@sipsolutions.net>
On 04/04/2016 09:35 AM, Johannes Berg wrote:
> On Sat, 2016-04-02 at 23:38 -0700, Brenden Blanco wrote:
>>
>> Having a common check makes sense. The tricky thing is that the type can
>> only be checked after taking the reference, and I wanted to keep the
>> scope of the prog brief in the case of errors. I would have to move the
>> bpf_prog_get logic into dev_change_bpf_fd and pass a bpf_prog * into the
>> ndo instead. Would that API look fine to you?
>
> I can't really comment, I wasn't planning on using the API right now :)
>
> However, what else is there that the driver could possibly do with the
> FD, other than getting the bpf_prog?
>
>> A possible extension of this is just to keep the bpf_prog * in the
>> netdev itself and expose a feature flag from the driver rather than
>> an ndo. But that would mean another 8 bytes in the netdev.
>
> That also misses the signal to the driver when the program is
> set/removed, so I don't think that works. I'd argue it's not really
> desirable anyway though since I wouldn't expect a majority of drivers
> to start supporting this.
I think ndo is probably fine for this purpose, see also my other mail. I
think currently, the only really driver specific code would be to store
the prog pointer somewhere and to pass needed meta data to populate the
fake skb.
Maybe mid-term drivers might want to reuse this hook/signal for offloading
as well, not yet sure ... how would that relate to offloading of cls_bpf?
Should these be considered two different things (although from an offloading
perspective they are not really). _Conceptually_, XDP could also be seen
as a software offload for the facilities we support with cls_bpf et al.
Thanks,
Daniel
^ permalink raw reply
* Re: [RFC PATCH 4/5] mlx4: add support for fast rx drop bpf program
From: Daniel Borkmann @ 2016-04-04 9:22 UTC (permalink / raw)
To: Brenden Blanco, davem
Cc: netdev, tom, alexei.starovoitov, gerlitz, john.fastabend, brouer
In-Reply-To: <1459560118-5582-5-git-send-email-bblanco@plumgrid.com>
On 04/02/2016 03:21 AM, Brenden Blanco wrote:
> Add support for the BPF_PROG_TYPE_PHYS_DEV hook in mlx4 driver. Since
> bpf programs require a skb context to navigate the packet, build a
> percpu fake skb with the minimal fields. This avoids the costly
> allocation for packets that end up being dropped.
>
> Since mlx4 is so far the only user of this pseudo skb, the build
> function is defined locally.
>
> Signed-off-by: Brenden Blanco <bblanco@plumgrid.com>
> ---
> drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 61 ++++++++++++++++++++++++++
> drivers/net/ethernet/mellanox/mlx4/en_rx.c | 18 ++++++++
> drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 2 +
> 3 files changed, 81 insertions(+)
>
[...]
>
> +static DEFINE_PER_CPU(struct sk_buff, percpu_pseudo_skb);
> +
> +static void build_pseudo_skb_for_bpf(struct sk_buff *skb, void *data,
> + unsigned int length)
> +{
> + /* data_len is intentionally not set here so that skb_is_nonlinear()
> + * returns false
> + */
> +
> + skb->len = length;
> + skb->head = data;
> + skb->data = data;
> +}
> +
> +int mlx4_call_bpf(struct bpf_prog *prog, void *data, unsigned int length)
> +{
> + struct sk_buff *skb = this_cpu_ptr(&percpu_pseudo_skb);
> + int ret;
> +
> + build_pseudo_skb_for_bpf(skb, data, length);
> +
> + rcu_read_lock();
> + ret = BPF_PROG_RUN(prog, (void *)skb);
> + rcu_read_unlock();
> +
> + return ret;
> +}
Couldn't this diff rather live in filter.c? Doesn't seem mlx4 specific. When
placed there, the api would also make the requirements clear for every driver
wanting to implement xdp wrt meta data that needs to be passed, and allows to
easier review code (as driver just call a few core helpers rather than needing
to re-implement the pseudo skb et al).
> +static int mlx4_bpf_set(struct net_device *dev, int fd)
> +{
> + struct mlx4_en_priv *priv = netdev_priv(dev);
> + struct bpf_prog *prog = NULL, *old_prog;
> +
> + if (fd >= 0) {
> + prog = bpf_prog_get(fd);
> + if (IS_ERR(prog))
> + return PTR_ERR(prog);
> +
> + if (prog->type != BPF_PROG_TYPE_PHYS_DEV) {
> + bpf_prog_put(prog);
> + return -EINVAL;
> + }
This block could just be a generic helper that mlx4_bpf_set() calls from here.
> + }
> +
> + old_prog = xchg(&priv->prog, prog);
> + if (old_prog) {
> + synchronize_net();
> + bpf_prog_put(old_prog);
> + }
> +
> + priv->dev->bpf_valid = !!prog;
Could the 'bpf_valid' addition to the net_device be avoided altogether?
The API could probably just be named .ndo_bpf() and depending how you invoke
it, either set/deletes the program or tell (return code) whether a program is
currently attached.
> + return 0;
> +}
> +
> static const struct net_device_ops mlx4_netdev_ops = {
> .ndo_open = mlx4_en_open,
> .ndo_stop = mlx4_en_close,
> @@ -2486,6 +2545,7 @@ static const struct net_device_ops mlx4_netdev_ops = {
> .ndo_features_check = mlx4_en_features_check,
> #endif
> .ndo_set_tx_maxrate = mlx4_en_set_tx_maxrate,
> + .ndo_bpf_set = mlx4_bpf_set,
> };
>
> static const struct net_device_ops mlx4_netdev_ops_master = {
> @@ -2524,6 +2584,7 @@ static const struct net_device_ops mlx4_netdev_ops_master = {
> .ndo_features_check = mlx4_en_features_check,
> #endif
> .ndo_set_tx_maxrate = mlx4_en_set_tx_maxrate,
> + .ndo_bpf_set = mlx4_bpf_set,
> };
>
> struct mlx4_en_bond {
> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
> index 86bcfe5..03fe005 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
> @@ -748,6 +748,7 @@ int mlx4_en_process_rx_cq(struct net_device *dev, struct mlx4_en_cq *cq, int bud
> struct mlx4_en_rx_ring *ring = priv->rx_ring[cq->ring];
> struct mlx4_en_rx_alloc *frags;
> struct mlx4_en_rx_desc *rx_desc;
> + struct bpf_prog *prog;
> struct sk_buff *skb;
> int index;
> int nr;
> @@ -764,6 +765,8 @@ int mlx4_en_process_rx_cq(struct net_device *dev, struct mlx4_en_cq *cq, int bud
> if (budget <= 0)
> return polled;
>
> + prog = READ_ONCE(priv->prog);
> +
> /* We assume a 1:1 mapping between CQEs and Rx descriptors, so Rx
> * descriptor offset can be deduced from the CQE index instead of
> * reading 'cqe->index' */
> @@ -840,6 +843,21 @@ int mlx4_en_process_rx_cq(struct net_device *dev, struct mlx4_en_cq *cq, int bud
> l2_tunnel = (dev->hw_enc_features & NETIF_F_RXCSUM) &&
> (cqe->vlan_my_qpn & cpu_to_be32(MLX4_CQE_L2_TUNNEL));
>
> + /* A bpf program gets first chance to drop the packet. It may
> + * read bytes but not past the end of the frag. A non-zero
> + * return indicates packet should be dropped.
> + */
> + if (prog) {
> + struct ethhdr *ethh;
> +
> + ethh = (struct ethhdr *)(page_address(frags[0].page) +
> + frags[0].page_offset);
> + if (mlx4_call_bpf(prog, ethh, length)) {
Since such program will be ABI, the return code might get some more additions in
future (e.g. forwarding, etc), so it needs to be thought through that we don't
burn ourselves later.
Maybe reuse tc opcodes, or define own ones?
We currently would have:
0 - Drop.
1 - Pass to stack.
rest - Reserved for future use.
> + priv->stats.rx_dropped++;
> + goto next;
> + }
> + }
> +
> if (likely(dev->features & NETIF_F_RXCSUM)) {
> if (cqe->status & cpu_to_be16(MLX4_CQE_STATUS_TCP |
> MLX4_CQE_STATUS_UDP)) {
> diff --git a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
> index d12ab6a..3d0fc89 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
> +++ b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
> @@ -568,6 +568,7 @@ struct mlx4_en_priv {
> struct hlist_head mac_hash[MLX4_EN_MAC_HASH_SIZE];
> struct hwtstamp_config hwtstamp_config;
> u32 counter_index;
> + struct bpf_prog *prog;
>
> #ifdef CONFIG_MLX4_EN_DCB
> struct ieee_ets ets;
> @@ -682,6 +683,7 @@ int mlx4_en_create_drop_qp(struct mlx4_en_priv *priv);
> void mlx4_en_destroy_drop_qp(struct mlx4_en_priv *priv);
> int mlx4_en_free_tx_buf(struct net_device *dev, struct mlx4_en_tx_ring *ring);
> void mlx4_en_rx_irq(struct mlx4_cq *mcq);
> +int mlx4_call_bpf(struct bpf_prog *prog, void *data, unsigned int length);
>
> int mlx4_SET_MCAST_FLTR(struct mlx4_dev *dev, u8 port, u64 mac, u64 clear, u8 mode);
> int mlx4_SET_VLAN_FLTR(struct mlx4_dev *dev, struct mlx4_en_priv *priv);
>
^ permalink raw reply
* [PATCH] net: mvneta: Remove superfluous SMP function call
From: Anna-Maria Gleixner @ 2016-04-04 9:20 UTC (permalink / raw)
To: linux-kernel; +Cc: rt, Anna-Maria Gleixner, Thomas Petazzoni, netdev
Since commit 1cf4f629d9d2 ("cpu/hotplug: Move online calls to
hotplugged cpu") it is ensured that callbacks of CPU_ONLINE and
CPU_DOWN_PREPARE are processed on the hotplugged cpu. Due to this SMP
function calls are no longer required.
Replace smp_call_function_single() with a direct call to
mvneta_percpu_enable() or mvneta_percpu_disable(). The functions do
not require to be called with interrupts disabled, therefore the
smp_call_function_single() calling convention is not preserved.
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: netdev@vger.kernel.org
Signed-off-by: Anna-Maria Gleixner <anna-maria@linutronix.de>
---
drivers/net/ethernet/marvell/mvneta.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -3354,8 +3354,7 @@ static int mvneta_percpu_notifier(struct
/* Enable per-CPU interrupts on the CPU that is
* brought up.
*/
- smp_call_function_single(cpu, mvneta_percpu_enable,
- pp, true);
+ mvneta_percpu_enable(pp);
/* Enable per-CPU interrupt on the one CPU we care
* about.
@@ -3387,8 +3386,7 @@ static int mvneta_percpu_notifier(struct
/* Disable per-CPU interrupts on the CPU that is
* brought down.
*/
- smp_call_function_single(cpu, mvneta_percpu_disable,
- pp, true);
+ mvneta_percpu_disable(pp);
break;
case CPU_DEAD:
^ permalink raw reply
* Re: Backport patch from 4.2 to 3.18
From: Andrei Sharaev @ 2016-04-04 9:05 UTC (permalink / raw)
To: David S. Miller; +Cc: Sasha Levin, stable, netdev@vger.kernel.org, LKML
In-Reply-To: <56E6EA59.5020302@oracle.com>
Hi David,
Could you help with this problem?
--
Best regards,
Andrei Sharaev
BYAS-RIPE
ISP Atlant Telecom
aosharaev@telecom.by
14.03.2016 19:44, Sasha Levin пишет:
> On 03/04/2016 04:26 PM, Sasha Levin wrote:
>> On 03/04/2016 03:40 PM, Andrei Sharaev wrote:
>>>> Hi Sasha,
>>>>
>>>> Can you backport this patch for "inet-frag-fixes" to linux kernel 3.18 LTS?
>>>> http://kernel.suse.com/cgit/kernel/commit/?h=v4.2-rc5&id=64b892ad2326348a5b8314167590d240e3bcc69e
>>>>
>>>> I get 1-5 kernel panics in month for linux kernels 3.18.24-3.18.26 at my NAT server with big IPv4 traffic (10-15 Gbps).
>>>> My kernel panics have similar symptoms:
>>>>>> <82>general protection fault: 0000 [#1] SMP
>>>>>> <82>Modules linked in: bonding ipt_NETFLOW(O) xt_recent configfs x86_pkg_temp_thermal ixgbe(O)
>>>>>> <86>CPU: 13 PID: 29908 Comm: kworker/13:2 Tainted: G IO 3.18.26 #1
>>>>>> <86>Hardware name: Intel Corporation S2600WT2/S2600WT2, BIOS SE5C610.86B.01.01.0005.101720141054 10/17/2014
>>>>>> <82>Workqueue: events inet_frag_worker
>>>>>> <86>task: ffff88046cdba9a0 ti: ffff880454928000 task.ti: ffff880454928000
>>>>>> <82>RIP: 0010:[<ffffffff815b91d9>] [<ffffffff815b91d9>] inet_evict_bucket+0x109/0x160
>>>>>> <86>RSP: 0018:ffff88045492bd38 EFLAGS: 00010286
>>>>>> <86>RAX: ffff880441d0e001 RBX: dead0000001000c0 RCX: 000000018030002e
>>>>>> <86>RDX: 000000018030002f RSI: ffff880441d0e000 RDI: dead0000001000c0
>>>>>> <86>RBP: ffff88045492bd88 R08: 0000000000000000 R09: ffff88086cc88500
>>>>>> <86>R10: ffff88046fdb5c50 R11: ffffea0011074380 R12: 0000000000000002
>>>>>> <86>R13: ffffffff81e02200 R14: 0000000000000000 R15: ffff88083f0942a0
>>>>>> <86>FS: 0000000000000000(0000) GS:ffff88046fda0000(0000) knlGS:0000000000000000
>>>>>> <86>CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>>>>> <86>CR2: 00007fab8f466000 CR3: 000000085f66d000 CR4: 00000000001407e0
>>>>>> <86>Stack:
>>>>>> <82> ffffffff81e05a78 ffffffff81e05a70 ffff88046cdba9a0 ffff88083f0942e0
>>>>>> <82> ffff88046f808c00 0000000000000079 ffffffff81e02200 ffffffff81e06200
>>>>>> <82> 0000000000000388 0000000000000007 ffff88045492bdf8 ffffffff815b928a
>>>>>> <86>Call Trace:
>>>>>> <82> [<ffffffff815b928a>] inet_frag_worker+0x5a/0x230
>>>>>> <82> [<ffffffff8105808d>] process_one_work+0x12d/0x330
>>>>>> <82> [<ffffffff8105892b>] worker_thread+0x4b/0x450
>>>>>> <82> [<ffffffff810588e0>] ? cancel_delayed_work_sync+0x10/0x10
>>>>>> <82> [<ffffffff8105cd34>] kthread+0xc4/0xe0
>>>>>> <82> [<ffffffff81060c59>] ? finish_task_switch+0x49/0xc0
>>>>>> <82> [<ffffffff8105cc70>] ? kthread_create_on_node+0x170/0x170
>>>>>> <82> [<ffffffff81603d88>] ret_from_fork+0x58/0x90
>>>>>> <82> [<ffffffff8105cc70>] ? kthread_create_on_node+0x170/0x170
>>>>>> <82>Code: f6 0f 85 73 ff ff ff 48 8b 45 b8 80 40 08 01 48 8b 7d c8 48 85 ff 74 23 48 83 ef 40 75 0d eb 1b 66 90 48 83 eb 40 48 89 df 74 10 <48> 8b 5f 40 41 ff 95 70 40 00 00 48 85 db 75 e7 48 83 c4 28 44
>>>>>> <22>RIP [<ffffffff815b91d9>] inet_evict_bucket+0x109/0x160
>>>>>> <82> RSP <ffff88045492bd38>
>> Hey Andrei,
>>
>> Thanks for the report.
>>
>> Usually David Miller (Cc'ed) handles backporting network commits. In this case, I see
>> that he has elected not to backport it into 4.1 or 3.18, so I don't want to do it without
>> getting an ack from him first.
>>
>> David, is it ok to backport these commits back to 3.18 (and probably 4.1)?
> Ping?
^ permalink raw reply
* Re: [RFC PATCH 1/5] bpf: add PHYS_DEV prog type for early driver filter
From: Daniel Borkmann @ 2016-04-04 8:49 UTC (permalink / raw)
To: Brenden Blanco, davem
Cc: netdev, tom, alexei.starovoitov, gerlitz, john.fastabend, brouer
In-Reply-To: <1459560118-5582-2-git-send-email-bblanco@plumgrid.com>
On 04/02/2016 03:21 AM, Brenden Blanco wrote:
> Add a new bpf prog type that is intended to run in early stages of the
> packet rx path. Only minimal packet metadata will be available, hence a new
> context type, struct xdp_metadata, is exposed to userspace. So far only
> expose the readable packet length, and only in read mode.
>
> The PHYS_DEV name is chosen to represent that the program is meant only
> for physical adapters, rather than all netdevs.
>
> While the user visible struct is new, the underlying context must be
> implemented as a minimal skb in order for the packet load_* instructions
> to work. The skb filled in by the driver must have skb->len, skb->head,
> and skb->data set, and skb->data_len == 0.
>
> Signed-off-by: Brenden Blanco <bblanco@plumgrid.com>
> ---
> include/uapi/linux/bpf.h | 5 ++++
> kernel/bpf/verifier.c | 1 +
> net/core/filter.c | 68 ++++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 74 insertions(+)
>
> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index 924f537..b8a4ef2 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
> @@ -92,6 +92,7 @@ enum bpf_prog_type {
> BPF_PROG_TYPE_KPROBE,
> BPF_PROG_TYPE_SCHED_CLS,
> BPF_PROG_TYPE_SCHED_ACT,
> + BPF_PROG_TYPE_PHYS_DEV,
> };
>
> #define BPF_PSEUDO_MAP_FD 1
> @@ -367,6 +368,10 @@ struct __sk_buff {
> __u32 tc_classid;
> };
>
> +struct xdp_metadata {
> + __u32 len;
> +};
Should this consistently be called 'xdp' or rather 'phys dev',
because currently it's a mixture of both everywhere?
> struct bpf_tunnel_key {
> __u32 tunnel_id;
> union {
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 2e08f8e..804ca70 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -1340,6 +1340,7 @@ static bool may_access_skb(enum bpf_prog_type type)
> case BPF_PROG_TYPE_SOCKET_FILTER:
> case BPF_PROG_TYPE_SCHED_CLS:
> case BPF_PROG_TYPE_SCHED_ACT:
> + case BPF_PROG_TYPE_PHYS_DEV:
> return true;
> default:
> return false;
> diff --git a/net/core/filter.c b/net/core/filter.c
> index b7177d0..c417db6 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -2018,6 +2018,12 @@ tc_cls_act_func_proto(enum bpf_func_id func_id)
> }
> }
>
> +static const struct bpf_func_proto *
> +phys_dev_func_proto(enum bpf_func_id func_id)
> +{
> + return sk_filter_func_proto(func_id);
Do you plan to support bpf_skb_load_bytes() as well? I like using
this API especially when dealing with larger chunks (>4 bytes) to
load into stack memory, plus content is kept in network byte order.
What about other helpers such as bpf_skb_store_bytes() et al that
work on skbs. Do you intent to reuse them as is and thus populate
the per cpu skb with needed fields (faking linear data), or do you
see larger obstacles that prevent for this?
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH] Marvell phy: add fiber status check for some components
From: Charles-Antoine Couret @ 2016-04-04 8:45 UTC (permalink / raw)
To: netdev
In-Reply-To: <20160401170838.GA21633@lunn.ch>
Hi,
> Shouldn't you return to page 0, i.e. MII_M1111_COPPER, under all
> conditions?
I return marvell_read_status() which returns 0 if it hasn't error during the process.
In case of right conditions, my function returns 0 for COPPER part (and FIBER part too).
It doesn't change the value returned and behavior.
Charles-Antoine
^ permalink raw reply
* Re: [RFC PATCH 4/5] mlx4: add support for fast rx drop bpf program
From: Jesper Dangaard Brouer @ 2016-04-04 8:33 UTC (permalink / raw)
To: Brenden Blanco
Cc: davem, netdev, tom, alexei.starovoitov, Or Gerlitz, daniel,
john.fastabend, brouer
In-Reply-To: <1459560118-5582-5-git-send-email-bblanco@plumgrid.com>
On Fri, 1 Apr 2016 18:21:57 -0700
Brenden Blanco <bblanco@plumgrid.com> wrote:
> @@ -840,6 +843,21 @@ int mlx4_en_process_rx_cq(struct net_device *dev, struct mlx4_en_cq *cq, int bud
> l2_tunnel = (dev->hw_enc_features & NETIF_F_RXCSUM) &&
> (cqe->vlan_my_qpn & cpu_to_be32(MLX4_CQE_L2_TUNNEL));
>
> + /* A bpf program gets first chance to drop the packet. It may
> + * read bytes but not past the end of the frag. A non-zero
> + * return indicates packet should be dropped.
> + */
> + if (prog) {
> + struct ethhdr *ethh;
> +
> + ethh = (struct ethhdr *)(page_address(frags[0].page) +
> + frags[0].page_offset);
> + if (mlx4_call_bpf(prog, ethh, length)) {
> + priv->stats.rx_dropped++;
> + goto next;
> + }
> + }
> +
For future API, I can imagine more return codes being needed.
For forwarding I could imagine returning "STOLEN", which should not
increment rx_dropped.
One could also imagine supporting tcpdump/af_packet like facilities at
this packet-page level (e.g. af_packet queue packets into a RX ring
buffer, later processed/read async). It could return "SHARED", bumping
refcnt on page, and indicate page is now read-only. Thus, affecting
drivers processing flow.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* davinci-mdio: failing to connect to PHY
From: Petr Kulhavy @ 2016-04-04 8:18 UTC (permalink / raw)
To: netdev
Hi,
I'm experiencing a peculiar problem with PHY communication in the
current davinci-mdio.c driver.
After upgrading from kernel 3.17 to 4.5 my DT based AM1808 board started
having issues with the PHY communication.
The MAC is detected, the MDIO is detected, the PHY is detected
(twice?!?!), however there is no data being sent/received and the after
issuing "ifdown -a" the MDIO starts spitting out messages that it cannot
connect to the PHY:
net eth0: could not connect to phy davinci_mdio.0:00
davinci_mdio davinci_mdio.0: resetting idled controller
I'm using a single Micrel KSZ8081 PHY connected via RMII using the
default PHY address 0x01.
Here is the dmesg excerpt related to mdio:
davinci_mdio davinci_mdio.0: Runtime PM disabled, clock forced on.
davinci_mdio davinci_mdio.0: davinci mdio revision 1.5
davinci_mdio davinci_mdio.0: detected phy mask fffffffc
libphy: davinci_mdio.0: probed
davinci_mdio davinci_mdio.0: phy[0]: device davinci_mdio.0:00, driver
Micrel KSZ8081 or KSZ8091
davinci_mdio davinci_mdio.0: phy[1]: device davinci_mdio.0:01, driver
Micrel KSZ8081 or KSZ8091
davinci_mdio davinci_mdio.0: resetting idled controller
Micrel KSZ8081 or KSZ8091 davinci_mdio.0:00: failed to disable NAND tree
mode
Micrel KSZ8081 or KSZ8091 davinci_mdio.0:00: attached PHY driver [Micrel
KSZ8081 or KSZ8091] (mii_bus:phy_addr=davinci_mdio.0:00, irq=-1)
After a soft-reboot the MDIO uses a different PHY mask fffffffd, detects
correctly only one PHY at address 1 (this is the default address) and
the networking works:
davinci_mdio davinci_mdio.0: Runtime PM disabled, clock forced on.
davinci_mdio davinci_mdio.0: davinci mdio revision 1.5
davinci_mdio davinci_mdio.0: detected phy mask fffffffd
libphy: davinci_mdio.0: probed
davinci_mdio davinci_mdio.0: phy[1]: device davinci_mdio.0:01, driver
Micrel KSZ8081 or KSZ8091
davinci_mdio davinci_mdio.0: resetting idled controller
Micrel KSZ8081 or KSZ8091 davinci_mdio.0:01: attached PHY driver [Micrel
KSZ8081 or KSZ8091] (mii_bus:phy_addr=davinci_mdio.0:01, irq=-1)
I'm wondering what the problem is and why the PHY mask is different
after power-up and after a soft reboot.
Also it's not clear to me why this set-up worked with kernel 3.17 even
if it was detecting the PHY twice exactly the same way.
How does the mask relate to the PHY address and how is it calculated?
Thanks
Petr
^ 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