* [PATCH v5 04/17] net: qualcomm: use net_device_ops instead of direct call
From: Stefan Wahren @ 2017-05-10 8:53 UTC (permalink / raw)
To: Rob Herring, David S. Miller
Cc: Mark Rutland, Greg Kroah-Hartman, Jiri Slaby,
linux-serial-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
Stefan Wahren
In-Reply-To: <1494406408-31760-1-git-send-email-stefan.wahren-eS4NqCHxEME@public.gmane.org>
There is no need to export qcaspi_netdev_open and qcaspi_netdev_close
because they are also accessible via the net_device_ops.
Signed-off-by: Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org>
---
drivers/net/ethernet/qualcomm/qca_debug.c | 5 +++--
drivers/net/ethernet/qualcomm/qca_spi.c | 4 ++--
drivers/net/ethernet/qualcomm/qca_spi.h | 3 ---
3 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/qualcomm/qca_debug.c b/drivers/net/ethernet/qualcomm/qca_debug.c
index d145df9..92b6be9 100644
--- a/drivers/net/ethernet/qualcomm/qca_debug.c
+++ b/drivers/net/ethernet/qualcomm/qca_debug.c
@@ -275,6 +275,7 @@ qcaspi_get_ringparam(struct net_device *dev, struct ethtool_ringparam *ring)
static int
qcaspi_set_ringparam(struct net_device *dev, struct ethtool_ringparam *ring)
{
+ const struct net_device_ops *ops = dev->netdev_ops;
struct qcaspi *qca = netdev_priv(dev);
if ((ring->rx_pending) ||
@@ -283,13 +284,13 @@ qcaspi_set_ringparam(struct net_device *dev, struct ethtool_ringparam *ring)
return -EINVAL;
if (netif_running(dev))
- qcaspi_netdev_close(dev);
+ ops->ndo_stop(dev);
qca->txr.count = max_t(u32, ring->tx_pending, TX_RING_MIN_LEN);
qca->txr.count = min_t(u16, qca->txr.count, TX_RING_MAX_LEN);
if (netif_running(dev))
- qcaspi_netdev_open(dev);
+ ops->ndo_open(dev);
return 0;
}
diff --git a/drivers/net/ethernet/qualcomm/qca_spi.c b/drivers/net/ethernet/qualcomm/qca_spi.c
index 8590109..5c79612 100644
--- a/drivers/net/ethernet/qualcomm/qca_spi.c
+++ b/drivers/net/ethernet/qualcomm/qca_spi.c
@@ -602,7 +602,7 @@ qcaspi_intr_handler(int irq, void *data)
return IRQ_HANDLED;
}
-int
+static int
qcaspi_netdev_open(struct net_device *dev)
{
struct qcaspi *qca = netdev_priv(dev);
@@ -639,7 +639,7 @@ qcaspi_netdev_open(struct net_device *dev)
return 0;
}
-int
+static int
qcaspi_netdev_close(struct net_device *dev)
{
struct qcaspi *qca = netdev_priv(dev);
diff --git a/drivers/net/ethernet/qualcomm/qca_spi.h b/drivers/net/ethernet/qualcomm/qca_spi.h
index 6e31a0e..064853d 100644
--- a/drivers/net/ethernet/qualcomm/qca_spi.h
+++ b/drivers/net/ethernet/qualcomm/qca_spi.h
@@ -108,7 +108,4 @@ struct qcaspi {
u16 burst_len;
};
-int qcaspi_netdev_open(struct net_device *dev);
-int qcaspi_netdev_close(struct net_device *dev);
-
#endif /* _QCA_SPI_H */
--
2.1.4
--
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 related
* [PATCH v5 03/17] net: qca_7k: Use BIT macro
From: Stefan Wahren @ 2017-05-10 8:53 UTC (permalink / raw)
To: Rob Herring, David S. Miller
Cc: Mark Rutland, Greg Kroah-Hartman, Jiri Slaby, linux-serial,
linux-kernel, netdev, devicetree, Stefan Wahren
In-Reply-To: <1494406408-31760-1-git-send-email-stefan.wahren@i2se.com>
Use the BIT macro for the CONFIG and INT register values.
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
---
drivers/net/ethernet/qualcomm/qca_7k.h | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/qualcomm/qca_7k.h b/drivers/net/ethernet/qualcomm/qca_7k.h
index 1cad851..4047f0a 100644
--- a/drivers/net/ethernet/qualcomm/qca_7k.h
+++ b/drivers/net/ethernet/qualcomm/qca_7k.h
@@ -54,15 +54,15 @@
#define SPI_REG_ACTION_CTRL 0x1B00
/* SPI_CONFIG register definition; */
-#define QCASPI_SLAVE_RESET_BIT (1 << 6)
+#define QCASPI_SLAVE_RESET_BIT BIT(6)
/* INTR_CAUSE/ENABLE register definition. */
-#define SPI_INT_WRBUF_BELOW_WM (1 << 10)
-#define SPI_INT_CPU_ON (1 << 6)
-#define SPI_INT_ADDR_ERR (1 << 3)
-#define SPI_INT_WRBUF_ERR (1 << 2)
-#define SPI_INT_RDBUF_ERR (1 << 1)
-#define SPI_INT_PKT_AVLBL (1 << 0)
+#define SPI_INT_WRBUF_BELOW_WM BIT(10)
+#define SPI_INT_CPU_ON BIT(6)
+#define SPI_INT_ADDR_ERR BIT(3)
+#define SPI_INT_WRBUF_ERR BIT(2)
+#define SPI_INT_RDBUF_ERR BIT(1)
+#define SPI_INT_PKT_AVLBL BIT(0)
void qcaspi_spi_error(struct qcaspi *qca);
int qcaspi_read_register(struct qcaspi *qca, u16 reg, u16 *result);
--
2.1.4
^ permalink raw reply related
* [PATCH v5 02/17] net: qca_framing: use u16 for frame offset
From: Stefan Wahren @ 2017-05-10 8:53 UTC (permalink / raw)
To: Rob Herring, David S. Miller
Cc: Mark Rutland, Greg Kroah-Hartman, Jiri Slaby, linux-serial,
linux-kernel, netdev, devicetree, Stefan Wahren
In-Reply-To: <1494406408-31760-1-git-send-email-stefan.wahren@i2se.com>
It doesn't make sense to use a signed variable for offset here, so
fix it up.
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
---
drivers/net/ethernet/qualcomm/qca_framing.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/qualcomm/qca_framing.h b/drivers/net/ethernet/qualcomm/qca_framing.h
index d5e795d..8b385e6 100644
--- a/drivers/net/ethernet/qualcomm/qca_framing.h
+++ b/drivers/net/ethernet/qualcomm/qca_framing.h
@@ -103,7 +103,7 @@ struct qcafrm_handle {
enum qcafrm_state state;
/* Offset in buffer (borrowed for length too) */
- s16 offset;
+ u16 offset;
/* Frame length as kept by this module */
u16 len;
--
2.1.4
^ permalink raw reply related
* [PATCH v5 01/17] net: qualcomm: remove unnecessary includes
From: Stefan Wahren @ 2017-05-10 8:53 UTC (permalink / raw)
To: Rob Herring, David S. Miller
Cc: Mark Rutland, Greg Kroah-Hartman, Jiri Slaby, linux-serial,
linux-kernel, netdev, devicetree, Stefan Wahren
In-Reply-To: <1494406408-31760-1-git-send-email-stefan.wahren@i2se.com>
Most of the includes in qca_7k.c are unnecessary so we better remove them.
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
---
drivers/net/ethernet/qualcomm/qca_7k.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/net/ethernet/qualcomm/qca_7k.c b/drivers/net/ethernet/qualcomm/qca_7k.c
index f0066fb..557d53c 100644
--- a/drivers/net/ethernet/qualcomm/qca_7k.c
+++ b/drivers/net/ethernet/qualcomm/qca_7k.c
@@ -23,11 +23,7 @@
* kernel-based SPI device.
*/
-#include <linux/init.h>
-#include <linux/module.h>
-#include <linux/moduleparam.h>
#include <linux/spi/spi.h>
-#include <linux/version.h>
#include "qca_7k.h"
--
2.1.4
^ permalink raw reply related
* [PATCH v5 00/17] net: qualcomm: add QCA7000 UART driver
From: Stefan Wahren @ 2017-05-10 8:53 UTC (permalink / raw)
To: Rob Herring, David S. Miller
Cc: Mark Rutland, Greg Kroah-Hartman, Jiri Slaby, linux-serial,
linux-kernel, netdev, devicetree, Stefan Wahren
The Qualcomm QCA7000 HomePlug GreenPHY supports two interfaces:
UART and SPI. This patch series adds the missing support for UART.
This driver based on the Qualcomm code [1], but contains some changes:
* use random MAC address per default
* use net_device_stats from device
* share frame decoding between SPI and UART driver
* improve error handling
* reimplement tty_wakeup with work queue (based on slcan)
* use new serial device bus instead of ldisc
The patches 1 - 3 are just for clean up and are not related to
the UART support. Patches 4 - 15 prepare the existing QCA7000
code for UART support. Patch 16 is a improvement for serial device
bus. Patch 17 contains the new driver.
Cherry picking of the dt-bindings and serdev patch is okay. The
UART driver functionally (not compile) depends on this unmerged
patch [2].
The code itself has been tested on a Freescale i.MX28 board and
a Raspberry Pi Zero.
Changes in v5:
* rebase to current linux-next
* fix alignment issues in rx path
* fix buffer overrun with big ethernet frames
* fix init of UART decoding fsm
* add device UART settings to Kconfig help
* add current-speed to slave-device binding
* merge SPI and UART binding document
* rename qca_common to qca_7k_common
* drop patch for retrieving UART settings
* several cleanups
Changes in v4:
* rebase to current linux-next
* use parameter -M for git format-patch
* change order of local variables where possible
* implement basic serdev support (without hardware flow control)
Changes in v3:
* rebase to current net-next
Changes in v2:
* fix build issue by using netif_trans_update() and dev_trans_start()
[1] - https://github.com/IoE/qca7000
[2] - http://marc.info/?l=linux-serial&m=149338017301309&w=2
Stefan Wahren (17):
net: qualcomm: remove unnecessary includes
net: qca_framing: use u16 for frame offset
net: qca_7k: Use BIT macro
net: qualcomm: use net_device_ops instead of direct call
net: qualcomm: Improve readability of length defines
net: qca_spi: remove QCASPI_MTU
net: qualcomm: move qcaspi_tx_cmd to qca_spi.c
net: qca_spi: Clarify MODULE_DESCRIPTION
net: qualcomm: rename qca_framing.c to qca_7k_common.c
net: qualcomm: prepare frame decoding for UART driver
net: qualcomm: make qca_7k_common a separate kernel module
dt-bindings: qca7000-spi: Rework binding
dt-bindings: qca7000: rename binding
dt-bindings: slave-device: add current-speed property
dt-bindings: qca7000: append UART interface to binding
tty: serdev-ttyport: return actual baudrate from ttyport_set_baudrate
net: qualcomm: add QCA7000 UART driver
.../devicetree/bindings/net/qca-qca7000-spi.txt | 47 ---
.../devicetree/bindings/net/qca-qca7000.txt | 88 +++++
.../devicetree/bindings/serial/slave-device.txt | 9 +
drivers/net/ethernet/qualcomm/Kconfig | 24 +-
drivers/net/ethernet/qualcomm/Makefile | 7 +-
drivers/net/ethernet/qualcomm/qca_7k.c | 28 --
drivers/net/ethernet/qualcomm/qca_7k.h | 15 +-
.../qualcomm/{qca_framing.c => qca_7k_common.c} | 26 +-
.../qualcomm/{qca_framing.h => qca_7k_common.h} | 24 +-
drivers/net/ethernet/qualcomm/qca_debug.c | 5 +-
drivers/net/ethernet/qualcomm/qca_spi.c | 47 ++-
drivers/net/ethernet/qualcomm/qca_spi.h | 5 +-
drivers/net/ethernet/qualcomm/qca_uart.c | 423 +++++++++++++++++++++
drivers/tty/serdev/serdev-ttyport.c | 2 +-
14 files changed, 630 insertions(+), 120 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/net/qca-qca7000-spi.txt
create mode 100644 Documentation/devicetree/bindings/net/qca-qca7000.txt
rename drivers/net/ethernet/qualcomm/{qca_framing.c => qca_7k_common.c} (85%)
rename drivers/net/ethernet/qualcomm/{qca_framing.h => qca_7k_common.h} (86%)
create mode 100644 drivers/net/ethernet/qualcomm/qca_uart.c
--
2.1.4
^ permalink raw reply
* RE: [PATCH 1/4] hamradio: Combine two seq_printf() calls into one in yam_seq_show()
From: David Laight @ 2017-05-10 8:48 UTC (permalink / raw)
To: 'SF Markus Elfring', linux-hams@vger.kernel.org,
netdev@vger.kernel.org, David S. Miller, Javier Martinez Canillas,
Jean-Paul Roubelat
Cc: LKML, kernel-janitors@vger.kernel.org
In-Reply-To: <c2866b46-28c9-f17f-dce7-96425a17a43a@users.sourceforge.net>
From: SF Markus Elfring
> Sent: 09 May 2017 15:22
> A bit of data was put into a sequence by two separate function calls.
> Print the same data by a single function call instead.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
> drivers/net/hamradio/yam.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/net/hamradio/yam.c b/drivers/net/hamradio/yam.c
> index b6891ada1d7b..542f1e511df1 100644
> --- a/drivers/net/hamradio/yam.c
> +++ b/drivers/net/hamradio/yam.c
> @@ -830,8 +830,7 @@ static int yam_seq_show(struct seq_file *seq, void *v)
> seq_printf(seq, " RxFrames %lu\n", dev->stats.rx_packets);
> seq_printf(seq, " TxInt %u\n", yp->nb_mdint);
> seq_printf(seq, " RxInt %u\n", yp->nb_rxint);
> - seq_printf(seq, " RxOver %lu\n", dev->stats.rx_fifo_errors);
> - seq_printf(seq, "\n");
> + seq_printf(seq, " RxOver %lu\n\n", dev->stats.rx_fifo_errors);
> return 0;
The code was consistently (and probably deliberately) using one seq_printf()
call for each line so that the source looks 'a bit like' the output.
These changes are all stupid.
David
^ permalink raw reply
* Re: [Patch net] ipv4: restore rt->fi for reference counting
From: Julian Anastasov @ 2017-05-10 7:38 UTC (permalink / raw)
To: Cong Wang
Cc: Eric Dumazet, David Miller, Linux Kernel Network Developers,
Andrey Konovalov, Eric Dumazet
In-Reply-To: <CAM_iQpU+fXO7eFroAYMv6vqDzCK_ZYXjrTPAMfoDR2BDqaK9rQ@mail.gmail.com>
Hello,
On Tue, 9 May 2017, Cong Wang wrote:
> > Also setting nexthop_nh->nh_dev to NULL looks quite dangerous
> >
> > We have plenty of sites doing :
> >
> > if (fi->fib_dev)
> > x = fi->fib_dev->field
> >
> > fib_route_seq_show() is one example.
> >
>
> All of them take RCU read lock, so, as I explained in the code comment,
> they all should be fine because of synchronize_net() on unregister path.
> Do you see anything otherwise?
During NETDEV_UNREGISTER packets for dev should not
be flying but packets for other devs can walk the nexthops
for multipath routes. It is the rcu_barrier before
NETDEV_UNREGISTER_FINAL that allows nh_dev to be set to NULL
during this grace period but there are many places to fix that
assume nh_dev!=NULL.
But why we leak routes? Is there some place that holds
routes without listening for NETDEV_UNREGISTER? On fib_flush
the infos are unlinked from trees, so after a grace period packets
should not see/hold such infos. If we hold routes somewhere for
long time, problem can happen also for routes with single nexthop.
Regards
^ permalink raw reply
* Re: [PATCH iproute2 v2 1/1] vxlan: Add support for modifying vxlan device attributes
From: Girish Moodalbail @ 2017-05-10 7:31 UTC (permalink / raw)
To: Roman Mashak; +Cc: stephen, netdev
In-Reply-To: <85shkgd92a.fsf@mojatatu.com>
On 5/7/17 7:40 AM, Roman Mashak wrote:
> Girish Moodalbail <girish.moodalbail@oracle.com> writes:
>
>
> [...]
>
>> ip/iplink_vxlan.c | 251 +++++++++++++++++++++++++++++++-----------------------
>> 1 file changed, 143 insertions(+), 108 deletions(-)
>>
>> diff --git a/ip/iplink_vxlan.c b/ip/iplink_vxlan.c
>> index b4ebb13..2bd619d 100644
>> --- a/ip/iplink_vxlan.c
>> +++ b/ip/iplink_vxlan.c
>> @@ -21,6 +21,8 @@
>> #include "utils.h"
>> #include "ip_common.h"
>>
>> +#define VXLAN_ATTRSET(attrs, type) (((attrs) & (1L << (type))) != 0)
>
> I think you can drop '!= 0' part in the macro.
Sure it can be done that way as well. However, I have seen both forms in use in
iproute2 code base, so I would like to keep this as is unless you feel strongly
about it. Furthermore, running 'checkpatch.pl --strict' on the patch didn't
complain too.
regards,
~Girish
>
> [...]
>
>>
>> +static void check_duparg(__u64 *attrs, int type, const char *key,
>> + const char *argv)
>> +{
>> + if (!VXLAN_ATTRSET(*attrs, type)) {
>> + *attrs |= (1L << type);
>> + return;
>> + }
>> + duparg2(key, argv);
>> +}
>
> [...]
>
^ permalink raw reply
* Re: [PATCH] wcn36xx: Close SMD channel on device removal
From: Arend van Spriel @ 2017-05-10 7:27 UTC (permalink / raw)
To: Bjorn Andersson, Kalle Valo
Cc: Eugene Krasnikov, Eyal Ilsar, wcn36xx, linux-wireless, netdev,
linux-kernel, linux-arm-msm
In-Reply-To: <20170509230312.GR15143@minitux>
On 5/10/2017 1:03 AM, Bjorn Andersson wrote:
> On Mon 08 May 23:17 PDT 2017, Kalle Valo wrote:
>
>> Bjorn Andersson <bjorn.andersson@linaro.org> writes:
>>
>>> The SMD channel is not the primary WCNSS channel and must explicitly be
>>> closed as the device is removed, or the channel will already by open on
>>> a subsequent probe call in e.g. the case of reloading the kernel module.
>>>
>>> This issue was introduced because I simplified the underlying SMD
>>> implementation while the SMD adaptions of the driver sat on the mailing
>>> list, but missed to update these patches. The patch does however only
>>> apply back to the transition to rpmsg, hence the limited Fixes.
>>>
>>> Fixes: 5052de8deff5 ("soc: qcom: smd: Transition client drivers from smd to rpmsg")
>>> Reported-by: Eyal Ilsar <c_eilsar@qti.qualcomm.com>
>>> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
>>
>> As this is a regression I'll queue this to 4.12.
>>
>
> Thanks.
>
>> But if this is an older bug (didn't quite understand your description
>> though) should there be a separate patch for stable releases?
>>
>
> AFAICT this never worked, as it seems I did the rework in SMD while we
> tried to figure out the dependency issues we had with moving to SMD. So
> v4.9 through v4.11 has SMD support - with this bug.
>
> How do I proceed, do you want me to write up a fix for stable@? Do I
> send that out as an ordinary patch?
If the patch applies cleanly on branches linux-4.9.y through
linux-4.11.y in the stable repository you can go for '--- Option 1 ---'
as described in <linux-repo>/Documentation/stable_kernel_rules.txt.
Regards,
Arend
^ permalink raw reply
* [PATCH] net/smc: mark as BROKEN due to remote memory exposure
From: Christoph Hellwig @ 2017-05-10 7:26 UTC (permalink / raw)
To: davem; +Cc: ubraun, netdev, linux-rdma, stable
The driver has a lot of quality issues due to the lack of RDMA-side
review, and explicitly bypasses APIs to register all memory once a
connection is made, and thus allows remote access to memoery.
Mark it as broken until at least that part is fixed.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Cc: stable@vger.kernel.org
---
net/smc/Kconfig | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/net/smc/Kconfig b/net/smc/Kconfig
index c717ef0896aa..fe6b78bc515f 100644
--- a/net/smc/Kconfig
+++ b/net/smc/Kconfig
@@ -1,6 +1,6 @@
config SMC
tristate "SMC socket protocol family"
- depends on INET && INFINIBAND
+ depends on INET && INFINIBAND && BROKEN
---help---
SMC-R provides a "sockets over RDMA" solution making use of
RDMA over Converged Ethernet (RoCE) technology to upgrade
@@ -8,6 +8,10 @@ config SMC
The Linux implementation of the SMC-R solution is designed as
a separate socket family SMC.
+ Warning: SMC will expose all memory for remote reads and writes
+ once a connection is established. Don't enable this option except
+ for tightly controlled lab environment.
+
Select this option if you want to run SMC socket applications
config SMC_DIAG
--
2.11.0
^ permalink raw reply related
* (unknown),
From: kelley @ 2017-05-10 7:23 UTC (permalink / raw)
To: netdev
[-- Attachment #1: 620_netdev.zip --]
[-- Type: application/zip, Size: 1923 bytes --]
^ permalink raw reply
* Re: [PATCH] net: ethernet: stmmac: properly set PS bit in MII configurations during reset
From: Thomas Petazzoni @ 2017-05-10 7:18 UTC (permalink / raw)
To: Giuseppe CAVALLARO; +Cc: Corentin Labbe, Alexandre Torgue, netdev, stable
In-Reply-To: <e8151650-aa51-6713-f10c-b3663763ff78@st.com>
Hello,
On Wed, 10 May 2017 09:03:12 +0200, Giuseppe CAVALLARO wrote:
> > Please, read again my patch and the description of the problem that I
> > have sent. But basically, any solution that does not allow to set the
> > PS bit between asserting the DMA reset bit and polling for it to clear
> > will not work for MII PHYs.
>
> yes your point was clear to me, I was just wondering if we could find an
> easier way
> to solve it w/o changing the API, adding the set_ps and propagating the
> "interface"
> inside the DMA reset.
>
> Maybe this could be fixed in the glue-logic in some way. Let me know
> what do you think.
Well, it's more up to you to tell me how you would like this be solved.
We figured out what the problem was, but I don't know well enough the
architecture of the driver to decide how the solution to this problem
should be designed. I made an initial simple proposal to show what is
needed, but I'm definitely open to suggestions.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH] net: ethernet: stmmac: properly set PS bit in MII configurations during reset
From: Giuseppe CAVALLARO @ 2017-05-10 7:03 UTC (permalink / raw)
To: Thomas Petazzoni; +Cc: Corentin Labbe, Alexandre Torgue, netdev, stable
In-Reply-To: <20170508211230.58aeead9@free-electrons.com>
Hi Thomas
On 5/8/2017 9:12 PM, Thomas Petazzoni wrote:
> Hello,
>
> On Mon, 8 May 2017 16:28:21 +0200, Giuseppe CAVALLARO wrote:
>
>>> I just see that GMAC_CONTROL and MAC_CTRL_REG are the same, so why not create a custom adjust_link for each dwmac type ?
>>> This will permit to call it instead of set_ps() and remove lots of if (has_gmac) and co in stmmac_adjust_link()
>>> Basicly replace all between "ctrl = readl()... and writel(ctrl)" by a sot of priv->hw->mac->adjust_link()
>>>
>>> It will also help a lot for my dwmac-sun8i inclusion (since I add some if has_sun8i:))
>> Corentin, I think this is a good idea and maybe necessary now that the
>> driver is supporting a lot of chips.
>> In the past it was sufficient to have a adjust link function and a
>> stmmac_hw_fix_mac_speed
>> to invoke dedicated hook shared between MAC10/100 and GMAC inside STM
>> platforms.
>>
>> Thomas, I wonder if you could take a look at the
>> priv->plat->fix_mac_speed. This can be used
>> for setting internal registers too.
> Once again, this is not called at the right time to fix the issue I'm
> seeing with a MII PHY. I need to adjust the PS bit between asserting the
> reset and polling for the reset bit to clear.
>
> ->fix_mac_speed() is called in the adjust_link() call-back, which is
> called way too late.
>
> Please, read again my patch and the description of the problem that I
> have sent. But basically, any solution that does not allow to set the
> PS bit between asserting the DMA reset bit and polling for it to clear
> will not work for MII PHYs.
yes your point was clear to me, I was just wondering if we could find an
easier way
to solve it w/o changing the API, adding the set_ps and propagating the
"interface"
inside the DMA reset.
Maybe this could be fixed in the glue-logic in some way. Let me know
what do you think.
peppe
>
> Best regards,
>
> Thomas Petazzoni
^ permalink raw reply
* Re: [PATCH 0/4] net: stmmac: Fine-tuning for four function implementations
From: Giuseppe CAVALLARO @ 2017-05-10 6:56 UTC (permalink / raw)
To: SF Markus Elfring, netdev, Alexandre Torgue; +Cc: LKML, kernel-janitors
In-Reply-To: <aa58027a-a39c-963e-4376-a4d5312ee118@users.sourceforge.net>
Hello Markus
Thanks a lot for your effort on stmmac
On 5/9/2017 1:51 PM, SF Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Tue, 9 May 2017 13:48:03 +0200
>
> A few update suggestions were taken into account
> from static source code analysis.
>
> Markus Elfring (4):
> Combine three seq_printf() calls into a seq_puts() in stmmac_sysfs_dma_cap_read()
> Replace five seq_printf() calls by seq_puts()
> Use seq_putc() in sysfs_display_ring()
> Delete an unnecessary return statement in stmmac_get_tx_hwtstamp()
>
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 22 ++++++++++------------
> 1 file changed, 10 insertions(+), 12 deletions(-)
Acked-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
^ permalink raw reply
* Re: bpf pointer alignment validation
From: Alexei Starovoitov @ 2017-05-10 5:57 UTC (permalink / raw)
To: David Miller; +Cc: daniel, ast, netdev
In-Reply-To: <20170509.143234.1785658771452710730.davem@davemloft.net>
On Tue, May 09, 2017 at 02:32:34PM -0400, David Miller wrote:
>
> +static u32 calc_align(u32 imm)
> +{
> + u32 align = 1;
> +
> + if (!imm)
> + return 1U << 31;
> +
> + while (!(imm & 1)) {
> + imm >>= 1;
> + align <<= 1;
> + }
> + return align;
> +}
same question as in previous reply.
Why not to use something like:
static u32 calc_align(u32 n)
{
if (!n)
return 1U << 31;
return n - ((n - 1) & n);
}
> - if (log_level && do_print_state) {
> + if (log_level > 1 || (log_level && do_print_state)) {
> verbose("\nfrom %d to %d:", prev_insn_idx, insn_idx);
> print_verifier_state(&env->cur_state);
> do_print_state = false;
this needs to be tweaked like
if (log_level > 1)
verbose("%d:", insn_idx);
else
verbose("\nfrom %d to %d:", prev_insn_idx, insn_idx);
otherwise it prints prev_insn_idx which is meaningful
only with processing exit and search pruning.
That's why below ...
> + .descr = "unknown shift",
> + .insns = {
> + LOAD_UNKNOWN(BPF_REG_3),
> + BPF_ALU64_IMM(BPF_LSH, BPF_REG_3, 1),
> + BPF_ALU64_IMM(BPF_LSH, BPF_REG_3, 1),
> + BPF_ALU64_IMM(BPF_LSH, BPF_REG_3, 1),
> + BPF_ALU64_IMM(BPF_LSH, BPF_REG_3, 1),
> + LOAD_UNKNOWN(BPF_REG_4),
> + BPF_ALU64_IMM(BPF_LSH, BPF_REG_4, 5),
> + BPF_ALU64_IMM(BPF_RSH, BPF_REG_4, 1),
> + BPF_ALU64_IMM(BPF_RSH, BPF_REG_4, 1),
> + BPF_ALU64_IMM(BPF_RSH, BPF_REG_4, 1),
> + BPF_ALU64_IMM(BPF_RSH, BPF_REG_4, 1),
> + BPF_MOV64_IMM(BPF_REG_0, 0),
> + BPF_EXIT_INSN(),
> + },
> + .prog_type = BPF_PROG_TYPE_SCHED_CLS,
> + .matches = {
> + "from 4 to 7: R0=pkt(id=0,off=8,r=8) R1=ctx R2=pkt(id=0,off=0,r=8) R3=inv56 R10=fp",
> + "from 4 to 8: R0=pkt(id=0,off=8,r=8) R1=ctx R2=pkt(id=0,off=0,r=8) R3=inv55,min_align=2 R10=fp",
> + "from 4 to 9: R0=pkt(id=0,off=8,r=8) R1=ctx R2=pkt(id=0,off=0,r=8) R3=inv54,min_align=4 R10=fp",
> + "from 4 to 10: R0=pkt(id=0,off=8,r=8) R1=ctx R2=pkt(id=0,off=0,r=8) R3=inv53,min_align=8 R10=fp",
> + "from 4 to 11: R0=pkt(id=0,off=8,r=8) R1=ctx R2=pkt(id=0,off=0,r=8) R3=inv52,min_align=16 R10=fp",
> + "from 15 to 18: R0=pkt(id=0,off=8,r=8) R1=ctx R2=pkt(id=0,off=0,r=8) R3=pkt_end R4=inv56 R10=fp",
> + "from 15 to 19: R0=pkt(id=0,off=8,r=8) R1=ctx R2=pkt(id=0,off=0,r=8) R3=pkt_end R4=inv51,min_align=32 R10=fp",
> + "from 15 to 20: R0=pkt(id=0,off=8,r=8) R1=ctx R2=pkt(id=0,off=0,r=8) R3=pkt_end R4=inv52,min_align=16 R10=fp",
... looks crazy here, since program is linear and 'from 4' and 'from 15' are
completely non-obvious and will change in the future for sure.
Since it just happened that search pruning heuristic kicked in at those points.
Hence doing verbose("%d:", insn_idx); is necessary to avoid noise.
> + .prog_type = BPF_PROG_TYPE_SCHED_CLS,
> + .matches = {
> + /* Calculated offset in R4 has unknown value, but known
> + * alignment of 4.
> + */
> + "from 4 to 8: R0=pkt(id=0,off=8,r=8) R1=ctx R2=pkt(id=0,off=0,r=8) R3=pkt_end R6=inv54,min_align=4 R10=fp",
> +
> + /* Offset is added to packet pointer, resulting in known
> + * auxiliary alignment and offset.
> + */
> + "from 4 to 11: R0=pkt(id=0,off=8,r=8) R1=ctx R2=pkt(id=0,off=0,r=8) R3=pkt_end R5=pkt(id=1,off=0,r=0),aux_off=14,aux_off_align=4 R6=inv54,min_align=4 R10=fp",
> +
> + /* At the time the word size load is performed from R5,
> + * it's total offset is NET_IP_ALIGN + reg->off (0) +
> + * reg->aux_off (14) which is 16. Then the variable
> + * offset is considered using reg->aux_off_align which
> + * is 4 and meets the load's requirements.
> + */
> + "from 13 to 15: R0=pkt(id=0,off=8,r=8) R1=ctx R2=pkt(id=0,off=0,r=8) R3=pkt_end R4=pkt(id=1,off=4,r=4),aux_off=14,aux_off_align=4 R5=pkt(id=1,off=0,r=4),aux_off=14,aux_off_align=4 R6=inv54,min_align=4 R10=fp",
> +
> +
> + /* Variable offset is added to R5 packet pointer,
> + * resulting in auxiliary alignment of 4.
> + */
> + "from 13 to 18: R0=pkt(id=0,off=8,r=8) R1=ctx R2=pkt(id=0,off=0,r=8) R3=pkt_end R4=inv,aux_off=14,aux_off_align=4 R5=pkt(id=2,off=0,r=0),aux_off_align=4 R6=inv54,min_align=4 R10=fp",
> +
> + /* Constant offset is added to R5, resulting in
> + * reg->off of 14.
> + */
> + "from 13 to 19: R0=pkt(id=0,off=8,r=8) R1=ctx R2=pkt(id=0,off=0,r=8) R3=pkt_end R4=inv,aux_off=14,aux_off_align=4 R5=pkt(id=2,off=14,r=0),aux_off_align=4 R6=inv54,min_align=4 R10=fp",
> +
> + /* At the time the word size load is performed from R5,
> + * it's total offset is NET_IP_ALIGN + reg->off (14) which
> + * is 16. Then the variable offset is considered using
> + * reg->aux_off_align which is 4 and meets the load's
> + * requirements.
> + */
> + "from 21 to 23: R0=pkt(id=0,off=8,r=8) R1=ctx R2=pkt(id=0,off=0,r=8) R3=pkt_end R4=pkt(id=2,off=18,r=18),aux_off_align=4 R5=pkt(id=2,off=14,r=18),aux_off_align=4 R6=inv54,min_align=4 R10=fp",
Nice to see all these comments.
I wonder how we can make them automatic in the verifier.
Like if verifier can somehow hint the user in such human friendly way
about what is happening with the program.
Today that's the #1 problem. Most folks complaining
that verifier error messages are too hard to understand.
CTF should help. Proper data-flow analysis in the verifier should help too.
> +static int do_test_single(struct bpf_align_test *test)
> +{
> + struct bpf_insn *prog = test->insns;
> + int prog_type = test->prog_type;
> + int prog_len, i;
> + int fd_prog;
> + int ret;
> +
> + prog_len = probe_filter_length(prog);
> + fd_prog = bpf_verify_program(prog_type ? : BPF_PROG_TYPE_SOCKET_FILTER,
> + prog, prog_len, "GPL", 0,
> + bpf_vlog, sizeof(bpf_vlog));
> + if (fd_prog < 0) {
> + printf("Failed to load program.\n");
> + printf("%s", bpf_vlog);
> + ret = 1;
> + } else {
> + ret = 0;
> + for (i = 0; i < MAX_MATCHES; i++) {
> + const char *t, *m = test->matches[i];
> +
> + if (!m)
> + break;
> + t = strstr(bpf_vlog, m);
> + if (!t) {
> + printf("Failed to find match: %s\n", m);
> + ret = 1;
> + printf("%s", bpf_vlog);
> + break;
> + }
> + }
> + /* printf("%s", bpf_vlog); */
> + close(fd_prog);
would it make sense to bpf_prog_test_run() it here as well?
On x86 not much value, but on sparc we can somehow look for traps?
Is there some counter of unaligned traps that we can read and report
as error to user space after prog_test_run ?
These tests we cannot really run, since they don't do any load/store.
I mean more for some future tests. Or some sort of debug warn
that there were traps while bpf prog was executed, so the user
is alarmed and reports to us, since that would be a bug in verifier
align logic?
^ permalink raw reply
* Re: DQL and TCQ_F_CAN_BYPASS destroy performance under virtualizaiton (Was: "Re: net_sched strange in 4.11")
From: Anton Ivanov @ 2017-05-10 5:35 UTC (permalink / raw)
To: Jason Wang, Stefan Hajnoczi; +Cc: David S. Miller, netdev, Michael S. Tsirkin
In-Reply-To: <52801b17-d8af-eaba-3ecf-fa4495c352f5@redhat.com>
[snip]
> Virtio-net net does not support BQL. Before commit ea7735d97ba9
> ("virtio-net: move free_old_xmit_skbs"), it's even impossible to
> support that since we don't have tx interrupt for each packet. I
> haven't measured the impact of xmit_more, maybe I was wrong but I
> think it may help in some cases since it may improve the batching on
> host more or less.
Sorry, hit send too soon.
Impact of xmit more depends on your transport.
If, for example, you are using sendmmsg on the outer side which can
consume the bulked data "as is", the impact is quite significant. If
your transport does not support bulking, the fact there was bulking
earlier in the chain has little impact.
There is some, but not a lot.
[snip]
--
Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
^ permalink raw reply
* Re: DQL and TCQ_F_CAN_BYPASS destroy performance under virtualizaiton (Was: "Re: net_sched strange in 4.11")
From: Anton Ivanov @ 2017-05-10 5:28 UTC (permalink / raw)
To: Jason Wang, Stefan Hajnoczi; +Cc: David S. Miller, netdev, Michael S. Tsirkin
In-Reply-To: <52801b17-d8af-eaba-3ecf-fa4495c352f5@redhat.com>
On 10/05/17 03:18, Jason Wang wrote:
>
>
> On 2017年05月09日 23:11, Stefan Hajnoczi wrote:
>> On Tue, May 09, 2017 at 08:46:46AM +0100, Anton Ivanov wrote:
>>> I have figured it out. Two issues.
>>>
>>> 1) skb->xmit_more is hardly ever set under virtualization because
>>> the qdisc
>>> is usually bypassed because of TCQ_F_CAN_BYPASS. Once
>>> TCQ_F_CAN_BYPASS is
>>> set a virtual NIC driver is not likely see skb->xmit_more (this
>>> answers my
>>> "how does this work at all" question).
>>>
>>> 2) If that flag is turned off (I patched sched_generic to turn it
>>> off in
>>> pfifo_fast while testing), DQL keeps xmit_more from being set. If
>>> the driver
>>> is not DQL enabled xmit_more is never ever set. If the driver is DQL
>>> enabled
>>> the queue is adjusted to ensure xmit_more stops happening within
>>> 10-15 xmit
>>> cycles.
>>>
>>> That is plain *wrong* for virtual NICs - virtio, emulated NICs, etc.
>>> There,
>>> the BIG cost is telling the hypervisor that it needs to "kick" the
>>> packets.
>>> The cost of putting them into the vNIC buffers is negligible. You want
>>> xmit_more to happen - it makes between 50% and 300% (depending on vNIC
>>> design) difference. If there is no xmit_more the vNIC will immediately
>>> "kick" the hypervisor and try to signal that the packet needs to move
>>> straight away (as for example in virtio_net).
>
> How do you measure the performance? TCP or just measure pps?
In this particular case - tcp from guest. I have a couple of other
benchmarks (forwarding, etc).
>
>>>
>>> In addition to that, the perceived line rate is proportional to this
>>> cost,
>>> so I am not sure that the current dql math holds. In fact, I think
>>> it does
>>> not - it is trying to adjust something which influences the
>>> perceived line
>>> rate.
>>>
>>> So - how do we turn BOTH bypass and DQL adjustment while under
>>> virtualization and set them to be "always qdisc" + "always xmit_more
>>> allowed"
>
> Virtio-net net does not support BQL. Before commit ea7735d97ba9
> ("virtio-net: move free_old_xmit_skbs"), it's even impossible to
> support that since we don't have tx interrupt for each packet. I
> haven't measured the impact of xmit_more, maybe I was wrong but I
> think it may help in some cases since it may improve the batching on
> host more or less.
If you do not support BQL, you might as well look the xmit_more part
kick code path. Line 1127.
bool kick = !skb->xmit_more; effectively means kick = true;
It will never be triggered. You will be kicking each packet and per
packet. xmit_more is now set only out of BQL. If BQL is not enabled you
never get it. Now, will the current dql code work correctly if you do
not have a defined line rate and completion interrupts - no idea.
Probably not. IMHO instead of trying to fix it there should be a way for
a device or architecture to turn it off.
To be clear - I ran into this working on my own drivers for UML, you are
cc-ed because you are likely to be one of the most affected.
A.
>
> Thanks
>
>>>
>>> A.
>>>
>>> P.S. Cc-ing virtio maintainer
>> CCing Michael Tsirkin and Jason Wang, who are the core virtio and
>> virtio-net maintainers. (I maintain the vsock driver - it's unrelated
>> to this discussion.)
>>
>>> A.
>>>
>>>
>>> On 08/05/17 08:15, Anton Ivanov wrote:
>>>> Hi all,
>>>>
>>>> I was revising some of my old work for UML to prepare it for
>>>> submission
>>>> and I noticed that skb->xmit_more does not seem to be set any more.
>>>>
>>>> I traced the issue as far as net/sched/sched_generic.c
>>>>
>>>> try_bulk_dequeue_skb() is never invoked (the drivers I am working
>>>> on are
>>>> dql enabled so that is not the problem).
>>>>
>>>> More interestingly, if I put a breakpoint and debug output into
>>>> dequeue_skb() around line 147 - right before the bulk: tag that skb
>>>> there is always NULL. ???
>>>>
>>>> Similarly, debug in pfifo_fast_dequeue shows only NULLs being
>>>> dequeued.
>>>> Again - ???
>>>>
>>>> First and foremost, I apologize for the silly question, but how can
>>>> this
>>>> work at all? I see the skbs showing up at the driver level, why are
>>>> NULLs being returned at qdisc dequeue and where do the skbs at the
>>>> driver level come from?
>>>>
>>>> Second, where should I look to fix it?
>>>>
>>>> A.
>>>>
>>>
>>> --
>>> Anton R. Ivanov
>>>
>>> Cambridge Greys Limited, England company No 10273661
>>> http://www.cambridgegreys.com/
>>>
>
>
--
Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
^ permalink raw reply
* Re: [PATCH] net: fec: select queue depending on VLAN priority
From: Stefan Agner @ 2017-05-10 4:51 UTC (permalink / raw)
To: David Miller; +Cc: fugang.duan, andrew, festevam, netdev, linux-kernel
In-Reply-To: <20170509.093913.1803457630634565212.davem@davemloft.net>
On 2017-05-09 06:39, David Miller wrote:
> From: Stefan Agner <stefan@agner.ch>
> Date: Mon, 8 May 2017 22:37:08 -0700
>
>> Since the addition of the multi queue code with commit 59d0f7465644
>> ("net: fec: init multi queue date structure") the queue selection
>> has been handelt by the default transmit queue selection
>> implementation which tries to evenly distribute the traffic across
>> all available queues. This selection presumes that the queues are
>> using an equal priority, however, the queues 1 and 2 are actually
>> of higher priority (the classification of the queues is enabled in
>> fec_enet_enable_ring).
>>
>> This can lead to net scheduler warnings and continuous TX ring
>> dumps when exercising the system with iperf.
>>
>> Use only queue 0 for all common traffic (no VLAN and P802.1p
>> priority 0 and 1) and route level 2-7 through queue 1 and 2.
>>
>> Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
>> Fixes: 59d0f7465644 ("net: fec: init multi queue date structure")
>
> If the queues are used for prioritization, and it does not have
> multiple normal priority level queues, multiqueue is not what the
> driver should have implemented.
As Andy mentioned, there is also a round-robin mode. I'll try that.
What would be the proper way to use the prioritized queues?
--
Stefan
^ permalink raw reply
* Re: [PATCH] libertas: Avoid reading past end of buffer
From: Joe Perches @ 2017-05-10 4:33 UTC (permalink / raw)
To: Kees Cook, netdev
Cc: Kalle Valo, libertas-dev, linux-wireless, linux-kernel,
Daniel Micay
In-Reply-To: <20170509232334.GA55070@beast>
On Tue, 2017-05-09 at 16:23 -0700, Kees Cook wrote:
> Using memcpy() from a string that is shorter than the length copied means
> the destination buffer is being filled with arbitrary data from the kernel
> rodata segment. Instead, use strncpy() which will fill the trailing bytes
> with zeros. Additionally adjust indentation to keep checkpatch.pl happy.
>
> This was found with the future CONFIG_FORTIFY_SOURCE feature.
[]
> diff --git a/drivers/net/wireless/marvell/libertas/mesh.c b/drivers/net/wireless/marvell/libertas/mesh.c
[]
> @@ -1177,9 +1177,9 @@ void lbs_mesh_ethtool_get_strings(struct net_device *dev,
> switch (stringset) {
> case ETH_SS_STATS:
> for (i = 0; i < MESH_STATS_NUM; i++) {
> - memcpy(s + i * ETH_GSTRING_LEN,
> - mesh_stat_strings[i],
> - ETH_GSTRING_LEN);
> + strncpy(s + i * ETH_GSTRING_LEN,
> + mesh_stat_strings[i],
> + ETH_GSTRING_LEN);
> }
The better solution is to declare
mesh_stat_strings in in the normal way
---
drivers/net/wireless/marvell/libertas/mesh.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/marvell/libertas/mesh.c b/drivers/net/wireless/marvell/libertas/mesh.c
index d0c881dd5846..a535e7f48d2d 100644
--- a/drivers/net/wireless/marvell/libertas/mesh.c
+++ b/drivers/net/wireless/marvell/libertas/mesh.c
@@ -1108,15 +1108,15 @@ void lbs_mesh_set_txpd(struct lbs_private *priv,
* Ethtool related
*/
-static const char * const mesh_stat_strings[] = {
- "drop_duplicate_bcast",
- "drop_ttl_zero",
- "drop_no_fwd_route",
- "drop_no_buffers",
- "fwded_unicast_cnt",
- "fwded_bcast_cnt",
- "drop_blind_table",
- "tx_failed_cnt"
+static const char mesh_stat_strings[][ETH_GSTRING_LEN] = {
+ "drop_duplicate_bcast",
+ "drop_ttl_zero",
+ "drop_no_fwd_route",
+ "drop_no_buffers",
+ "fwded_unicast_cnt",
+ "fwded_bcast_cnt",
+ "drop_blind_table",
+ "tx_failed_cnt",
};
void lbs_mesh_ethtool_get_stats(struct net_device *dev,
^ permalink raw reply related
* Re: [PATCH] net: dsa: loop: Free resources if initialization is deferred
From: Julia Lawall @ 2017-05-10 4:30 UTC (permalink / raw)
To: Christophe JAILLET
Cc: andrew, vivien.didelot, f.fainelli, netdev, linux-kernel,
kernel-janitors
In-Reply-To: <20170510041503.29363-1-christophe.jaillet@wanadoo.fr>
On Wed, 10 May 2017, Christophe JAILLET wrote:
> Free some devm'allocated memory in case of deferred driver initialization.
> This avoid to waste some memory in such a case.
I really think it would be helpful to mention the special behavior of
-EPROBE_DEFER. It doesn't take much space, and it coud be helpful to
someone in the future.
julia
>
> Suggested-by: Joe Perches <joe@perches.com>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> ---
> drivers/net/dsa/dsa_loop.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/dsa/dsa_loop.c b/drivers/net/dsa/dsa_loop.c
> index a19e1781e9bb..557afb418320 100644
> --- a/drivers/net/dsa/dsa_loop.c
> +++ b/drivers/net/dsa/dsa_loop.c
> @@ -260,8 +260,11 @@ static int dsa_loop_drv_probe(struct mdio_device *mdiodev)
> return -ENOMEM;
>
> ps->netdev = dev_get_by_name(&init_net, pdata->netdev);
> - if (!ps->netdev)
> + if (!ps->netdev) {
> + devm_kfree(&mdiodev->dev, ps);
> + devm_kfree(&mdiodev->dev, ds);
> return -EPROBE_DEFER;
> + }
>
> pdata->cd.netdev[DSA_LOOP_CPU_PORT] = &ps->netdev->dev;
>
> --
> 2.11.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH] net: dsa: loop: Free resources if initialization is deferred
From: Christophe JAILLET @ 2017-05-10 4:15 UTC (permalink / raw)
To: andrew, vivien.didelot, f.fainelli
Cc: netdev, linux-kernel, kernel-janitors, Christophe JAILLET
Free some devm'allocated memory in case of deferred driver initialization.
This avoid to waste some memory in such a case.
Suggested-by: Joe Perches <joe@perches.com>
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
drivers/net/dsa/dsa_loop.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/dsa/dsa_loop.c b/drivers/net/dsa/dsa_loop.c
index a19e1781e9bb..557afb418320 100644
--- a/drivers/net/dsa/dsa_loop.c
+++ b/drivers/net/dsa/dsa_loop.c
@@ -260,8 +260,11 @@ static int dsa_loop_drv_probe(struct mdio_device *mdiodev)
return -ENOMEM;
ps->netdev = dev_get_by_name(&init_net, pdata->netdev);
- if (!ps->netdev)
+ if (!ps->netdev) {
+ devm_kfree(&mdiodev->dev, ps);
+ devm_kfree(&mdiodev->dev, ds);
return -EPROBE_DEFER;
+ }
pdata->cd.netdev[DSA_LOOP_CPU_PORT] = &ps->netdev->dev;
--
2.11.0
^ permalink raw reply related
* [PATCH net-next V4 05/10] skb_array: introduce batch dequeuing
From: Jason Wang @ 2017-05-10 3:36 UTC (permalink / raw)
To: netdev, linux-kernel, mst; +Cc: Jason Wang
In-Reply-To: <1494387382-19916-1-git-send-email-jasowang@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
include/linux/skb_array.h | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/include/linux/skb_array.h b/include/linux/skb_array.h
index 79850b6..35226cd 100644
--- a/include/linux/skb_array.h
+++ b/include/linux/skb_array.h
@@ -97,21 +97,46 @@ static inline struct sk_buff *skb_array_consume(struct skb_array *a)
return ptr_ring_consume(&a->ring);
}
+static inline int skb_array_consume_batched(struct skb_array *a,
+ struct sk_buff **array, int n)
+{
+ return ptr_ring_consume_batched(&a->ring, (void **)array, n);
+}
+
static inline struct sk_buff *skb_array_consume_irq(struct skb_array *a)
{
return ptr_ring_consume_irq(&a->ring);
}
+static inline int skb_array_consume_batched_irq(struct skb_array *a,
+ struct sk_buff **array, int n)
+{
+ return ptr_ring_consume_batched_irq(&a->ring, (void **)array, n);
+}
+
static inline struct sk_buff *skb_array_consume_any(struct skb_array *a)
{
return ptr_ring_consume_any(&a->ring);
}
+static inline int skb_array_consume_batched_any(struct skb_array *a,
+ struct sk_buff **array, int n)
+{
+ return ptr_ring_consume_batched_any(&a->ring, (void **)array, n);
+}
+
+
static inline struct sk_buff *skb_array_consume_bh(struct skb_array *a)
{
return ptr_ring_consume_bh(&a->ring);
}
+static inline int skb_array_consume_batched_bh(struct skb_array *a,
+ struct sk_buff **array, int n)
+{
+ return ptr_ring_consume_batched_bh(&a->ring, (void **)array, n);
+}
+
static inline int __skb_array_len_with_tag(struct sk_buff *skb)
{
if (likely(skb)) {
--
2.7.4
^ permalink raw reply related
* [PATCH net-next V4 10/10] vhost_net: try batch dequing from skb array
From: Jason Wang @ 2017-05-10 3:36 UTC (permalink / raw)
To: netdev, linux-kernel, mst; +Cc: Jason Wang
In-Reply-To: <1494387382-19916-1-git-send-email-jasowang@redhat.com>
We used to dequeue one skb during recvmsg() from skb_array, this could
be inefficient because of the bad cache utilization and spinlock
touching for each packet. This patch tries to batch them by calling
batch dequeuing helpers explicitly on the exported skb array and pass
the skb back through msg_control for underlayer socket to finish the
userspace copying.
Batch dequeuing is also the requirement for more batching improvement
on rx.
Tests were done by pktgen on tap with XDP1 in guest on top of batch
zeroing:
rx batch | pps
256 2.41Mpps (+6.16%)
128 2.48Mpps (+8.80%)
64 2.38Mpps (+3.96%) <- Default
16 2.31Mpps (+1.76%)
4 2.31Mpps (+1.76%)
1 2.30Mpps (+1.32%)
0 2.27Mpps (+7.48%)
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/vhost/net.c | 117 +++++++++++++++++++++++++++++++++++++++++++++++++---
1 file changed, 111 insertions(+), 6 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 9b51989..fbaecf3 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -28,6 +28,8 @@
#include <linux/if_macvlan.h>
#include <linux/if_tap.h>
#include <linux/if_vlan.h>
+#include <linux/skb_array.h>
+#include <linux/skbuff.h>
#include <net/sock.h>
@@ -85,6 +87,13 @@ struct vhost_net_ubuf_ref {
struct vhost_virtqueue *vq;
};
+#define VHOST_RX_BATCH 64
+struct vhost_net_buf {
+ struct sk_buff *queue[VHOST_RX_BATCH];
+ int tail;
+ int head;
+};
+
struct vhost_net_virtqueue {
struct vhost_virtqueue vq;
size_t vhost_hlen;
@@ -99,6 +108,8 @@ struct vhost_net_virtqueue {
/* Reference counting for outstanding ubufs.
* Protected by vq mutex. Writers must also take device mutex. */
struct vhost_net_ubuf_ref *ubufs;
+ struct skb_array *rx_array;
+ struct vhost_net_buf rxq;
};
struct vhost_net {
@@ -117,6 +128,71 @@ struct vhost_net {
static unsigned vhost_net_zcopy_mask __read_mostly;
+static void *vhost_net_buf_get_ptr(struct vhost_net_buf *rxq)
+{
+ if (rxq->tail != rxq->head)
+ return rxq->queue[rxq->head];
+ else
+ return NULL;
+}
+
+static int vhost_net_buf_get_size(struct vhost_net_buf *rxq)
+{
+ return rxq->tail - rxq->head;
+}
+
+static int vhost_net_buf_is_empty(struct vhost_net_buf *rxq)
+{
+ return rxq->tail == rxq->head;
+}
+
+static void *vhost_net_buf_consume(struct vhost_net_buf *rxq)
+{
+ void *ret = vhost_net_buf_get_ptr(rxq);
+ ++rxq->head;
+ return ret;
+}
+
+static int vhost_net_buf_produce(struct vhost_net_virtqueue *nvq)
+{
+ struct vhost_net_buf *rxq = &nvq->rxq;
+
+ rxq->head = 0;
+ rxq->tail = skb_array_consume_batched(nvq->rx_array, rxq->queue,
+ VHOST_RX_BATCH);
+ return rxq->tail;
+}
+
+static void vhost_net_buf_unproduce(struct vhost_net_virtqueue *nvq)
+{
+ struct vhost_net_buf *rxq = &nvq->rxq;
+
+ if (nvq->rx_array && !vhost_net_buf_is_empty(rxq)) {
+ skb_array_unconsume(nvq->rx_array, rxq->queue + rxq->head,
+ vhost_net_buf_get_size(rxq));
+ rxq->head = rxq->tail = 0;
+ }
+}
+
+static int vhost_net_buf_peek(struct vhost_net_virtqueue *nvq)
+{
+ struct vhost_net_buf *rxq = &nvq->rxq;
+
+ if (!vhost_net_buf_is_empty(rxq))
+ goto out;
+
+ if (!vhost_net_buf_produce(nvq))
+ return 0;
+
+out:
+ return __skb_array_len_with_tag(vhost_net_buf_get_ptr(rxq));
+}
+
+static void vhost_net_buf_init(struct vhost_net_buf *rxq)
+{
+ rxq->head = rxq->tail = 0;
+}
+
static void vhost_net_enable_zcopy(int vq)
{
vhost_net_zcopy_mask |= 0x1 << vq;
@@ -201,6 +277,7 @@ static void vhost_net_vq_reset(struct vhost_net *n)
n->vqs[i].ubufs = NULL;
n->vqs[i].vhost_hlen = 0;
n->vqs[i].sock_hlen = 0;
+ vhost_net_buf_init(&n->vqs[i].rxq);
}
}
@@ -503,15 +580,14 @@ static void handle_tx(struct vhost_net *net)
mutex_unlock(&vq->mutex);
}
-static int peek_head_len(struct sock *sk)
+static int peek_head_len(struct vhost_net_virtqueue *rvq, struct sock *sk)
{
- struct socket *sock = sk->sk_socket;
struct sk_buff *head;
int len = 0;
unsigned long flags;
- if (sock->ops->peek_len)
- return sock->ops->peek_len(sock);
+ if (rvq->rx_array)
+ return vhost_net_buf_peek(rvq);
spin_lock_irqsave(&sk->sk_receive_queue.lock, flags);
head = skb_peek(&sk->sk_receive_queue);
@@ -537,10 +613,11 @@ static int sk_has_rx_data(struct sock *sk)
static int vhost_net_rx_peek_head_len(struct vhost_net *net, struct sock *sk)
{
+ struct vhost_net_virtqueue *rvq = &net->vqs[VHOST_NET_VQ_RX];
struct vhost_net_virtqueue *nvq = &net->vqs[VHOST_NET_VQ_TX];
struct vhost_virtqueue *vq = &nvq->vq;
unsigned long uninitialized_var(endtime);
- int len = peek_head_len(sk);
+ int len = peek_head_len(rvq, sk);
if (!len && vq->busyloop_timeout) {
/* Both tx vq and rx socket were polled here */
@@ -561,7 +638,7 @@ static int vhost_net_rx_peek_head_len(struct vhost_net *net, struct sock *sk)
vhost_poll_queue(&vq->poll);
mutex_unlock(&vq->mutex);
- len = peek_head_len(sk);
+ len = peek_head_len(rvq, sk);
}
return len;
@@ -699,6 +776,8 @@ static void handle_rx(struct vhost_net *net)
/* On error, stop handling until the next kick. */
if (unlikely(headcount < 0))
goto out;
+ if (nvq->rx_array)
+ msg.msg_control = vhost_net_buf_consume(&nvq->rxq);
/* On overrun, truncate and discard */
if (unlikely(headcount > UIO_MAXIOV)) {
iov_iter_init(&msg.msg_iter, READ, vq->iov, 1, 1);
@@ -841,6 +920,7 @@ static int vhost_net_open(struct inode *inode, struct file *f)
n->vqs[i].done_idx = 0;
n->vqs[i].vhost_hlen = 0;
n->vqs[i].sock_hlen = 0;
+ vhost_net_buf_init(&n->vqs[i].rxq);
}
vhost_dev_init(dev, vqs, VHOST_NET_VQ_MAX);
@@ -856,11 +936,14 @@ static struct socket *vhost_net_stop_vq(struct vhost_net *n,
struct vhost_virtqueue *vq)
{
struct socket *sock;
+ struct vhost_net_virtqueue *nvq =
+ container_of(vq, struct vhost_net_virtqueue, vq);
mutex_lock(&vq->mutex);
sock = vq->private_data;
vhost_net_disable_vq(n, vq);
vq->private_data = NULL;
+ vhost_net_buf_unproduce(nvq);
mutex_unlock(&vq->mutex);
return sock;
}
@@ -953,6 +1036,25 @@ static struct socket *get_raw_socket(int fd)
return ERR_PTR(r);
}
+static struct skb_array *get_tap_skb_array(int fd)
+{
+ struct skb_array *array;
+ struct file *file = fget(fd);
+
+ if (!file)
+ return NULL;
+ array = tun_get_skb_array(file);
+ if (!IS_ERR(array))
+ goto out;
+ array = tap_get_skb_array(file);
+ if (!IS_ERR(array))
+ goto out;
+ array = NULL;
+out:
+ fput(file);
+ return array;
+}
+
static struct socket *get_tap_socket(int fd)
{
struct file *file = fget(fd);
@@ -1029,6 +1131,9 @@ static long vhost_net_set_backend(struct vhost_net *n, unsigned index, int fd)
vhost_net_disable_vq(n, vq);
vq->private_data = sock;
+ vhost_net_buf_unproduce(nvq);
+ if (index == VHOST_NET_VQ_RX)
+ nvq->rx_array = get_tap_skb_array(fd);
r = vhost_vq_init_access(vq);
if (r)
goto err_used;
--
2.7.4
^ permalink raw reply related
* [PATCH net-next V4 09/10] tap: support receiving skb from msg_control
From: Jason Wang @ 2017-05-10 3:36 UTC (permalink / raw)
To: netdev, linux-kernel, mst; +Cc: Jason Wang
In-Reply-To: <1494387382-19916-1-git-send-email-jasowang@redhat.com>
This patch makes tap_recvmsg() can receive from skb from its caller
through msg_control. Vhost_net will be the first user.
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/net/tap.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/net/tap.c b/drivers/net/tap.c
index abdaf86..9af3239 100644
--- a/drivers/net/tap.c
+++ b/drivers/net/tap.c
@@ -824,15 +824,17 @@ static ssize_t tap_put_user(struct tap_queue *q,
static ssize_t tap_do_read(struct tap_queue *q,
struct iov_iter *to,
- int noblock)
+ int noblock, struct sk_buff *skb)
{
DEFINE_WAIT(wait);
- struct sk_buff *skb;
ssize_t ret = 0;
if (!iov_iter_count(to))
return 0;
+ if (skb)
+ goto put;
+
while (1) {
if (!noblock)
prepare_to_wait(sk_sleep(&q->sk), &wait,
@@ -856,6 +858,7 @@ static ssize_t tap_do_read(struct tap_queue *q,
if (!noblock)
finish_wait(sk_sleep(&q->sk), &wait);
+put:
if (skb) {
ret = tap_put_user(q, skb, to);
if (unlikely(ret < 0))
@@ -872,7 +875,7 @@ static ssize_t tap_read_iter(struct kiocb *iocb, struct iov_iter *to)
struct tap_queue *q = file->private_data;
ssize_t len = iov_iter_count(to), ret;
- ret = tap_do_read(q, to, file->f_flags & O_NONBLOCK);
+ ret = tap_do_read(q, to, file->f_flags & O_NONBLOCK, NULL);
ret = min_t(ssize_t, ret, len);
if (ret > 0)
iocb->ki_pos = ret;
@@ -1155,7 +1158,8 @@ static int tap_recvmsg(struct socket *sock, struct msghdr *m,
int ret;
if (flags & ~(MSG_DONTWAIT|MSG_TRUNC))
return -EINVAL;
- ret = tap_do_read(q, &m->msg_iter, flags & MSG_DONTWAIT);
+ ret = tap_do_read(q, &m->msg_iter, flags & MSG_DONTWAIT,
+ m->msg_control);
if (ret > total_len) {
m->msg_flags |= MSG_TRUNC;
ret = flags & MSG_TRUNC ? ret : total_len;
--
2.7.4
^ permalink raw reply related
* [PATCH net-next V4 08/10] tun: support receiving skb through msg_control
From: Jason Wang @ 2017-05-10 3:36 UTC (permalink / raw)
To: netdev, linux-kernel, mst; +Cc: Jason Wang
In-Reply-To: <1494387382-19916-1-git-send-email-jasowang@redhat.com>
This patch makes tun_recvmsg() can receive from skb from its caller
through msg_control. Vhost_net will be the first user.
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/net/tun.c | 18 ++++++++++--------
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 3cbfc5c..f8041f9c 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1510,9 +1510,8 @@ static struct sk_buff *tun_ring_recv(struct tun_file *tfile, int noblock,
static ssize_t tun_do_read(struct tun_struct *tun, struct tun_file *tfile,
struct iov_iter *to,
- int noblock)
+ int noblock, struct sk_buff *skb)
{
- struct sk_buff *skb;
ssize_t ret;
int err;
@@ -1521,10 +1520,12 @@ static ssize_t tun_do_read(struct tun_struct *tun, struct tun_file *tfile,
if (!iov_iter_count(to))
return 0;
- /* Read frames from ring */
- skb = tun_ring_recv(tfile, noblock, &err);
- if (!skb)
- return err;
+ if (!skb) {
+ /* Read frames from ring */
+ skb = tun_ring_recv(tfile, noblock, &err);
+ if (!skb)
+ return err;
+ }
ret = tun_put_user(tun, tfile, skb, to);
if (unlikely(ret < 0))
@@ -1544,7 +1545,7 @@ static ssize_t tun_chr_read_iter(struct kiocb *iocb, struct iov_iter *to)
if (!tun)
return -EBADFD;
- ret = tun_do_read(tun, tfile, to, file->f_flags & O_NONBLOCK);
+ ret = tun_do_read(tun, tfile, to, file->f_flags & O_NONBLOCK, NULL);
ret = min_t(ssize_t, ret, len);
if (ret > 0)
iocb->ki_pos = ret;
@@ -1646,7 +1647,8 @@ static int tun_recvmsg(struct socket *sock, struct msghdr *m, size_t total_len,
SOL_PACKET, TUN_TX_TIMESTAMP);
goto out;
}
- ret = tun_do_read(tun, tfile, &m->msg_iter, flags & MSG_DONTWAIT);
+ ret = tun_do_read(tun, tfile, &m->msg_iter, flags & MSG_DONTWAIT,
+ m->msg_control);
if (ret > (ssize_t)total_len) {
m->msg_flags |= MSG_TRUNC;
ret = flags & MSG_TRUNC ? ret : total_len;
--
2.7.4
^ permalink raw reply related
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