* [PATCH net-next 14/22] net: caif: fix return type of ndo_start_xmit function
From: YueHaibing @ 2018-09-20 12:32 UTC (permalink / raw)
To: davem, dmitry.tarnyagin, wg, mkl, michal.simek, hsweeten,
madalin.bucur, pantelis.antoniou, claudiu.manoil, leoyang.li,
linux, sammy, ralf, nico, steve.glendinning, f.fainelli,
grygorii.strashko, w-kwok2, m-karicheri2, t.sailer, jreuter, kys,
haiyangz, wei.liu2, paul.durrant, arvid.brodin, pshelar
Cc: linux-kernel, netdev, linux-can, linux-arm-kernel, linuxppc-dev,
linux-mips, linux-omap, linux-hams, devel, linux-usb, xen-devel,
dev, YueHaibing
In-Reply-To: <20180920123306.14772-1-yuehaibing@huawei.com>
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, so make sure the implementation in
this driver has returns 'netdev_tx_t' value, and change the function
return type to netdev_tx_t.
Found by coccinelle.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/caif/caif_hsi.c | 10 +++++-----
drivers/net/caif/caif_serial.c | 7 +++++--
drivers/net/caif/caif_spi.c | 6 +++---
drivers/net/caif/caif_virtio.c | 2 +-
net/caif/chnl_net.c | 3 ++-
5 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/drivers/net/caif/caif_hsi.c b/drivers/net/caif/caif_hsi.c
index 433a14b..70c449e 100644
--- a/drivers/net/caif/caif_hsi.c
+++ b/drivers/net/caif/caif_hsi.c
@@ -1006,7 +1006,7 @@ static void cfhsi_aggregation_tout(struct timer_list *t)
cfhsi_start_tx(cfhsi);
}
-static int cfhsi_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t cfhsi_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct cfhsi *cfhsi = NULL;
int start_xfer = 0;
@@ -1014,7 +1014,7 @@ static int cfhsi_xmit(struct sk_buff *skb, struct net_device *dev)
int prio;
if (!dev)
- return -EINVAL;
+ return NETDEV_TX_BUSY;
cfhsi = netdev_priv(dev);
@@ -1048,7 +1048,7 @@ static int cfhsi_xmit(struct sk_buff *skb, struct net_device *dev)
if (WARN_ON(test_bit(CFHSI_SHUTDOWN, &cfhsi->bits))) {
spin_unlock_bh(&cfhsi->lock);
cfhsi_abort_tx(cfhsi);
- return -EINVAL;
+ return NETDEV_TX_BUSY;
}
/* Send flow off if number of packets is above high water mark. */
@@ -1072,7 +1072,7 @@ static int cfhsi_xmit(struct sk_buff *skb, struct net_device *dev)
spin_unlock_bh(&cfhsi->lock);
if (aggregate_ready)
cfhsi_start_tx(cfhsi);
- return 0;
+ return NETDEV_TX_OK;
}
/* Delete inactivity timer if started. */
@@ -1102,7 +1102,7 @@ static int cfhsi_xmit(struct sk_buff *skb, struct net_device *dev)
queue_work(cfhsi->wq, &cfhsi->wake_up_work);
}
- return 0;
+ return NETDEV_TX_OK;
}
static const struct net_device_ops cfhsi_netdevops;
diff --git a/drivers/net/caif/caif_serial.c b/drivers/net/caif/caif_serial.c
index a0f954f..acb3264 100644
--- a/drivers/net/caif/caif_serial.c
+++ b/drivers/net/caif/caif_serial.c
@@ -275,7 +275,7 @@ static int handle_tx(struct ser_device *ser)
return tty_wr;
}
-static int caif_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t caif_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct ser_device *ser;
@@ -290,7 +290,10 @@ static int caif_xmit(struct sk_buff *skb, struct net_device *dev)
ser->common.flowctrl(ser->dev, OFF);
skb_queue_tail(&ser->head, skb);
- return handle_tx(ser);
+ if (handle_tx(ser))
+ return NETDEV_TX_BUSY;
+
+ return NETDEV_TX_OK;
}
diff --git a/drivers/net/caif/caif_spi.c b/drivers/net/caif/caif_spi.c
index d28a139..9040658 100644
--- a/drivers/net/caif/caif_spi.c
+++ b/drivers/net/caif/caif_spi.c
@@ -486,12 +486,12 @@ static void cfspi_xfer_done_cb(struct cfspi_ifc *ifc)
complete(&cfspi->comp);
}
-static int cfspi_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t cfspi_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct cfspi *cfspi = NULL;
unsigned long flags;
if (!dev)
- return -EINVAL;
+ return NETDEV_TX_BUSY;
cfspi = netdev_priv(dev);
@@ -512,7 +512,7 @@ static int cfspi_xmit(struct sk_buff *skb, struct net_device *dev)
cfspi->cfdev.flowctrl(cfspi->ndev, 0);
}
- return 0;
+ return NETDEV_TX_OK;
}
int cfspi_rxfrm(struct cfspi *cfspi, u8 *buf, size_t len)
diff --git a/drivers/net/caif/caif_virtio.c b/drivers/net/caif/caif_virtio.c
index 2814e0d..f5507db 100644
--- a/drivers/net/caif/caif_virtio.c
+++ b/drivers/net/caif/caif_virtio.c
@@ -519,7 +519,7 @@ static struct buf_info *cfv_alloc_and_copy_to_shm(struct cfv_info *cfv,
}
/* Put the CAIF packet on the virtio ring and kick the receiver */
-static int cfv_netdev_tx(struct sk_buff *skb, struct net_device *netdev)
+static netdev_tx_t cfv_netdev_tx(struct sk_buff *skb, struct net_device *netdev)
{
struct cfv_info *cfv = netdev_priv(netdev);
struct buf_info *buf_info;
diff --git a/net/caif/chnl_net.c b/net/caif/chnl_net.c
index 13e2ae6..30be426 100644
--- a/net/caif/chnl_net.c
+++ b/net/caif/chnl_net.c
@@ -211,7 +211,8 @@ static void chnl_flowctrl_cb(struct cflayer *layr, enum caif_ctrlcmd flow,
}
}
-static int chnl_net_start_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t
+chnl_net_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct chnl_net *priv;
struct cfpkt *pkt = NULL;
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next 15/22] net: hamradio: fix return type of ndo_start_xmit function
From: YueHaibing @ 2018-09-20 12:32 UTC (permalink / raw)
To: davem, dmitry.tarnyagin, wg, mkl, michal.simek, hsweeten,
madalin.bucur, pantelis.antoniou, claudiu.manoil, leoyang.li,
linux, sammy, ralf, nico, steve.glendinning, f.fainelli,
grygorii.strashko, w-kwok2, m-karicheri2, t.sailer, jreuter, kys,
haiyangz, wei.liu2, paul.durrant, arvid.brodin, pshelar
Cc: linux-kernel, netdev, linux-can, linux-arm-kernel, linuxppc-dev,
linux-mips, linux-omap, linux-hams, devel, linux-usb, xen-devel,
dev, YueHaibing
In-Reply-To: <20180920123306.14772-1-yuehaibing@huawei.com>
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, so make sure the implementation in
this driver has returns 'netdev_tx_t' value, and change the function
return type to netdev_tx_t.
Found by coccinelle.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/hamradio/baycom_epp.c | 3 ++-
drivers/net/hamradio/dmascc.c | 4 ++--
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/hamradio/baycom_epp.c b/drivers/net/hamradio/baycom_epp.c
index 1e62d00..f4ceccf 100644
--- a/drivers/net/hamradio/baycom_epp.c
+++ b/drivers/net/hamradio/baycom_epp.c
@@ -772,7 +772,8 @@ static void epp_bh(struct work_struct *work)
* ===================== network driver interface =========================
*/
-static int baycom_send_packet(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t
+baycom_send_packet(struct sk_buff *skb, struct net_device *dev)
{
struct baycom_state *bc = netdev_priv(dev);
diff --git a/drivers/net/hamradio/dmascc.c b/drivers/net/hamradio/dmascc.c
index cde4120..2798870 100644
--- a/drivers/net/hamradio/dmascc.c
+++ b/drivers/net/hamradio/dmascc.c
@@ -239,7 +239,7 @@ struct scc_info {
static int scc_open(struct net_device *dev);
static int scc_close(struct net_device *dev);
static int scc_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd);
-static int scc_send_packet(struct sk_buff *skb, struct net_device *dev);
+static netdev_tx_t scc_send_packet(struct sk_buff *skb, struct net_device *dev);
static int scc_set_mac_address(struct net_device *dev, void *sa);
static inline void tx_on(struct scc_priv *priv);
@@ -921,7 +921,7 @@ static int scc_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
}
-static int scc_send_packet(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t scc_send_packet(struct sk_buff *skb, struct net_device *dev)
{
struct scc_priv *priv = dev->ml_priv;
unsigned long flags;
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next 17/22] hv_netvsc: fix return type of ndo_start_xmit function
From: YueHaibing @ 2018-09-20 12:33 UTC (permalink / raw)
To: davem, dmitry.tarnyagin, wg, mkl, michal.simek, hsweeten,
madalin.bucur, pantelis.antoniou, claudiu.manoil, leoyang.li,
linux, sammy, ralf, nico, steve.glendinning, f.fainelli,
grygorii.strashko, w-kwok2, m-karicheri2, t.sailer, jreuter, kys,
haiyangz, wei.liu2, paul.durrant, arvid.brodin, pshelar
Cc: dev, linux-mips, xen-devel, netdev, linux-usb, YueHaibing,
linux-kernel, linux-can, devel, linux-hams, linux-omap,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <20180920123306.14772-1-yuehaibing@huawei.com>
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, so make sure the implementation in
this driver has returns 'netdev_tx_t' value, and change the function
return type to netdev_tx_t.
Found by coccinelle.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/hyperv/netvsc_drv.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index 3af6d8d..056c472 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -511,7 +511,8 @@ static int netvsc_vf_xmit(struct net_device *net, struct net_device *vf_netdev,
return rc;
}
-static int netvsc_start_xmit(struct sk_buff *skb, struct net_device *net)
+static netdev_tx_t
+netvsc_start_xmit(struct sk_buff *skb, struct net_device *net)
{
struct net_device_context *net_device_ctx = netdev_priv(net);
struct hv_netvsc_packet *packet = NULL;
@@ -528,8 +529,11 @@ static int netvsc_start_xmit(struct sk_buff *skb, struct net_device *net)
*/
vf_netdev = rcu_dereference_bh(net_device_ctx->vf_netdev);
if (vf_netdev && netif_running(vf_netdev) &&
- !netpoll_tx_running(net))
- return netvsc_vf_xmit(net, vf_netdev, skb);
+ !netpoll_tx_running(net)) {
+ ret = netvsc_vf_xmit(net, vf_netdev, skb);
+ if (ret)
+ return NETDEV_TX_BUSY;
+ }
/* We will atmost need two pages to describe the rndis
* header. We can only transmit MAX_PAGE_BUFFER_COUNT number
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next 18/22] can: xilinx: fix return type of ndo_start_xmit function
From: YueHaibing @ 2018-09-20 12:33 UTC (permalink / raw)
To: davem, dmitry.tarnyagin, wg, mkl, michal.simek, hsweeten,
madalin.bucur, pantelis.antoniou, claudiu.manoil, leoyang.li,
linux, sammy, ralf, nico, steve.glendinning, f.fainelli,
grygorii.strashko, w-kwok2, m-karicheri2, t.sailer, jreuter, kys,
haiyangz, wei.liu2, paul.durrant, arvid.brodin, pshelar
Cc: linux-kernel, netdev, linux-can, linux-arm-kernel, linuxppc-dev,
linux-mips, linux-omap, linux-hams, devel, linux-usb, xen-devel,
dev, YueHaibing
In-Reply-To: <20180920123306.14772-1-yuehaibing@huawei.com>
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, so make sure the implementation in
this driver has returns 'netdev_tx_t' value, and change the function
return type to netdev_tx_t.
Found by coccinelle.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/can/xilinx_can.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/can/xilinx_can.c b/drivers/net/can/xilinx_can.c
index 045f084..6de5004 100644
--- a/drivers/net/can/xilinx_can.c
+++ b/drivers/net/can/xilinx_can.c
@@ -612,7 +612,7 @@ static int xcan_start_xmit_mailbox(struct sk_buff *skb, struct net_device *ndev)
*
* Return: NETDEV_TX_OK on success and NETDEV_TX_BUSY when the tx queue is full
*/
-static int xcan_start_xmit(struct sk_buff *skb, struct net_device *ndev)
+static netdev_tx_t xcan_start_xmit(struct sk_buff *skb, struct net_device *ndev)
{
struct xcan_priv *priv = netdev_priv(ndev);
int ret;
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next 20/22] rionet: fix return type of ndo_start_xmit function
From: YueHaibing @ 2018-09-20 12:33 UTC (permalink / raw)
To: davem, dmitry.tarnyagin, wg, mkl, michal.simek, hsweeten,
madalin.bucur, pantelis.antoniou, claudiu.manoil, leoyang.li,
linux, sammy, ralf, nico, steve.glendinning, f.fainelli,
grygorii.strashko, w-kwok2, m-karicheri2, t.sailer, jreuter, kys,
haiyangz, wei.liu2, paul.durrant, arvid.brodin, pshelar
Cc: linux-kernel, netdev, linux-can, linux-arm-kernel, linuxppc-dev,
linux-mips, linux-omap, linux-hams, devel, linux-usb, xen-devel,
dev, YueHaibing
In-Reply-To: <20180920123306.14772-1-yuehaibing@huawei.com>
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, so make sure the implementation in
this driver has returns 'netdev_tx_t' value, and change the function
return type to netdev_tx_t.
Found by coccinelle.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/rionet.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/rionet.c b/drivers/net/rionet.c
index e9f101c..de391c7 100644
--- a/drivers/net/rionet.c
+++ b/drivers/net/rionet.c
@@ -170,7 +170,8 @@ static int rionet_queue_tx_msg(struct sk_buff *skb, struct net_device *ndev,
return 0;
}
-static int rionet_start_xmit(struct sk_buff *skb, struct net_device *ndev)
+static netdev_tx_t
+rionet_start_xmit(struct sk_buff *skb, struct net_device *ndev)
{
int i;
struct rionet_private *rnet = netdev_priv(ndev);
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next 21/22] l2tp: fix return type of ndo_start_xmit function
From: YueHaibing @ 2018-09-20 12:33 UTC (permalink / raw)
To: davem, dmitry.tarnyagin, wg, mkl, michal.simek, hsweeten,
madalin.bucur, pantelis.antoniou, claudiu.manoil, leoyang.li,
linux, sammy, ralf, nico, steve.glendinning, f.fainelli,
grygorii.strashko, w-kwok2, m-karicheri2, t.sailer, jreuter, kys,
haiyangz, wei.liu2, paul.durrant, arvid.brodin, pshelar
Cc: dev, linux-mips, xen-devel, netdev, linux-usb, YueHaibing,
linux-kernel, linux-can, devel, linux-hams, linux-omap,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <20180920123306.14772-1-yuehaibing@huawei.com>
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, so make sure the implementation in
this driver has returns 'netdev_tx_t' value, and change the function
return type to netdev_tx_t.
Found by coccinelle.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
net/l2tp/l2tp_eth.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/l2tp/l2tp_eth.c b/net/l2tp/l2tp_eth.c
index 8aadc4f..4173cb1 100644
--- a/net/l2tp/l2tp_eth.c
+++ b/net/l2tp/l2tp_eth.c
@@ -77,7 +77,8 @@ static void l2tp_eth_dev_uninit(struct net_device *dev)
*/
}
-static int l2tp_eth_dev_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t
+l2tp_eth_dev_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct l2tp_eth *priv = netdev_priv(dev);
struct l2tp_session *session = priv->session;
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next 22/22] net: hsr: fix return type of ndo_start_xmit function
From: YueHaibing @ 2018-09-20 12:33 UTC (permalink / raw)
To: davem, dmitry.tarnyagin, wg, mkl, michal.simek, hsweeten,
madalin.bucur, pantelis.antoniou, claudiu.manoil, leoyang.li,
linux, sammy, ralf, nico, steve.glendinning, f.fainelli,
grygorii.strashko, w-kwok2, m-karicheri2, t.sailer, jreuter, kys,
haiyangz, wei.liu2, paul.durrant, arvid.brodin, pshelar
Cc: dev, linux-mips, xen-devel, netdev, linux-usb, YueHaibing,
linux-kernel, linux-can, devel, linux-hams, linux-omap,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <20180920123306.14772-1-yuehaibing@huawei.com>
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, so make sure the implementation in
this driver has returns 'netdev_tx_t' value, and change the function
return type to netdev_tx_t.
Found by coccinelle.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
net/hsr/hsr_device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/hsr/hsr_device.c b/net/hsr/hsr_device.c
index b8cd43c..a067150 100644
--- a/net/hsr/hsr_device.c
+++ b/net/hsr/hsr_device.c
@@ -233,7 +233,7 @@ static netdev_features_t hsr_fix_features(struct net_device *dev,
}
-static int hsr_dev_xmit(struct sk_buff *skb, struct net_device *dev)
+static netdev_tx_t hsr_dev_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct hsr_priv *hsr = netdev_priv(dev);
struct hsr_port *master;
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] brcm80211: remove redundant condition check before debugfs_remove_recursive
From: zhong jiang @ 2018-09-20 12:37 UTC (permalink / raw)
To: Kalle Valo
Cc: davem, hante.meuleman, franky.lin, arend.vanspriel,
linux-wireless, brcm80211-dev-list.pdl, netdev, linux-kernel
In-Reply-To: <877ejg1hcd.fsf@kamboji.qca.qualcomm.com>
On 2018/9/20 20:30, Kalle Valo wrote:
> zhong jiang <zhongjiang@huawei.com> writes:
>
>> On 2018/9/20 20:07, Kalle Valo wrote:
>>> zhong jiang <zhongjiang@huawei.com> wrote:
>>>
>>>> debugfs_remove_recursive has taken IS_ERR_OR_NULL into account. So just
>>>> remove the condition check before debugfs_remove_recursive.
>>>>
>>>> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
>>> It seems you already submitted an identical patch four days earlier:
>>>
>>> https://patchwork.kernel.org/patch/10593061/
>>>
>>> Why the duplicate? Please ALWAYS add a changelog and increase the version number:
>> I am sorry for that. Maybe I send the patch earlier, but I remeber I
>> should forget to cc to
>> netdev@vger.kernel.org and LMLK. So I repost it. Plese ingore the current patch.
> Even then please increase the version number and mention in the change
> log why you sent a new version. Otherwise you will make maintainers
> confused and wasting time with asking what has changed.
>
Get it and will keep it in mind . Thanks
Sincerely,
zhong jiang
^ permalink raw reply
* Re: [PATCH 0/2] net/sched: Add hardware specific counters to TC actions
From: Eelco Chaudron @ 2018-09-20 7:14 UTC (permalink / raw)
To: Jakub Kicinski
Cc: David Miller, netdev, jhs, xiyou.wangcong, jiri, simon.horman,
Marcelo Ricardo Leitner, louis.peens, Paolo, Davide Caratti
In-Reply-To: <20180829201211.6c58b827@cakuba.netronome.com>
On 29 Aug 2018, at 20:12, Jakub Kicinski wrote:
> On Wed, 29 Aug 2018 11:43:47 +0200, Eelco Chaudron wrote:
>> On 23 Aug 2018, at 20:14, Jakub Kicinski wrote:
>>
>>> On Mon, 20 Aug 2018 16:03:40 +0200, Eelco Chaudron wrote:
>>>> On 17 Aug 2018, at 13:27, Jakub Kicinski wrote:
>>>>> On Thu, 16 Aug 2018 14:02:44 +0200, Eelco Chaudron wrote:
>>>>>> On 11 Aug 2018, at 21:06, David Miller wrote:
>>>>>>
>>>>>>> From: Jakub Kicinski <jakub.kicinski@netronome.com>
>>>>>>> Date: Thu, 9 Aug 2018 20:26:08 -0700
>>>>>>>
>>>>>>>> It is not immediately clear why this is needed. The memory and
>>>>>>>> updating two sets of counters won't come for free, so perhaps a
>>>>>>>> stronger justification than troubleshooting is due? :S
>>>>>>>>
>>>>>>>> Netdev has counters for fallback vs forwarded traffic, so you'd
>>>>>>>> know
>>>>>>>> that traffic hits the SW datapath, plus the rules which are
>>>>>>>> in_hw
>>>>>>>> will
>>>>>>>> most likely not match as of today for flower (assuming
>>>>>>>> correctness).
>>>>>>
>>>>>> I strongly believe that these counters are a requirement for a
>>>>>> mixed
>>>>>> software/hardware (flow) based forwarding environment. The global
>>>>>> counters will not help much here as you might have chosen to have
>>>>>> certain traffic forwarded by software.
>>>>>>
>>>>>> These counters are probably the only option you have to figure
>>>>>> out
>>>>>> why
>>>>>> forwarding is not as fast as expected, and you want to blame the
>>>>>> TC
>>>>>> offload NIC.
>>>>>
>>>>> The suggested debugging flow would be:
>>>>> (1) check the global counter for fallback are incrementing;
>>>>> (2) find a flow with high stats but no in_hw flag set.
>>>>>
>>>>> The in_hw indication should be sufficient in most cases (unless
>>>>> there
>>>>> are shared blocks between netdevs of different ASICs...).
>>>>
>>>> I guess the aim is to find miss behaving hardware, i.e. having the
>>>> in_hw
>>>> flag set, but flows still coming to the kernel.
>>>
>>> For misbehaving hardware in_hw will not work indeed. Whether we
>>> need
>>> these extra always-on stats for such use case could be debated :)
>>>
>>>>>>>> I'm slightly concerned about potential performance impact,
>>>>>>>> would
>>>>>>>> you
>>>>>>>> be able to share some numbers for non-trivial number of flows
>>>>>>>> (100k
>>>>>>>> active?)?
>>>>>>>
>>>>>>> Agreed, features used for diagnostics cannot have a harmful
>>>>>>> penalty
>>>>>>> for fast path performance.
>>>>>>
>>>>>> Fast path performance is not affected as these counters are not
>>>>>> incremented there. They are only incremented by the nic driver
>>>>>> when
>>>>>> they
>>>>>> gather their statistics from hardware.
>>>>>
>>>>> Not by much, you are adding state to performance-critical
>>>>> structures,
>>>>> though, for what is effectively debugging purposes.
>>>>>
>>>>> I was mostly talking about the HW offload stat updates (sorry for
>>>>> not
>>>>> being clear).
>>>>>
>>>>> We can have some hundreds of thousands active offloaded flows,
>>>>> each
>>>>> of
>>>>> them can have multiple actions, and stats have to be updated
>>>>> multiple
>>>>> times per second and dumped probably around once a second, too.
>>>>> On
>>>>> a
>>>>> busy system the stats will get evicted from cache between each
>>>>> round.
>>>>>
>>>>> But I'm speculating let's see if I can get some numbers on it (if
>>>>> you
>>>>> could get some too, that would be great!).
>>>>
>>>> I’ll try to measure some of this later this week/early next week.
>>>
>>> I asked Louis to run some tests while I'm travelling, and he reports
>>> that my worry about reporting the extra stats was unfounded. Update
>>> function does not show up in traces at all. It seems under stress
>>> (generated with stress-ng) the thread dumping the stats in userspace
>>> (in OvS it would be the revalidator) actually consumes less CPU in
>>> __gnet_stats_copy_basic (0.4% less for ~2.0% total).
>>>
>>> Would this match with your results? I'm not sure why dumping would
>>> be
>>> faster with your change..
>>
>> Tested with OVS and https://github.com/chaudron/ovs_perf using 300K
>> TC
>> rules installed in HW.
>>
>> For __gnet_stats_copy_basic() being faster I have (had) a theory. Now
>> this function is called twice, and I assumed the first call would
>> cache
>> memory and the second call would be faster.
>>
>> Sampling a lot of perf data, I get an average of 1115ns with the base
>> kernel and 954ns with the fix applied, so about ~14%.
>>
>> Thought I would perf tcf_action_copy_stats() as it is the place
>> updating
>> the additional counter. But even in this case, I see a better
>> performance with the patch applied.
>>
>> In average 13581ns with the fix, vs base kernel at 1391ns, so about
>> 2.3%.
>>
>> I guess the changes to the tc_action structure got better cache
>> alignment.
>
> Interesting you could reproduce the speed up too! +1 for the guess.
> Seems like my caution about slowing down SW paths to support HW
> offload
> landed on a very unfortunate patch :)
Is there anything else blocking from getting this into net-next?
I still think this patch is beneficial for the full user experience, and
I’ve got requests from QA and others for this.
^ permalink raw reply
* Re: [PATCH net-next v2 05/10] net: sched: use Qdisc rcu API instead of relying on rtnl lock
From: Vlad Buslov @ 2018-09-20 7:20 UTC (permalink / raw)
To: Cong Wang
Cc: Linux Kernel Network Developers, Jamal Hadi Salim, Jiri Pirko,
David Miller, Stephen Hemminger, Kirill Tkhai, Nicolas Dichtel,
Greg KH, mark.rutland, Leon Romanovsky, Paul E. McKenney,
Florian Westphal, David Ahern, christian, lucien xin,
Jakub Kicinski, Jiri Benc
In-Reply-To: <CAM_iQpVKEU_RqxDPaTEo2KShKNATsHGJEa64afT-m6iadptNGw@mail.gmail.com>
On Wed 19 Sep 2018 at 22:04, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> On Mon, Sep 17, 2018 at 12:19 AM Vlad Buslov <vladbu@mellanox.com> wrote:
>> +static void tcf_qdisc_put(struct Qdisc *q, bool rtnl_held)
>> +{
>> + if (!q)
>> + return;
>> +
>> + if (rtnl_held)
>> + qdisc_put(q);
>> + else
>> + qdisc_put_unlocked(q);
>> +}
>
> This is very ugly. You should know whether RTNL is held or
> not when calling it.
>
> What's more, all of your code passes true, so why do you
> need a parameter for rtnl_held?
It passes true because currently rule update handlers still registered
as locked. This is a preparation for next patch set where this would be
changed to proper variable that depends on qdics and classifier type.
^ permalink raw reply
* [PATCH] smc: generic netlink family should be __ro_after_init
From: Johannes Berg @ 2018-09-20 7:27 UTC (permalink / raw)
To: linux-s390; +Cc: netdev, Ursula Braun, Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
The generic netlink family is only initialized during module init,
so it should be __ro_after_init like all other generic netlink
families.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/smc/smc_pnet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/smc/smc_pnet.c b/net/smc/smc_pnet.c
index 01c6ce042a1c..7cb3e4f07c10 100644
--- a/net/smc/smc_pnet.c
+++ b/net/smc/smc_pnet.c
@@ -461,7 +461,7 @@ static const struct genl_ops smc_pnet_ops[] = {
};
/* SMC_PNETID family definition */
-static struct genl_family smc_pnet_nl_family = {
+static struct genl_family smc_pnet_nl_family __ro_after_init = {
.hdrsize = 0,
.name = SMCR_GENL_FAMILY_NAME,
.version = SMCR_GENL_FAMILY_VERSION,
--
2.14.4
^ permalink raw reply related
* Re: [PATCH net-next v2 08/10] net: sched: protect block idr with spinlock
From: Vlad Buslov @ 2018-09-20 7:36 UTC (permalink / raw)
To: Cong Wang
Cc: Linux Kernel Network Developers, Jamal Hadi Salim, Jiri Pirko,
David Miller, Stephen Hemminger, Kirill Tkhai, Nicolas Dichtel,
Greg KH, mark.rutland, Leon Romanovsky, Paul E. McKenney,
Florian Westphal, David Ahern, christian, lucien xin,
Jakub Kicinski, Jiri Benc
In-Reply-To: <CAM_iQpVVKJtLJpjepPE=cpi2=3paxYp7yKvOz6PV6imjYi8BPQ@mail.gmail.com>
On Wed 19 Sep 2018 at 22:09, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> On Mon, Sep 17, 2018 at 12:19 AM Vlad Buslov <vladbu@mellanox.com> wrote:
>> @@ -482,16 +483,25 @@ static int tcf_block_insert(struct tcf_block *block, struct net *net,
>> struct netlink_ext_ack *extack)
>> {
>> struct tcf_net *tn = net_generic(net, tcf_net_id);
>> + int err;
>> +
>> + idr_preload(GFP_KERNEL);
>> + spin_lock(&tn->idr_lock);
>> + err = idr_alloc_u32(&tn->idr, block, &block->index, block->index,
>> + GFP_NOWAIT);
>
>
> Why GFP_NOWAIT rather than GFP_ATOMIC here?
I checked how idr_preload is used in kernel and in most places following
allocation uses GFP_NOWAIT (including idr-test.c). You suggest I should
change it to GFP_ATOMIC?
^ permalink raw reply
* Re: [PATCH net-next v5 06/20] zinc: ChaCha20 MIPS32r2 implementation
From: Jason A. Donenfeld @ 2018-09-20 13:19 UTC (permalink / raw)
To: paul.burton
Cc: LKML, Netdev, Linux Crypto Mailing List, David Miller,
Greg Kroah-Hartman, René van Dorst, Samuel Neves,
Andrew Lutomirski, Jean-Philippe Aumasson, Ralf Baechle, jhogan,
linux-mips
In-Reply-To: <20180918202549.ogfyunppxaha7sfu@pburton-laptop>
Hi Paul,
Thanks a bunch for the review.
On Tue, Sep 18, 2018 at 10:25 PM Paul Burton <paul.burton@mips.com> wrote:
> Should this be .set reorder?
Nice catch. Fixed here:
https://git.zx2c4.com/WireGuard/commit/?id=23d97fc333cf85dd07445a9d21a28cbef47c553c
But then...
> Even better - could we not just place the addiu before the bne & drop
> the .set noreorder, allowing the assembler to fill the delay slot with
> the addiu? Likewise in many other places throughout the patch.
>
> That would be more future proof - particularly if we ever want to adjust
> this for use with the nanoMIPS ISA which has no delay slots. It may also
> allow the assembler the choice to use compact branches (ie. branches
> without visible delay slots) when targeting MIPS32r6. I know neither of
> these will currently build this code, but I think avoiding all the
> noreorder blocks would be a nice cleanup just for the sake of
> readability anyway.
Great idea. Rene has committed that here:
https://git.zx2c4.com/WireGuard/commit/?id=5c153a59ac3aa58a3ff17c69fee63d599e5f2758
These will be in the v6 patchset whenever that's posted, and it's
already been merged into the dev tree:
https://git.kernel.org/pub/scm/linux/kernel/git/zx2c4/linux.git/log/?h=jd/wireguard
Regards,
Jason
^ permalink raw reply
* [PATCH bpf-next] samples/bpf: fix compilation failure
From: Prashant Bhole @ 2018-09-20 7:52 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann; +Cc: Prashant Bhole, netdev
following commit:
commit d58e468b1112 ("flow_dissector: implements flow dissector BPF hook")
added struct bpf_flow_keys which conflicts with the struct with
same name in sockex2_kern.c and sockex3_kern.c
similar to commit:
commit 534e0e52bc23 ("samples/bpf: fix a compilation failure")
we tried the rename it "flow_keys" but it also conflicted with struct
having same name in include/net/flow_dissector.h. Hence renaming the
struct to "flow_key_record". Also, this commit doesn't fix the
compilation error completely because the similar struct is present in
sockex3_kern.c. Hence renaming it in both files sockex3_user.c and
sockex3_kern.c
Signed-off-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
---
samples/bpf/sockex2_kern.c | 11 ++++++-----
samples/bpf/sockex3_kern.c | 8 ++++----
samples/bpf/sockex3_user.c | 4 ++--
3 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/samples/bpf/sockex2_kern.c b/samples/bpf/sockex2_kern.c
index f58acfc92556..f2f9dbc021b0 100644
--- a/samples/bpf/sockex2_kern.c
+++ b/samples/bpf/sockex2_kern.c
@@ -14,7 +14,7 @@ struct vlan_hdr {
__be16 h_vlan_encapsulated_proto;
};
-struct bpf_flow_keys {
+struct flow_key_record {
__be32 src;
__be32 dst;
union {
@@ -59,7 +59,7 @@ static inline __u32 ipv6_addr_hash(struct __sk_buff *ctx, __u64 off)
}
static inline __u64 parse_ip(struct __sk_buff *skb, __u64 nhoff, __u64 *ip_proto,
- struct bpf_flow_keys *flow)
+ struct flow_key_record *flow)
{
__u64 verlen;
@@ -83,7 +83,7 @@ static inline __u64 parse_ip(struct __sk_buff *skb, __u64 nhoff, __u64 *ip_proto
}
static inline __u64 parse_ipv6(struct __sk_buff *skb, __u64 nhoff, __u64 *ip_proto,
- struct bpf_flow_keys *flow)
+ struct flow_key_record *flow)
{
*ip_proto = load_byte(skb,
nhoff + offsetof(struct ipv6hdr, nexthdr));
@@ -96,7 +96,8 @@ static inline __u64 parse_ipv6(struct __sk_buff *skb, __u64 nhoff, __u64 *ip_pro
return nhoff;
}
-static inline bool flow_dissector(struct __sk_buff *skb, struct bpf_flow_keys *flow)
+static inline bool flow_dissector(struct __sk_buff *skb,
+ struct flow_key_record *flow)
{
__u64 nhoff = ETH_HLEN;
__u64 ip_proto;
@@ -198,7 +199,7 @@ struct bpf_map_def SEC("maps") hash_map = {
SEC("socket2")
int bpf_prog2(struct __sk_buff *skb)
{
- struct bpf_flow_keys flow = {};
+ struct flow_key_record flow = {};
struct pair *value;
u32 key;
diff --git a/samples/bpf/sockex3_kern.c b/samples/bpf/sockex3_kern.c
index 95907f8d2b17..c527b57d3ec8 100644
--- a/samples/bpf/sockex3_kern.c
+++ b/samples/bpf/sockex3_kern.c
@@ -61,7 +61,7 @@ struct vlan_hdr {
__be16 h_vlan_encapsulated_proto;
};
-struct bpf_flow_keys {
+struct flow_key_record {
__be32 src;
__be32 dst;
union {
@@ -88,7 +88,7 @@ static inline __u32 ipv6_addr_hash(struct __sk_buff *ctx, __u64 off)
}
struct globals {
- struct bpf_flow_keys flow;
+ struct flow_key_record flow;
};
struct bpf_map_def SEC("maps") percpu_map = {
@@ -114,14 +114,14 @@ struct pair {
struct bpf_map_def SEC("maps") hash_map = {
.type = BPF_MAP_TYPE_HASH,
- .key_size = sizeof(struct bpf_flow_keys),
+ .key_size = sizeof(struct flow_key_record),
.value_size = sizeof(struct pair),
.max_entries = 1024,
};
static void update_stats(struct __sk_buff *skb, struct globals *g)
{
- struct bpf_flow_keys key = g->flow;
+ struct flow_key_record key = g->flow;
struct pair *value;
value = bpf_map_lookup_elem(&hash_map, &key);
diff --git a/samples/bpf/sockex3_user.c b/samples/bpf/sockex3_user.c
index 22f74d0e1493..9d02e0404719 100644
--- a/samples/bpf/sockex3_user.c
+++ b/samples/bpf/sockex3_user.c
@@ -13,7 +13,7 @@
#define PARSE_IP_PROG_FD (prog_fd[0])
#define PROG_ARRAY_FD (map_fd[0])
-struct flow_keys {
+struct flow_key_record {
__be32 src;
__be32 dst;
union {
@@ -64,7 +64,7 @@ int main(int argc, char **argv)
(void) f;
for (i = 0; i < 5; i++) {
- struct flow_keys key = {}, next_key;
+ struct flow_key_record key = {}, next_key;
struct pair value;
sleep(1);
--
2.17.1
^ permalink raw reply related
* Re: [PATCH iproute2 v2 0/3] testsuite: make alltests fixes
From: Phil Sutter @ 2018-09-20 8:02 UTC (permalink / raw)
To: Petr Vorel; +Cc: netdev, Stephen Hemminger, Luca Boccassi
In-Reply-To: <20180919233624.18494-1-petr.vorel@gmail.com>
Hi Petr,
On Thu, Sep 20, 2018 at 01:36:21AM +0200, Petr Vorel wrote:
> here are simply fixes to restore 'make alltests'.
> Currently it does not run.
Yeah, that testsuite definitely deserves some love.
Just one nit: The one-line summary in Fixes: tags should be enclosed in
quotes and parens, e.g.:
| Fixes: deadbeef ("foo bar")
Cheers, Phil
^ permalink raw reply
* Re: [PATCH v3 net-next 07/12] net: ethernet: Add helper to remove a supported link mode
From: Simon Horman @ 2018-09-20 8:05 UTC (permalink / raw)
To: Andrew Lunn
Cc: David Miller, netdev, Florian Fainelli, Sergei Shtylyov,
linux-renesas-soc
In-Reply-To: <20180919123200.GB26940@lunn.ch>
On Wed, Sep 19, 2018 at 02:32:00PM +0200, Andrew Lunn wrote:
> > > And here also.
> >
> > Thanks for raising this, I noticed it too.
> >
> > > Looking at the code, i see:
> > >
> > > /* E-MAC init function */
> > > static void ravb_emac_init(struct net_device *ndev)
> > > {
> > > struct ravb_private *priv = netdev_priv(ndev);
> > >
> > > /* Receive frame limit set register */
> > > ravb_write(ndev, ndev->mtu + ETH_HLEN + VLAN_HLEN + ETH_FCS_LEN, RFLR);
> > >
> > > /* EMAC Mode: PAUSE prohibition; Duplex; RX Checksum; TX; RX */
> > > ravb_write(ndev, ECMR_ZPF | (priv->duplex ? ECMR_DM : 0) |
> > > (ndev->features & NETIF_F_RXCSUM ? ECMR_RCSC : 0) |
> > > ECMR_TE | ECMR_RE, ECMR);
> > >
> > > Does this mean Pause is not supported in the hardware?
> >
> > According to my reading of the documentation Pause is supported by the
> > hardware and the above code seems to conflict with the comment (possibly
> > both the code and comment predate the current documentation). My reading of
> > the documentation is that the above unconditionally _enables_ receiving and
> > sending Pause frames with time parameter value 0.
>
> Hi Simon
>
> We should first prove that this additional Pause is causing the
> issue. After that, we can decide if we want to add Pause support to
> the driver. Please could you test this patch.
Hi Andrew,
thanks for your patch. I agree with the approach you have taken here,
however, unfortunately this patch does not seem to resolve the problem that
I have observed.
With this patch on top of net-next ([1] & [2]) I see:
[1] net-next as of two days ago, the version used when reporting
results earlier in this thread
cf7d97e1e54d ("net: mdio: remove duplicated include from mdio_bus.c")
# mii-tool -vv eth0
Using SIOCGMIIPHY=0x8947
eth0: no link
registers for MII PHY 0:
1140 7949 0022 1622 0981 c1e1 000d 0000
0000 0300 0000 0000 0000 0000 0000 3000
0000 0000 0000 0000 7002 0000 0000 0200
0000 0000 0000 0500 0000 0000 0000 0000
product info: vendor 00:08:85, model 34 rev 2
basic mode: autonegotiation enabled
basic status: no link
capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
advertising: 100baseTx-FD 100baseTx-HD
link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
[2] net-next as of this morning
faa08325b429 ("isdn/hisax: Remove unnecessary parenthesis")
# mii-tool -vv eth0
Using SIOCGMIIPHY=0x8947
eth0: no link
registers for MII PHY 0:
1140 7949 0022 1622 0981 c1e1 000d 0000
0000 0300 0000 0000 0000 0000 0000 3000
0000 0000 0000 0000 6002 0000 0000 0200
0000 0000 0000 0500 0000 0000 0000 0000
product info: vendor 00:08:85, model 34 rev 2
basic mode: autonegotiation enabled
basic status: no link
capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
advertising: 100baseTx-FD 100baseTx-HD
link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
I note a difference in the 3rd line of hex output: 7002 vs 6002
but I am unsure if that is relevant.
^ permalink raw reply
* Re: [RFC 4/5] netlink: prepare validate extack setting for recursion
From: Johannes Berg @ 2018-09-20 8:14 UTC (permalink / raw)
To: Marcelo Ricardo Leitner; +Cc: netdev
In-Reply-To: <20180919211048.GN4590@localhost.localdomain>
On Wed, 2018-09-19 at 18:10 -0300, Marcelo Ricardo Leitner wrote:
> > FWIW, if you do think that there's a need for distinguishing this, then
> > I'd argue that perhaps the right way to address this would be to extend
> > this all the way to userspace and have two separate attributes for
> > errors and warnings in the extended ACK message?
>
> Likely, yes. And perhaps even support multiple messages. That way we
> could, for example, parse all attributes and return a list of the all
> the offending ones, instead of returning one at a time. Net benefit?
> Not clear.. over engineering? Possibly.
Not sure I'd want to continue parsing after hitting something that's
considered garbage? It might be that the attribute length field is
corrupted and the data is actually fine, or something, and then
continuing to parse would just lead to more errors over and over again.
Also, I'd worry about being able to "blow up" the message, if we get a
text & bad attribute for everything that's wrong, it's pretty easy to
create a sort of "message amplification" and we'd probably have to
defend against that in terms of limiting memory allocation for all the
possible errors etc. Not sure I'd want to go there.
> I agree with you that in general we should not need this.
:-)
> > I'm still not really sure what the use case for a warning is, so not
> > sure I can really comment on this.
>
> Good point. From iproute POV, a warning is a non-fatal message. From
> an user perspective, that probably translates are nothing because in
> the end the command actually worked. :-)
>
> Seriously, I do think it's more of a hint for developers than anyone
> else.
I guess we also have the (ratelimited) messages from the kernel, like
the one saying you have extra bytes after your attributes at the end of
the message. Not sure which makes more sense, depends on the specific
case you'd use this in I guess.
Anyway - we got into this discussion because of all the extra recursion
stuff I was adding. With the change suggested by David we don't need
that now at all, so I guess it'd be better to propose a patch if you (or
perhaps I will see a need later) need such a facility for multiple
messages or multiple message levels?
johannes
^ permalink raw reply
* Re: [PATCH net-next 13/22] net: xen-netback: fix return type of ndo_start_xmit function
From: Wei Liu @ 2018-09-20 14:05 UTC (permalink / raw)
To: YueHaibing
Cc: davem, dmitry.tarnyagin, wg, mkl, michal.simek, hsweeten,
madalin.bucur, pantelis.antoniou, claudiu.manoil, leoyang.li,
linux, sammy, ralf, nico, steve.glendinning, f.fainelli,
grygorii.strashko, w-kwok2, m-karicheri2, t.sailer, jreuter, kys,
haiyangz, wei.liu2, paul.durrant, arvid.brodin, pshelar,
linux-kernel, netdev, linux-can, linux-arm-kernel
In-Reply-To: <20180920123306.14772-14-yuehaibing@huawei.com>
On Thu, Sep 20, 2018 at 08:32:57PM +0800, YueHaibing wrote:
> The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
> which is a typedef for an enum type, so make sure the implementation in
> this driver has returns 'netdev_tx_t' value, and change the function
> return type to netdev_tx_t.
>
> Found by coccinelle.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
^ permalink raw reply
* Re: [PATCH v2 net-next] ravb: remove tx buffer addr 4byte alilgnment restriction for R-Car Gen3
From: Sergei Shtylyov @ 2018-09-20 8:36 UTC (permalink / raw)
To: David Miller, horms+renesas
Cc: magnus.damm, netdev, linux-renesas-soc, kazuya.mizuguchi.ks
In-Reply-To: <20180919.210836.924996973074874493.davem@davemloft.net>
On 9/20/2018 7:08 AM, David Miller wrote:
>> From: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
>>
>> This patch sets from two descriptor to one descriptor because R-Car Gen3
>> does not have the 4 bytes alignment restriction of the transmission buffer.
>>
>> Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
>> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>> ---
>> v2 [Simon Horman]
>> * As per review by Sergi Shtylyov
>> - Use reverse xmas tree for variable declarations
>> - Use > rather than >= for conditions
>> - Dropped unnecessary parentheses
>> - Don't allocate memory for tx_align when it will not be used
>> - But, kept NUM_TX_DESC_GEN[23] as I see some value in
>> the self-documentation provided by these #defines
>>
>> v1 [Kazuya Mizuguchi]
>
> Applied, thanks.
Mhm, I was just going to re-review the patch...
MBR, Sergei
^ permalink raw reply
* Re: [PATCH bpf-next 2/3] bpf: emit RECORD_MMAP events for bpf prog load/unload
From: Peter Zijlstra @ 2018-09-20 8:44 UTC (permalink / raw)
To: Alexei Starovoitov; +Cc: David S . Miller, daniel, acme, netdev, kernel-team
In-Reply-To: <20180919223935.999270-3-ast@kernel.org>
On Wed, Sep 19, 2018 at 03:39:34PM -0700, Alexei Starovoitov wrote:
> void bpf_prog_kallsyms_del(struct bpf_prog *fp)
> {
> + unsigned long symbol_start, symbol_end;
> + /* mmap_record.filename cannot be NULL and has to be u64 aligned */
> + char buf[sizeof(u64)] = {};
> +
> if (!bpf_prog_kallsyms_candidate(fp))
> return;
>
> spin_lock_bh(&bpf_lock);
> bpf_prog_ksym_node_del(fp->aux);
> spin_unlock_bh(&bpf_lock);
> + bpf_get_prog_addr_region(fp, &symbol_start, &symbol_end);
> + perf_event_mmap_bpf_prog(symbol_start, symbol_end - symbol_start,
> + buf, sizeof(buf));
> }
So perf doesn't normally issue unmap events.. We've talked about doing
that, but so far it's never really need needed I think.
I feels a bit weird to start issuing unmap events for this.
^ permalink raw reply
* [PATCH] mISDN: remove redundant null pointer check before kfree_skb
From: zhong jiang @ 2018-09-20 14:27 UTC (permalink / raw)
To: davem; +Cc: isdn, dvlasenk, gregkh, netdev, linux-kernel
kfree_skb has taken the null pointer into account. hence it is safe
to remove the redundant null pointer check before kfree_skb.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
drivers/isdn/mISDN/socket.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/isdn/mISDN/socket.c b/drivers/isdn/mISDN/socket.c
index 18c0a12..15d3ca3 100644
--- a/drivers/isdn/mISDN/socket.c
+++ b/drivers/isdn/mISDN/socket.c
@@ -236,8 +236,7 @@ static void mISDN_sock_unlink(struct mISDN_sock_list *l, struct sock *sk)
}
done:
- if (skb)
- kfree_skb(skb);
+ kfree_skb(skb);
release_sock(sk);
return err;
}
--
1.7.12.4
^ permalink raw reply related
* Re: [PATCH 00/21] SMMU enablement for NXP LS1043A and LS1046A
From: Laurentiu Tudor @ 2018-09-20 14:33 UTC (permalink / raw)
To: Robin Murphy, devicetree@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Cc: Roy Pledge, Leo Li, shawnguo@kernel.org, davem@davemloft.net,
Madalin-cristian Bucur
In-Reply-To: <c2acecc8-5357-6cbe-f93c-00d71470dff5@arm.com>
On 20.09.2018 14:49, Robin Murphy wrote:
> On 20/09/18 11:38, Laurentiu Tudor wrote:
>>
>>
>> On 19.09.2018 17:37, Robin Murphy wrote:
>>> On 19/09/18 15:18, Laurentiu Tudor wrote:
>>>> Hi Robin,
>>>>
>>>> On 19.09.2018 16:25, Robin Murphy wrote:
>>>>> Hi Laurentiu,
>>>>>
>>>>> On 19/09/18 13:35, laurentiu.tudor@nxp.com wrote:
>>>>>> From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
>>>>>>
>>>>>> This patch series adds SMMU support for NXP LS1043A and LS1046A chips
>>>>>> and consists mostly in important driver fixes and the required device
>>>>>> tree updates. It touches several subsystems and consists of three
>>>>>> main
>>>>>> parts:
>>>>>> - changes in soc/drivers/fsl/qbman drivers adding iommu
>>>>>> mapping of
>>>>>> reserved memory areas, fixes and defered probe support
>>>>>> - changes in drivers/net/ethernet/freescale/dpaa_eth drivers
>>>>>> consisting in misc dma mapping related fixes and probe ordering
>>>>>> - addition of the actual arm smmu device tree node together with
>>>>>> various adjustments to the device trees
>>>>>>
>>>>>> Performance impact
>>>>>>
>>>>>> Running iperf benchmarks in a back-to-back setup (both sides
>>>>>> having smmu enabled) on a 10GBps port show an important
>>>>>> networking performance degradation of around %40 (9.48Gbps
>>>>>> linerate vs 5.45Gbps). If you need performance but without
>>>>>> SMMU support you can use "iommu.passthrough=1" to disable
>>>>>> SMMU.
>
> I should have said before - thanks for the numbers there as well. Always
> good to add another datapoint to my collection. If you're interested
> I've added SMMUv2 support to the "non-strict mode" series (of which I
> should be posting v8 soon), so it might be fun to see how well that
> works on MMU-500 in the real world.
Hmm, I think I gave those a try some weeks ago and vaguely remember that
I did see improvements. Can't remember the numbers off the top of my
head but I'll re-test with the latest spin and update the numbers.
>>>>>>
>>>>>> USB issue and workaround
>>>>>>
>>>>>> There's a problem with the usb controllers in these chips
>>>>>> generating smaller, 40-bit wide dma addresses instead of the
>>>>>> 48-bit
>>>>>> supported at the smmu input. So you end up in a situation
>>>>>> where the
>>>>>> smmu is mapped with 48-bit address translations, but the
>>>>>> device
>>>>>> generates transactions with clipped 40-bit addresses, thus
>>>>>> smmu
>>>>>> context faults are triggered. I encountered a similar
>>>>>> situation for
>>>>>> mmc that I managed to fix in software [1] however for USB I
>>>>>> did not
>>>>>> find a proper place in the code to add a similar fix. The only
>>>>>> workaround I found was to add this kernel parameter which
>>>>>> limits the
>>>>>> usb dma to 32-bit size: "xhci-hcd.quirks=0x800000".
>>>>>> This workaround if far from ideal, so any suggestions for a
>>>>>> code
>>>>>> based workaround in this area would be greatly appreciated.
>>>>>
>>>>> If you have a nominally-64-bit device with a
>>>>> narrower-than-the-main-interconnect link in front of it, that should
>>>>> already be fixed in 4.19-rc by bus_dma_mask picking up DT dma-ranges,
>>>>> provided the interconnect hierarchy can be described appropriately (or
>>>>> at least massaged sufficiently to satisfy the binding), e.g.:
>>>>>
>>>>> / {
>>>>> ...
>>>>>
>>>>> soc {
>>>>> ranges;
>>>>> dma-ranges = <0 0 10000 0>;
>>>>>
>>>>> dev_48bit { ... };
>>>>>
>>>>> periph_bus {
>>>>> ranges;
>>>>> dma-ranges = <0 0 100 0>;
>>>>>
>>>>> dev_40bit { ... };
>>>>> };
>>>>> };
>>>>> };
>>>>>
>>>>> and if that fails to work as expected (except for PCI hosts where
>>>>> handling dma-ranges properly still needs sorting out), please do
>>>>> let us
>>>>> know ;)
>>>>>
>>>>
>>>> Just to confirm, Is this [1] the change I was supposed to test?
>>>
>>> Not quite - dma-ranges is only valid for nodes representing a bus, so
>>> putting it directly in the USB device nodes doesn't work (FWIW that's
>>> why PCI is broken, because the parser doesn't expect the
>>> bus-as-leaf-node case). That's teh point of that intermediate simple-bus
>>> node represented by "periph_bus" in my example (sorry, I should have put
>>> compatibles in to make it clearer) - often that's actually true to life
>>> (i.e. "soc" is something like a CCI and "periph_bus" is something like
>>> an AXI NIC gluing a bunch of lower-bandwidth DMA masters to one of the
>>> CCI ports) but at worst it's just a necessary evil to make the binding
>>> happy (if it literally only represents the point-to-point link between
>>> the device master port and interconnect slave port).
>>>
>>
>> Quick update: so I adjusted to device tree according to your example and
>> it works so now I can get rid of that nasty kernel arg based workaround,
>> yey! :-)
>
> Cool! In fact, judging by the block diagrams on the website, the "basic
> peripherals and interconnect" section hanging off the side of the CCI
> implies that probably is true to the real topology as I imagined, so it
> doesn't even count as a horrible hack :)
Indeed, on this chip there's a NoC lumping behind it several low-speed
devices such as usb, sata, esdhc.
>> Thanks a lot, that was really helpful.
>
> No problem. FWIW if you ever come to doing ACPI support for these SoCs,
> the equivalent is merely a case of setting the device memory address
> size limit field appropriately for all the named components.
>
Thanks, I'll keep this in mind. If i remember correctly, there are
people over here working on UEFI + ACPI support for some LS chips but
progress appears to be slow.
---
Best Regards, Laurentiu
^ permalink raw reply
* [PATCH][next-next][v2] netlink: avoid to allocate full skb when sending to many devices
From: Li RongQing @ 2018-09-20 8:54 UTC (permalink / raw)
To: netdev
if skb->head is vmalloc address, when this skb is delivered, full
allocation for this skb is required, if there are many devices,
the full allocation will be called for every devices
now if it is vmalloc, allocate a new skb, whose data is not vmalloc
address, and use new allocated skb to clone and send, to avoid to
allocate full skb everytime.
Signed-off-by: Zhang Yu <zhangyu31@baidu.com>
Signed-off-by: Li RongQing <lirongqing@baidu.com>
---
net/netlink/af_netlink.c | 37 ++++++++++++++++++++++++++++++-------
1 file changed, 30 insertions(+), 7 deletions(-)
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index e3a0538ec0be..a5b1bf706526 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -279,21 +279,25 @@ static bool netlink_filter_tap(const struct sk_buff *skb)
}
static int __netlink_deliver_tap_skb(struct sk_buff *skb,
- struct net_device *dev)
+ struct net_device *dev, bool alloc, bool last)
{
struct sk_buff *nskb;
struct sock *sk = skb->sk;
int ret = -ENOMEM;
- if (!net_eq(dev_net(dev), sock_net(sk)))
+ if (!net_eq(dev_net(dev), sock_net(sk))) {
+ if (last && alloc)
+ consume_skb(skb);
return 0;
+ }
dev_hold(dev);
- if (is_vmalloc_addr(skb->head))
- nskb = netlink_to_full_skb(skb, GFP_ATOMIC);
+ if (unlikely(last && alloc))
+ nskb = skb;
else
nskb = skb_clone(skb, GFP_ATOMIC);
+
if (nskb) {
nskb->dev = dev;
nskb->protocol = htons((u16) sk->sk_protocol);
@@ -303,6 +307,8 @@ static int __netlink_deliver_tap_skb(struct sk_buff *skb,
ret = dev_queue_xmit(nskb);
if (unlikely(ret > 0))
ret = net_xmit_errno(ret);
+ } else if (alloc) {
+ kfree_skb(skb);
}
dev_put(dev);
@@ -311,16 +317,33 @@ static int __netlink_deliver_tap_skb(struct sk_buff *skb,
static void __netlink_deliver_tap(struct sk_buff *skb, struct netlink_tap_net *nn)
{
+ struct netlink_tap *tmp, *next;
+ bool alloc = false;
int ret;
- struct netlink_tap *tmp;
if (!netlink_filter_tap(skb))
return;
- list_for_each_entry_rcu(tmp, &nn->netlink_tap_all, list) {
- ret = __netlink_deliver_tap_skb(skb, tmp->dev);
+ tmp = list_first_or_null_rcu(&nn->netlink_tap_all,
+ struct netlink_tap, list);
+ if (!tmp)
+ return;
+
+ if (is_vmalloc_addr(skb->head)) {
+ skb = netlink_to_full_skb(skb, GFP_ATOMIC);
+ if (!skb)
+ return;
+ alloc = true;
+ }
+
+ while (tmp) {
+ next = list_next_or_null_rcu(&nn->netlink_tap_all, &tmp->list,
+ struct netlink_tap, list);
+
+ ret = __netlink_deliver_tap_skb(skb, tmp->dev, alloc, !next);
if (unlikely(ret))
break;
+ tmp = next;
}
}
--
2.16.2
^ permalink raw reply related
* RE: [PATCH net-next 17/22] hv_netvsc: fix return type of ndo_start_xmit function
From: Haiyang Zhang @ 2018-09-20 14:40 UTC (permalink / raw)
To: YueHaibing, davem@davemloft.net, dmitry.tarnyagin@lockless.no,
wg@grandegger.com, mkl@pengutronix.de, michal.simek@xilinx.com,
hsweeten@visionengravers.com, madalin.bucur@nxp.com,
pantelis.antoniou@gmail.com, claudiu.manoil@nxp.com,
leoyang.li@nxp.com, linux@armlinux.org.uk, sammy@sammy.net,
ralf@linux-mips.org, nico@fluxnic.net,
steve.glendinning@shawell.net
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-can@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linuxppc-dev@lists.ozlabs.org, linux-mips@linux-mips.org,
linux-omap@vger.kernel.org, linux-hams@vger.kernel.org,
devel@linuxdriverproject.org, linux-usb@vger.kernel.org,
xen-devel@lists.xenproject.org, dev@openvswitch.org
In-Reply-To: <20180920123306.14772-18-yuehaibing@huawei.com>
> -----Original Message-----
> From: YueHaibing <yuehaibing@huawei.com>
> Sent: Thursday, September 20, 2018 8:33 AM
> To: davem@davemloft.net; dmitry.tarnyagin@lockless.no;
> wg@grandegger.com; mkl@pengutronix.de; michal.simek@xilinx.com;
> hsweeten@visionengravers.com; madalin.bucur@nxp.com;
> pantelis.antoniou@gmail.com; claudiu.manoil@nxp.com; leoyang.li@nxp.com;
> linux@armlinux.org.uk; sammy@sammy.net; ralf@linux-mips.org;
> nico@fluxnic.net; steve.glendinning@shawell.net; f.fainelli@gmail.com;
> grygorii.strashko@ti.com; w-kwok2@ti.com; m-karicheri2@ti.com;
> t.sailer@alumni.ethz.ch; jreuter@yaina.de; KY Srinivasan <kys@microsoft.com>;
> Haiyang Zhang <haiyangz@microsoft.com>; wei.liu2@citrix.com;
> paul.durrant@citrix.com; arvid.brodin@alten.se; pshelar@ovn.org
> Cc: linux-kernel@vger.kernel.org; netdev@vger.kernel.org; linux-
> can@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linuxppc-
> dev@lists.ozlabs.org; linux-mips@linux-mips.org; linux-omap@vger.kernel.org;
> linux-hams@vger.kernel.org; devel@linuxdriverproject.org; linux-
> usb@vger.kernel.org; xen-devel@lists.xenproject.org; dev@openvswitch.org;
> YueHaibing <yuehaibing@huawei.com>
> Subject: [PATCH net-next 17/22] hv_netvsc: fix return type of ndo_start_xmit
> function
>
> The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', which is
> a typedef for an enum type, so make sure the implementation in this driver has
> returns 'netdev_tx_t' value, and change the function return type to netdev_tx_t.
>
> Found by coccinelle.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> ---
> drivers/net/hyperv/netvsc_drv.c | 10 +++++++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
> index 3af6d8d..056c472 100644
> --- a/drivers/net/hyperv/netvsc_drv.c
> +++ b/drivers/net/hyperv/netvsc_drv.c
> @@ -511,7 +511,8 @@ static int netvsc_vf_xmit(struct net_device *net, struct
> net_device *vf_netdev,
> return rc;
> }
>
> -static int netvsc_start_xmit(struct sk_buff *skb, struct net_device *net)
> +static netdev_tx_t
> +netvsc_start_xmit(struct sk_buff *skb, struct net_device *net)
> {
> struct net_device_context *net_device_ctx = netdev_priv(net);
> struct hv_netvsc_packet *packet = NULL; @@ -528,8 +529,11 @@
> static int netvsc_start_xmit(struct sk_buff *skb, struct net_device *net)
> */
> vf_netdev = rcu_dereference_bh(net_device_ctx->vf_netdev);
> if (vf_netdev && netif_running(vf_netdev) &&
> - !netpoll_tx_running(net))
> - return netvsc_vf_xmit(net, vf_netdev, skb);
> + !netpoll_tx_running(net)) {
> + ret = netvsc_vf_xmit(net, vf_netdev, skb);
> + if (ret)
> + return NETDEV_TX_BUSY;
For error case, please just return NETDEV_TX_OK. We are not sure if the
error can go away after retrying, returning NETDEV_TX_BUSY may cause
infinite retry from the upper layer.
Thanks,
- Haiyang
^ permalink raw reply
* [PATCH net-next 0/5] vrf: allow simultaneous service instances in default and other VRFs
From: Mike Manning @ 2018-09-20 8:58 UTC (permalink / raw)
To: netdev
Services currently have to be VRF-aware if they are using an unbound
socket. One cannot have multiple service instances running in the
default and other VRFs for services that are not VRF-aware and listen
on an unbound socket. This is because there is no way of isolating
packets received in the default VRF from those arriving in other VRFs.
This series provides this isolation subject to the existing kernel
parameter net.ipv4.tcp_l3mdev_accept not being set, given that this is
documented as allowing a single service instance to work across all
VRF domains. The functionality applies to UDP & TCP services, for IPv4
and IPv6, in particular adding VRF table handling for IPv6 multicast.
Example of running ssh instances in default and blue VRF:
$ /usr/sbin/sshd -D
$ ip vrf exec vrf-blue /usr/sbin/sshd
$ ss -ta | egrep 'State|ssh'
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 0.0.0.0%vrf-blue:ssh 0.0.0.0:*
LISTEN 0 128 0.0.0.0:ssh 0.0.0.0:*
ESTAB 0 0 192.168.122.220:ssh 192.168.122.1:50282
LISTEN 0 128 [::]%vrf-blue:ssh [::]:*
LISTEN 0 128 [::]:ssh [::]:*
ESTAB 0 0 [3000::2]%vrf-blue:ssh [3000::9]:45896
ESTAB 0 0 [2000::2]:ssh [2000::9]:46398
Dewi Morgan (1):
ipv6: do not drop vrf udp multicast packets
Mike Manning (1):
ipv6: allow link-local and multicast packets inside vrf
Patrick Ruddy (1):
ipv6: add vrf table handling code for ipv6 mcast
Robert Shearman (2):
net: allow binding socket in a VRF when there's an unbound socket
ipv4: Allow sending multicast packets on specific i/f using VRF socket
Documentation/networking/vrf.txt | 9 ++++----
drivers/net/vrf.c | 30 ++++++++++++++++--------
include/net/inet6_hashtables.h | 5 ++--
include/net/inet_hashtables.h | 21 +++++++++++------
include/net/inet_sock.h | 13 +++++++++++
net/core/sock.c | 2 ++
net/ipv4/datagram.c | 2 +-
net/ipv4/inet_connection_sock.c | 13 ++++++++---
net/ipv4/inet_hashtables.c | 34 +++++++++++++++++-----------
net/ipv4/ip_sockglue.c | 3 +++
net/ipv4/ping.c | 2 +-
net/ipv4/raw.c | 6 ++---
net/ipv4/udp.c | 17 ++++++--------
net/ipv6/datagram.c | 5 +++-
net/ipv6/inet6_hashtables.c | 14 +++++-------
net/ipv6/ip6_input.c | 46 +++++++++++++++++++++++++++++++++----
net/ipv6/ip6mr.c | 49 ++++++++++++++++++++++++++++++----------
net/ipv6/ipv6_sockglue.c | 5 +++-
net/ipv6/raw.c | 6 ++---
net/ipv6/udp.c | 22 ++++++++----------
20 files changed, 208 insertions(+), 96 deletions(-)
--
2.11.0
^ 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