* [PATCH v2 5/5] phy: core: clean up unused ethernet specific phy modes
From: Grygorii Strashko @ 2018-11-09 23:47 UTC (permalink / raw)
To: David S. Miller, Kishon Vijay Abraham I, Russell King - ARM Linux
Cc: netdev, Sekhar Nori, linux-kernel, linux-arm-kernel,
Tony Lindgren, linux-amlogic, linux-mediatek, Alexandre Belloni,
Antoine Tenart, Quentin Schulz, Vivek Gautam, Maxime Ripard,
Chen-Yu Tsai, Carlo Caione, Chunfeng Yun, Matthias Brugger,
Manu Gautam, Grygorii Strashko
In-Reply-To: <20181109234755.21687-1-grygorii.strashko@ti.com>
After recent changes PHY_MODE_SGMII, PHY_MODE_2500SGMII, PHY_MODE_QSGMII,
PHY_MODE_10GKR are not used any more and can be removed. Hence - remove
them.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
---
include/linux/phy/phy.h | 4 ----
1 file changed, 4 deletions(-)
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index 02c9ef0..79da05a 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -35,10 +35,6 @@ enum phy_mode {
PHY_MODE_USB_DEVICE_HS,
PHY_MODE_USB_DEVICE_SS,
PHY_MODE_USB_OTG,
- PHY_MODE_SGMII,
- PHY_MODE_2500SGMII,
- PHY_MODE_QSGMII,
- PHY_MODE_10GKR,
PHY_MODE_UFS_HS_A,
PHY_MODE_UFS_HS_B,
PHY_MODE_PCIE,
--
2.10.5
^ permalink raw reply related
* [Patch net-next 03/11] net: hns3: add reset handling for VF when doing PF reset
From: Huazhong Tan @ 2018-11-09 14:07 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm
In-Reply-To: <1541772476-41478-1-git-send-email-tanhuazhong@huawei.com>
When PF performs a function reset, the hardware will reset both PF
and all the VF belong to this PF. Hence, both PF's driver and VF's
driver need to perform corresponding reset operations.
Before PF driver asserting function reset to hardware, it firstly
set up VF's hardware reset status, and inform the VF driver with
HNAE3_VF_PF_FUNC_RESET, then VF driver sets this reset type to
reset_pending and shechule reset task to stop IO and waits for the
hardware reset status to clear. When PF driver has reinitialized the
hardware and is ready to process mailbox from VF, PF driver clears
VF's hardware reset status for VF to continue its reset process.
Also, this patch uses readl_poll_timeout to simplify the hardware reset
status waitting.
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hclge_mbx.h | 6 ++
drivers/net/ethernet/hisilicon/hns3/hnae3.h | 1 +
drivers/net/ethernet/hisilicon/hns3/hns3_enet.h | 3 +-
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 91 ++++++++++++++++++++++
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.h | 1 +
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c | 11 ++-
.../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 39 ++++++----
.../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.h | 10 ++-
.../ethernet/hisilicon/hns3/hns3vf/hclgevf_mbx.c | 4 +-
9 files changed, 146 insertions(+), 20 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hclge_mbx.h b/drivers/net/ethernet/hisilicon/hns3/hclge_mbx.h
index 038326c..3bb313c 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hclge_mbx.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hclge_mbx.h
@@ -85,6 +85,12 @@ struct hclge_mbx_pf_to_vf_cmd {
u16 msg[8];
};
+struct hclge_vf_rst_cmd {
+ u8 dest_vfid;
+ u8 vf_rst;
+ u8 rsv[22];
+};
+
/* used by VF to store the received Async responses from PF */
struct hclgevf_mbx_arq_ring {
#define HCLGE_MBX_MAX_ARQ_MSG_SIZE 8
diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.h b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
index 510dd08..f15f595 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
@@ -125,6 +125,7 @@ enum hnae3_reset_notify_type {
enum hnae3_reset_type {
HNAE3_VF_RESET,
HNAE3_VF_FUNC_RESET,
+ HNAE3_VF_PF_FUNC_RESET,
HNAE3_VF_FULL_RESET,
HNAE3_FUNC_RESET,
HNAE3_CORE_RESET,
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
index 5a38226..bd6ee5c 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
@@ -594,7 +594,8 @@ static inline void hns3_write_reg(void __iomem *base, u32 reg, u32 value)
static inline bool hns3_dev_ongoing_func_reset(struct hnae3_ae_dev *ae_dev)
{
return (ae_dev && (ae_dev->reset_type == HNAE3_FUNC_RESET ||
- ae_dev->reset_type == HNAE3_VF_FUNC_RESET));
+ ae_dev->reset_type == HNAE3_VF_FUNC_RESET ||
+ ae_dev->reset_type == HNAE3_VF_PF_FUNC_RESET));
}
#define hns3_read_dev(a, reg) \
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 77980e5..ba6ea6b 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -2392,6 +2392,55 @@ static int hclge_reset_wait(struct hclge_dev *hdev)
return 0;
}
+static int hclge_set_vf_rst(struct hclge_dev *hdev, int func_id, bool reset)
+{
+ struct hclge_vf_rst_cmd *req;
+ struct hclge_desc desc;
+
+ req = (struct hclge_vf_rst_cmd *)desc.data;
+ hclge_cmd_setup_basic_desc(&desc, HCLGE_OPC_GBL_RST_STATUS, false);
+ req->dest_vfid = func_id;
+
+ if (reset)
+ req->vf_rst = 0x1;
+
+ return hclge_cmd_send(&hdev->hw, &desc, 1);
+}
+
+int hclge_set_all_vf_rst(struct hclge_dev *hdev, bool reset)
+{
+ int i;
+
+ for (i = hdev->num_vmdq_vport + 1; i < hdev->num_alloc_vport; i++) {
+ struct hclge_vport *vport = &hdev->vport[i];
+ int ret;
+
+ /* Send cmd to set/clear VF's FUNC_RST_ING */
+ ret = hclge_set_vf_rst(hdev, vport->vport_id, reset);
+ if (ret) {
+ dev_err(&hdev->pdev->dev,
+ "set vf(%d) rst failded %d!\n",
+ vport->vport_id, ret);
+ return ret;
+ }
+
+ if (!reset)
+ continue;
+
+ /* Inform VF to process the reset.
+ * hclge_inform_reset_assert_to_vf may fail if VF
+ * driver is not loaded.
+ */
+ ret = hclge_inform_reset_assert_to_vf(vport);
+ if (ret)
+ dev_warn(&hdev->pdev->dev,
+ "inform reset to vf(%d) failded %d!\n",
+ vport->vport_id, ret);
+ }
+
+ return 0;
+}
+
int hclge_func_reset_cmd(struct hclge_dev *hdev, int func_id)
{
struct hclge_desc desc;
@@ -2495,12 +2544,31 @@ static void hclge_clear_reset_cause(struct hclge_dev *hdev)
hclge_enable_vector(&hdev->misc_vector, true);
}
+static int hclge_reset_prepare_down(struct hclge_dev *hdev)
+{
+ int ret = 0;
+
+ switch (hdev->reset_type) {
+ case HNAE3_FUNC_RESET:
+ ret = hclge_set_all_vf_rst(hdev, true);
+ break;
+ default:
+ break;
+ }
+
+ return ret;
+}
+
static int hclge_reset_prepare_wait(struct hclge_dev *hdev)
{
int ret = 0;
switch (hdev->reset_type) {
case HNAE3_FUNC_RESET:
+ /* There is no mechanism for PF to know if VF has stopped IO
+ * for now, just wait 100 ms for VF to stop IO
+ */
+ msleep(100);
ret = hclge_func_reset_cmd(hdev, 0);
if (ret) {
dev_err(&hdev->pdev->dev,
@@ -2562,6 +2630,21 @@ static bool hclge_reset_err_handle(struct hclge_dev *hdev, bool is_timeout)
return false;
}
+static int hclge_reset_prepare_up(struct hclge_dev *hdev)
+{
+ int ret = 0;
+
+ switch (hdev->reset_type) {
+ case HNAE3_FUNC_RESET:
+ ret = hclge_set_all_vf_rst(hdev, false);
+ break;
+ default:
+ break;
+ }
+
+ return ret;
+}
+
static void hclge_reset(struct hclge_dev *hdev)
{
struct hnae3_ae_dev *ae_dev = pci_get_drvdata(hdev->pdev);
@@ -2579,6 +2662,10 @@ static void hclge_reset(struct hclge_dev *hdev)
if (ret)
goto err_reset;
+ ret = hclge_reset_prepare_down(hdev);
+ if (ret)
+ goto err_reset;
+
rtnl_lock();
ret = hclge_notify_client(hdev, HNAE3_DOWN_CLIENT);
if (ret)
@@ -2614,6 +2701,10 @@ static void hclge_reset(struct hclge_dev *hdev)
hclge_clear_reset_cause(hdev);
+ ret = hclge_reset_prepare_up(hdev);
+ if (ret)
+ goto err_reset_lock;
+
ret = hclge_notify_client(hdev, HNAE3_UP_CLIENT);
if (ret)
goto err_reset_lock;
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h
index 6df4cfe..8ab974c 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h
@@ -785,6 +785,7 @@ int hclge_buffer_alloc(struct hclge_dev *hdev);
int hclge_rss_init_hw(struct hclge_dev *hdev);
void hclge_rss_indir_init_cfg(struct hclge_dev *hdev);
+int hclge_inform_reset_assert_to_vf(struct hclge_vport *vport);
void hclge_mbx_handler(struct hclge_dev *hdev);
int hclge_reset_tqp(struct hnae3_handle *handle, u16 queue_id);
void hclge_reset_vf_queue(struct hclge_vport *vport, u16 queue_id);
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c
index 013bc7a..f15b807 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c
@@ -81,13 +81,22 @@ static int hclge_send_mbx_msg(struct hclge_vport *vport, u8 *msg, u16 msg_len,
int hclge_inform_reset_assert_to_vf(struct hclge_vport *vport)
{
+ struct hclge_dev *hdev = vport->back;
+ enum hnae3_reset_type reset_type;
u8 msg_data[2];
u8 dest_vfid;
dest_vfid = (u8)vport->vport_id;
+ if (hdev->reset_type == HNAE3_FUNC_RESET)
+ reset_type = HNAE3_VF_PF_FUNC_RESET;
+ else
+ return -EINVAL;
+
+ memcpy(&msg_data[0], &reset_type, sizeof(u16));
+
/* send this requested info to VF */
- return hclge_send_mbx_msg(vport, msg_data, sizeof(u8),
+ return hclge_send_mbx_msg(vport, msg_data, sizeof(msg_data),
HCLGE_MBX_ASSERTING_RESET, dest_vfid);
}
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
index 7a1462a..9405517 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
@@ -2,6 +2,7 @@
// Copyright (c) 2016-2017 Hisilicon Limited.
#include <linux/etherdevice.h>
+#include <linux/iopoll.h>
#include <net/rtnetlink.h>
#include "hclgevf_cmd.h"
#include "hclgevf_main.h"
@@ -1094,24 +1095,28 @@ static int hclgevf_notify_client(struct hclgevf_dev *hdev,
static int hclgevf_reset_wait(struct hclgevf_dev *hdev)
{
-#define HCLGEVF_RESET_WAIT_MS 500
-#define HCLGEVF_RESET_WAIT_CNT 20
- u32 val, cnt = 0;
+#define HCLGEVF_RESET_WAIT_US 20000
+#define HCLGEVF_RESET_WAIT_CNT 2000
+#define HCLGEVF_RESET_WAIT_TIMEOUT_US \
+ (HCLGEVF_RESET_WAIT_US * HCLGEVF_RESET_WAIT_CNT)
+
+ u32 val;
+ int ret;
/* wait to check the hardware reset completion status */
- val = hclgevf_read_dev(&hdev->hw, HCLGEVF_FUN_RST_ING);
- while (hnae3_get_bit(val, HCLGEVF_FUN_RST_ING_B) &&
- (cnt < HCLGEVF_RESET_WAIT_CNT)) {
- msleep(HCLGEVF_RESET_WAIT_MS);
- val = hclgevf_read_dev(&hdev->hw, HCLGEVF_FUN_RST_ING);
- cnt++;
- }
+ val = hclgevf_read_dev(&hdev->hw, HCLGEVF_RST_ING);
+ dev_info(&hdev->pdev->dev, "checking vf resetting status: %x\n", val);
+
+ ret = readl_poll_timeout(hdev->hw.io_base + HCLGEVF_RST_ING, val,
+ !(val & HCLGEVF_RST_ING_BITS),
+ HCLGEVF_RESET_WAIT_US,
+ HCLGEVF_RESET_WAIT_TIMEOUT_US);
/* hardware completion status should be available by this time */
- if (cnt >= HCLGEVF_RESET_WAIT_CNT) {
- dev_warn(&hdev->pdev->dev,
- "could'nt get reset done status from h/w, timeout!\n");
- return -EBUSY;
+ if (ret) {
+ dev_err(&hdev->pdev->dev,
+ "could'nt get reset done status from h/w, timeout!\n");
+ return ret;
}
/* we will wait a bit more to let reset of the stack to complete. This
@@ -1225,6 +1230,10 @@ static enum hnae3_reset_type hclgevf_get_reset_level(struct hclgevf_dev *hdev,
rst_level = HNAE3_VF_FULL_RESET;
clear_bit(HNAE3_VF_FULL_RESET, addr);
clear_bit(HNAE3_VF_FUNC_RESET, addr);
+ } else if (test_bit(HNAE3_VF_PF_FUNC_RESET, addr)) {
+ rst_level = HNAE3_VF_PF_FUNC_RESET;
+ clear_bit(HNAE3_VF_PF_FUNC_RESET, addr);
+ clear_bit(HNAE3_VF_FUNC_RESET, addr);
} else if (test_bit(HNAE3_VF_FUNC_RESET, addr)) {
rst_level = HNAE3_VF_FUNC_RESET;
clear_bit(HNAE3_VF_FUNC_RESET, addr);
@@ -2178,7 +2187,7 @@ static bool hclgevf_get_hw_reset_stat(struct hnae3_handle *handle)
{
struct hclgevf_dev *hdev = hclgevf_ae_get_hdev(handle);
- return !!hclgevf_read_dev(&hdev->hw, HCLGEVF_FUN_RST_ING);
+ return !!hclgevf_read_dev(&hdev->hw, HCLGEVF_RST_ING);
}
static bool hclgevf_ae_dev_resetting(struct hnae3_handle *handle)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.h b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.h
index e6abc4e..2735414 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.h
@@ -34,8 +34,14 @@
#define HCLGEVF_TQP_RESET_TRY_TIMES 10
/* Reset related Registers */
-#define HCLGEVF_FUN_RST_ING 0x20C00
-#define HCLGEVF_FUN_RST_ING_B 0
+#define HCLGEVF_RST_ING 0x20C00
+#define HCLGEVF_FUN_RST_ING_BIT BIT(0)
+#define HCLGEVF_GLOBAL_RST_ING_BIT BIT(5)
+#define HCLGEVF_CORE_RST_ING_BIT BIT(6)
+#define HCLGEVF_IMP_RST_ING_BIT BIT(7)
+#define HCLGEVF_RST_ING_BITS \
+ (HCLGEVF_FUN_RST_ING_BIT | HCLGEVF_GLOBAL_RST_ING_BIT | \
+ HCLGEVF_CORE_RST_ING_BIT | HCLGEVF_IMP_RST_ING_BIT)
#define HCLGEVF_RSS_IND_TBL_SIZE 512
#define HCLGEVF_RSS_SET_BITMAP_MSK 0xffff
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_mbx.c b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_mbx.c
index d3519f7..01a028a 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_mbx.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_mbx.c
@@ -233,6 +233,7 @@ void hclgevf_mbx_handler(struct hclgevf_dev *hdev)
void hclgevf_mbx_async_handler(struct hclgevf_dev *hdev)
{
+ enum hnae3_reset_type reset_type;
u16 link_status;
u16 *msg_q;
u8 duplex;
@@ -267,7 +268,8 @@ void hclgevf_mbx_async_handler(struct hclgevf_dev *hdev)
* has been completely reset. After this stack should
* eventually be re-initialized.
*/
- set_bit(HNAE3_VF_FULL_RESET, &hdev->reset_pending);
+ reset_type = le16_to_cpu(msg_q[1]);
+ set_bit(reset_type, &hdev->reset_pending);
set_bit(HCLGEVF_RESET_PENDING, &hdev->reset_state);
hclgevf_reset_task_schedule(hdev);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next 1/2] dpaa2-eth: defer probe on object allocate
From: Andrew Lunn @ 2018-11-09 14:16 UTC (permalink / raw)
To: Ioana Ciornei
Cc: netdev@vger.kernel.org, davem@davemloft.net,
Ioana Ciocoi Radulescu
In-Reply-To: <VI1PR0402MB28001D2F8046CE09F6EE2433E0C60@VI1PR0402MB2800.eurprd04.prod.outlook.com>
Hi Ioana
> I will send a v2 changing the return value to -ENODEV in case no
> cpus with an affine DPIO is found.
It would be good to review all the cases where IS_ERR_OR_NULL() is
used. It is very easy to get wrong. In fact, it has been suggested
this macro is removed, because it is used wrongly way too often. Try
to avoid it if you can.
Andrew
^ permalink raw reply
* RE: [PATCH net-next 1/2] dpaa2-eth: defer probe on object allocate
From: Ioana Ciornei @ 2018-11-09 14:24 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev@vger.kernel.org, davem@davemloft.net,
Ioana Ciocoi Radulescu
In-Reply-To: <20181109141634.GC1364@lunn.ch>
> Hi Ioana
>
> > I will send a v2 changing the return value to -ENODEV in case no cpus
> > with an affine DPIO is found.
>
> It would be good to review all the cases where IS_ERR_OR_NULL() is used. It is
> very easy to get wrong. In fact, it has been suggested this macro is removed,
> because it is used wrongly way too often. Try to avoid it if you can.
>
The macro is used just 2 times in the dpaa2-eth and both are part of the error path that I've reviewed and will update with a v2 of this patch.
Ioana
^ permalink raw reply
* Re: [PATCH] net: Add trace events for all receive exit points
From: Steven Rostedt @ 2018-11-09 14:24 UTC (permalink / raw)
To: Geneviève Bastien; +Cc: davem, netdev, Mathieu Desnoyers, Ingo Molnar
In-Reply-To: <20181108195648.31846-1-gbastien@versatic.net>
On Thu, 8 Nov 2018 14:56:48 -0500
Geneviève Bastien <gbastien@versatic.net> wrote:
> Trace events are already present for the receive entry points, to indicate
> how the reception entered the stack.
>
> This patch adds the corresponding exit trace events that will bound the
> reception such that all events occurring between the entry and the exit
> can be considered as part of the reception context. This greatly helps
> for dependency and root cause analyses.
>
> Without this, it is impossible to determine whether a sched_wakeup
> event following a netif_receive_skb event is the result of the packet
> reception or a simple coincidence after further processing by the
> thread.
>
> Signed-off-by: Geneviève Bastien <gbastien@versatic.net>
> CC: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> CC: Steven Rostedt <rostedt@goodmis.org>
> CC: Ingo Molnar <mingo@redhat.com>
> CC: David S. Miller <davem@davemloft.net>
> ---
> include/trace/events/net.h | 59 ++++++++++++++++++++++++++++++++++++++
> net/core/dev.c | 30 ++++++++++++++++---
> 2 files changed, 85 insertions(+), 4 deletions(-)
>
> diff --git a/include/trace/events/net.h b/include/trace/events/net.h
> index 00aa72ce0e7c..318307511018 100644
> --- a/include/trace/events/net.h
> +++ b/include/trace/events/net.h
> @@ -117,6 +117,23 @@ DECLARE_EVENT_CLASS(net_dev_template,
> __get_str(name), __entry->skbaddr, __entry->len)
> )
>
> +DECLARE_EVENT_CLASS(net_dev_template_simple,
> +
> + TP_PROTO(struct sk_buff *skb),
> +
> + TP_ARGS(skb),
> +
> + TP_STRUCT__entry(
> + __field(void *, skbaddr)
> + ),
> +
> + TP_fast_assign(
> + __entry->skbaddr = skb;
> + ),
> +
> + TP_printk("skbaddr=%p", __entry->skbaddr)
> +)
> +
> DEFINE_EVENT(net_dev_template, net_dev_queue,
>
> TP_PROTO(struct sk_buff *skb),
> @@ -244,6 +261,48 @@ DEFINE_EVENT(net_dev_rx_verbose_template, netif_rx_ni_entry,
> TP_ARGS(skb)
> );
>
> +DEFINE_EVENT(net_dev_template_simple, napi_gro_frags_exit,
> +
> + TP_PROTO(struct sk_buff *skb),
> +
> + TP_ARGS(skb)
> +);
> +
> +DEFINE_EVENT(net_dev_template_simple, napi_gro_receive_exit,
> +
> + TP_PROTO(struct sk_buff *skb),
> +
> + TP_ARGS(skb)
> +);
> +
> +DEFINE_EVENT(net_dev_template_simple, netif_receive_skb_exit,
> +
> + TP_PROTO(struct sk_buff *skb),
> +
> + TP_ARGS(skb)
> +);
> +
> +DEFINE_EVENT(net_dev_template_simple, netif_receive_skb_list_exit,
> +
> + TP_PROTO(struct sk_buff *skb),
> +
> + TP_ARGS(skb)
> +);
> +
> +DEFINE_EVENT(net_dev_template_simple, netif_rx_exit,
> +
> + TP_PROTO(struct sk_buff *skb),
> +
> + TP_ARGS(skb)
> +);
> +
> +DEFINE_EVENT(net_dev_template_simple, netif_rx_ni_exit,
> +
> + TP_PROTO(struct sk_buff *skb),
> +
> + TP_ARGS(skb)
> +);
> +
> #endif /* _TRACE_NET_H */
>
> /* This part must be outside protection */
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 0ffcbdd55fa9..e670ca27e829 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -4520,9 +4520,14 @@ static int netif_rx_internal(struct sk_buff *skb)
>
> int netif_rx(struct sk_buff *skb)
> {
> + int ret;
> +
> trace_netif_rx_entry(skb);
>
> - return netif_rx_internal(skb);
> + ret = netif_rx_internal(skb);
> + trace_netif_rx_exit(skb);
> +
> + return ret;
Pretty much all the trace events have a "ret" passed by them, why not
record the ret in the trace event as well?
trace_netif_rx_exit(skb, ret);
> }
> EXPORT_SYMBOL(netif_rx);
>
> @@ -4537,6 +4542,7 @@ int netif_rx_ni(struct sk_buff *skb)
> if (local_softirq_pending())
> do_softirq();
> preempt_enable();
> + trace_netif_rx_ni_exit(skb);
>
> return err;
> }
> @@ -5222,9 +5228,14 @@ static void netif_receive_skb_list_internal(struct list_head *head)
> */
> int netif_receive_skb(struct sk_buff *skb)
> {
> + int ret;
> +
> trace_netif_receive_skb_entry(skb);
>
> - return netif_receive_skb_internal(skb);
> + ret = netif_receive_skb_internal(skb);
> + trace_netif_receive_skb_exit(skb);
> +
> + return ret;
> }
> EXPORT_SYMBOL(netif_receive_skb);
>
> @@ -5247,6 +5258,8 @@ void netif_receive_skb_list(struct list_head *head)
> list_for_each_entry(skb, head, list)
> trace_netif_receive_skb_list_entry(skb);
> netif_receive_skb_list_internal(head);
> + list_for_each_entry(skb, head, list)
> + trace_netif_receive_skb_list_exit(skb);
This needs:
if (trace_netif_receive_skb_list_exit_enabled()) {
list_for_each_entry(skb, head, list)
trace_netif_receive_skb_list_exit(skb);
}
Because we should not be doing the list walk if the trace event is not
enabled. The trace_<event>_enabled() call uses jump labels, so by
default it is a nop that just skips the code completely, and when its
enabled it is a direct jump to the list walk.
-- Steve
> }
> EXPORT_SYMBOL(netif_receive_skb_list);
>
> @@ -5634,12 +5647,17 @@ static gro_result_t napi_skb_finish(gro_result_t ret, struct sk_buff *skb)
>
> gro_result_t napi_gro_receive(struct napi_struct *napi, struct sk_buff *skb)
> {
> + gro_result_t ret;
> +
> skb_mark_napi_id(skb, napi);
> trace_napi_gro_receive_entry(skb);
>
> skb_gro_reset_offset(skb);
>
> - return napi_skb_finish(dev_gro_receive(napi, skb), skb);
> + ret = napi_skb_finish(dev_gro_receive(napi, skb), skb);
> + trace_napi_gro_receive_exit(skb);
> +
> + return ret;
> }
> EXPORT_SYMBOL(napi_gro_receive);
>
> @@ -5753,6 +5771,7 @@ static struct sk_buff *napi_frags_skb(struct napi_struct *napi)
>
> gro_result_t napi_gro_frags(struct napi_struct *napi)
> {
> + gro_result_t ret;
> struct sk_buff *skb = napi_frags_skb(napi);
>
> if (!skb)
> @@ -5760,7 +5779,10 @@ gro_result_t napi_gro_frags(struct napi_struct *napi)
>
> trace_napi_gro_frags_entry(skb);
>
> - return napi_frags_finish(napi, skb, dev_gro_receive(napi, skb));
> + ret = napi_frags_finish(napi, skb, dev_gro_receive(napi, skb));
> + trace_napi_gro_frags_exit(skb);
> +
> + return ret;
> }
> EXPORT_SYMBOL(napi_gro_frags);
>
^ permalink raw reply
* [PATCH net-next] udp6: cleanup stats accounting in recvmsg()
From: Paolo Abeni @ 2018-11-09 14:52 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller
In the udp6 code path, we needed multiple tests to select the correct
mib to be updated. Since we touch at least a counter at each iteration,
it's convenient to use the recently introduced __UDPX_MIB() helper once
and remove some code duplication.
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
---
net/ipv6/udp.c | 32 +++++++-------------------------
1 file changed, 7 insertions(+), 25 deletions(-)
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 0c0cb1611aef..dde51fc7ac16 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -326,6 +326,7 @@ int udpv6_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,
int err;
int is_udplite = IS_UDPLITE(sk);
bool checksum_valid = false;
+ struct udp_mib *mib;
int is_udp4;
if (flags & MSG_ERRQUEUE)
@@ -349,6 +350,7 @@ int udpv6_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,
msg->msg_flags |= MSG_TRUNC;
is_udp4 = (skb->protocol == htons(ETH_P_IP));
+ mib = __UDPX_MIB(sk, is_udp4);
/*
* If checksum is needed at all, try to do it while copying the
@@ -377,24 +379,13 @@ int udpv6_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,
if (unlikely(err)) {
if (!peeked) {
atomic_inc(&sk->sk_drops);
- if (is_udp4)
- UDP_INC_STATS(sock_net(sk), UDP_MIB_INERRORS,
- is_udplite);
- else
- UDP6_INC_STATS(sock_net(sk), UDP_MIB_INERRORS,
- is_udplite);
+ SNMP_INC_STATS(mib, UDP_MIB_INERRORS);
}
kfree_skb(skb);
return err;
}
- if (!peeked) {
- if (is_udp4)
- UDP_INC_STATS(sock_net(sk), UDP_MIB_INDATAGRAMS,
- is_udplite);
- else
- UDP6_INC_STATS(sock_net(sk), UDP_MIB_INDATAGRAMS,
- is_udplite);
- }
+ if (!peeked)
+ SNMP_INC_STATS(mib, UDP_MIB_INDATAGRAMS);
sock_recv_ts_and_drops(msg, sk, skb);
@@ -443,17 +434,8 @@ int udpv6_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,
csum_copy_err:
if (!__sk_queue_drop_skb(sk, &udp_sk(sk)->reader_queue, skb, flags,
udp_skb_destructor)) {
- if (is_udp4) {
- UDP_INC_STATS(sock_net(sk),
- UDP_MIB_CSUMERRORS, is_udplite);
- UDP_INC_STATS(sock_net(sk),
- UDP_MIB_INERRORS, is_udplite);
- } else {
- UDP6_INC_STATS(sock_net(sk),
- UDP_MIB_CSUMERRORS, is_udplite);
- UDP6_INC_STATS(sock_net(sk),
- UDP_MIB_INERRORS, is_udplite);
- }
+ SNMP_INC_STATS(mib, UDP_MIB_CSUMERRORS);
+ SNMP_INC_STATS(mib, UDP_MIB_INERRORS);
}
kfree_skb(skb);
--
2.17.2
^ permalink raw reply related
* Re: [Patch net-next 00/11] add code optimization for VF reset and some new reset feature
From: David Miller @ 2018-11-10 0:47 UTC (permalink / raw)
To: tanhuazhong; +Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm
In-Reply-To: <1541772476-41478-1-git-send-email-tanhuazhong@huawei.com>
From: Huazhong Tan <tanhuazhong@huawei.com>
Date: Fri, 9 Nov 2018 22:07:45 +0800
> Currently hardware supports below reset:
> 1. VF reset: triggered by sending cmd to IMP(Integrated Management
> Processor). Only reset specific VF function and do not affect
> other PF or VF.
> 2. PF reset: triggered by sending cmd to IMP. Only reset specific PF
> and it's VF.
> 3. PF FLR: triggered by PCIe subsystem. Only reset specific PF and
> it's VF.
> 4. VF FLR: triggered by PCIe subsystem. Only reset specific VF function
> and do not affect other PF or VF.
> 5. Core reset: triggered by writing to register. Reset most hardware
> unit, such as SSU, which affects all the PF and VF.
> 6. Global reset: triggered by writing to register. Reset all hardware
> unit, which affects all the PF and VF.
> 7. IMP reset: triggered by IMU(Intelligent Management Unit) when
> IMP is not longer feeding IMU's watchdog. IMU will reload the IMP
> firmware and IMP will perform global reset after firmware reloading,
> which affects all the PF and VF.
>
> Current driver only support PF/VF reset, incomplete core and global
> reset(lacking the vf reset handling). So this patchset adds complete
> reset support in hns3 driver.
>
> Also, this patchset contains some optimization related to reset.
Series applied, thank you.
^ permalink raw reply
* [PATCH net-next v2 0/2] dpaa2-eth: defer probe on object allocate
From: Ioana Ciornei @ 2018-11-09 15:26 UTC (permalink / raw)
To: netdev@vger.kernel.org, davem@davemloft.net, andrew@lunn.ch
Cc: Ioana Ciocoi Radulescu, Ioana Ciornei
Allocatable objects on the fsl-mc bus may be probed by the fsl_mc_allocator
after the first attempts of other drivers to use them. Defer the probe when
this situation happens.
Changes in v2:
- proper handling of IS_ERR_OR_NULL
Ioana Ciornei (2):
dpaa2-eth: defer probe on object allocate
dpaa2-ptp: defer probe when portal allocation failed
drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c | 32 ++++++++++++++++--------
drivers/net/ethernet/freescale/dpaa2/dpaa2-ptp.c | 5 +++-
2 files changed, 26 insertions(+), 11 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH net-next v2 1/2] dpaa2-eth: defer probe on object allocate
From: Ioana Ciornei @ 2018-11-09 15:26 UTC (permalink / raw)
To: netdev@vger.kernel.org, davem@davemloft.net, andrew@lunn.ch
Cc: Ioana Ciocoi Radulescu, Ioana Ciornei
In-Reply-To: <1541777182-9135-1-git-send-email-ioana.ciornei@nxp.com>
The fsl_mc_object_allocate function can fail because not all allocatable
objects are probed by the fsl_mc_allocator at the call time. Defer the
dpaa2-eth probe when this happens.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
---
Changes in v2:
- proper handling of IS_ERR_OR_NULL
drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c | 32 ++++++++++++++++--------
1 file changed, 22 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c b/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
index 88f7acc..bdfb13b 100644
--- a/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
+++ b/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
@@ -1434,8 +1434,11 @@ static struct fsl_mc_device *setup_dpcon(struct dpaa2_eth_priv *priv)
err = fsl_mc_object_allocate(to_fsl_mc_device(dev),
FSL_MC_POOL_DPCON, &dpcon);
if (err) {
- dev_info(dev, "Not enough DPCONs, will go on as-is\n");
- return NULL;
+ if (err == -ENXIO)
+ err = -EPROBE_DEFER;
+ else
+ dev_info(dev, "Not enough DPCONs, will go on as-is\n");
+ return ERR_PTR(err);
}
err = dpcon_open(priv->mc_io, 0, dpcon->obj_desc.id, &dpcon->mc_handle);
@@ -1493,8 +1496,10 @@ static void free_dpcon(struct dpaa2_eth_priv *priv,
return NULL;
channel->dpcon = setup_dpcon(priv);
- if (!channel->dpcon)
+ if (IS_ERR_OR_NULL(channel->dpcon)) {
+ err = PTR_ERR(channel->dpcon);
goto err_setup;
+ }
err = dpcon_get_attributes(priv->mc_io, 0, channel->dpcon->mc_handle,
&attr);
@@ -1513,7 +1518,7 @@ static void free_dpcon(struct dpaa2_eth_priv *priv,
free_dpcon(priv, channel->dpcon);
err_setup:
kfree(channel);
- return NULL;
+ return ERR_PTR(err);
}
static void free_channel(struct dpaa2_eth_priv *priv,
@@ -1547,10 +1552,11 @@ static int setup_dpio(struct dpaa2_eth_priv *priv)
for_each_online_cpu(i) {
/* Try to allocate a channel */
channel = alloc_channel(priv);
- if (!channel) {
- dev_info(dev,
- "No affine channel for cpu %d and above\n", i);
- err = -ENODEV;
+ if (IS_ERR_OR_NULL(channel)) {
+ err = PTR_ERR(channel);
+ if (err != -EPROBE_DEFER)
+ dev_info(dev,
+ "No affine channel for cpu %d and above\n", i);
goto err_alloc_ch;
}
@@ -1608,9 +1614,12 @@ static int setup_dpio(struct dpaa2_eth_priv *priv)
err_service_reg:
free_channel(priv, channel);
err_alloc_ch:
+ if (err == -EPROBE_DEFER)
+ return err;
+
if (cpumask_empty(&priv->dpio_cpumask)) {
dev_err(dev, "No cpu with an affine DPIO/DPCON\n");
- return err;
+ return -ENODEV;
}
dev_info(dev, "Cores %*pbl available for processing ingress traffic\n",
@@ -1732,7 +1741,10 @@ static int setup_dpbp(struct dpaa2_eth_priv *priv)
err = fsl_mc_object_allocate(to_fsl_mc_device(dev), FSL_MC_POOL_DPBP,
&dpbp_dev);
if (err) {
- dev_err(dev, "DPBP device allocation failed\n");
+ if (err == -ENXIO)
+ err = -EPROBE_DEFER;
+ else
+ dev_err(dev, "DPBP device allocation failed\n");
return err;
}
--
1.9.1
^ permalink raw reply related
* [PATCH net-next v2 2/2] dpaa2-ptp: defer probe when portal allocation failed
From: Ioana Ciornei @ 2018-11-09 15:26 UTC (permalink / raw)
To: netdev@vger.kernel.org, davem@davemloft.net, andrew@lunn.ch
Cc: Ioana Ciocoi Radulescu, Ioana Ciornei
In-Reply-To: <1541777182-9135-1-git-send-email-ioana.ciornei@nxp.com>
The fsl_mc_portal_allocate can fail when the requested MC portals are
not yet probed by the fsl_mc_allocator. In this situation, the driver
should defer the probe.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
---
Changes in v2:
- none
drivers/net/ethernet/freescale/dpaa2/dpaa2-ptp.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/dpaa2/dpaa2-ptp.c b/drivers/net/ethernet/freescale/dpaa2/dpaa2-ptp.c
index 84b942b..9b150db 100644
--- a/drivers/net/ethernet/freescale/dpaa2/dpaa2-ptp.c
+++ b/drivers/net/ethernet/freescale/dpaa2/dpaa2-ptp.c
@@ -140,7 +140,10 @@ static int dpaa2_ptp_probe(struct fsl_mc_device *mc_dev)
err = fsl_mc_portal_allocate(mc_dev, 0, &mc_dev->mc_io);
if (err) {
- dev_err(dev, "fsl_mc_portal_allocate err %d\n", err);
+ if (err == -ENXIO)
+ err = -EPROBE_DEFER;
+ else
+ dev_err(dev, "fsl_mc_portal_allocate err %d\n", err);
goto err_exit;
}
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v4 bpf-next 2/7] libbpf: cleanup after partial failure in bpf_object__pin
From: Stanislav Fomichev @ 2018-11-09 15:41 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, linux-kselftest, ast, daniel, shuah, quentin.monnet, guro,
jiong.wang, sdf, bhole_prashant_q7, john.fastabend, jbenc,
treeze.taeung, yhs, osk, sandipan
In-Reply-To: <20181108193705.2933c2bc@cakuba.netronome.com>
On 11/08, Jakub Kicinski wrote:
> On Thu, 8 Nov 2018 16:22:08 -0800, Stanislav Fomichev wrote:
> > + for (map = bpf_map__prev(map, obj);
> > + map != NULL;
> > + map = bpf_map__prev(map, obj)) {
>
> nit pick: if you need to respin all these for loops on error paths could
> have been more concise while loops
Agreed with everything, will address this one and the other comments in v5.
Thank you for another thorough review!
^ permalink raw reply
* Re: [PATCH v4 bpf-next 5/7] bpftool: add loadall command
From: Stanislav Fomichev @ 2018-11-09 15:42 UTC (permalink / raw)
To: Quentin Monnet
Cc: netdev, linux-kselftest, ast, daniel, shuah, jakub.kicinski, guro,
jiong.wang, sdf, bhole_prashant_q7, john.fastabend, jbenc,
treeze.taeung, yhs, osk, sandipan
In-Reply-To: <30359d0f-40c0-27c9-cd4e-bba60c6cb138@netronome.com>
On 11/09, Quentin Monnet wrote:
> 2018-11-08 16:22 UTC-0800 ~ Stanislav Fomichev <sdf@fomichev.me>
> > From: Stanislav Fomichev <sdf@google.com>
> >
> > This patch adds new *loadall* command which slightly differs from the
> > existing *load*. *load* command loads all programs from the obj file,
> > but pins only the first programs. *loadall* pins all programs from the
> > obj file under specified directory.
> >
> > The intended usecase is flow_dissector, where we want to load a bunch
> > of progs, pin them all and after that construct a jump table.
> >
> > Signed-off-by: Stanislav Fomichev <sdf@google.com>
> > ---
> > .../bpftool/Documentation/bpftool-prog.rst | 14 +++-
> > tools/bpf/bpftool/bash-completion/bpftool | 4 +-
> > tools/bpf/bpftool/common.c | 31 ++++----
> > tools/bpf/bpftool/main.h | 1 +
> > tools/bpf/bpftool/prog.c | 74 ++++++++++++++-----
> > 5 files changed, 82 insertions(+), 42 deletions(-)
> >
> > diff --git a/tools/bpf/bpftool/Documentation/bpftool-prog.rst b/tools/bpf/bpftool/Documentation/bpftool-prog.rst
> > index ac4e904b10fb..d943d9b67a1d 100644
> > --- a/tools/bpf/bpftool/Documentation/bpftool-prog.rst
> > +++ b/tools/bpf/bpftool/Documentation/bpftool-prog.rst
>
> > @@ -24,7 +25,7 @@ MAP COMMANDS
> > | **bpftool** **prog dump xlated** *PROG* [{**file** *FILE* | **opcodes** | **visual**}]
> > | **bpftool** **prog dump jited** *PROG* [{**file** *FILE* | **opcodes**}]
> > | **bpftool** **prog pin** *PROG* *FILE*
> > -| **bpftool** **prog load** *OBJ* *FILE* [**type** *TYPE*] [**map** {**idx** *IDX* | **name** *NAME*} *MAP*] [**dev** *NAME*]
> > +| **bpftool** **prog { load | loadall }** *OBJ* *FILE* [**type** *TYPE*] [**map** {**idx** *IDX* | **name** *NAME*} *MAP*] [**dev** *NAME*]
> > | **bpftool** **prog attach** *PROG* *ATTACH_TYPE* *MAP*
> > | **bpftool** **prog detach** *PROG* *ATTACH_TYPE* *MAP*
> > | **bpftool** **prog help**
> > @@ -79,8 +80,13 @@ DESCRIPTION
> > contain a dot character ('.'), which is reserved for future
> > extensions of *bpffs*.
> >
> > - **bpftool prog load** *OBJ* *FILE* [**type** *TYPE*] [**map** {**idx** *IDX* | **name** *NAME*} *MAP*] [**dev** *NAME*]
> > - Load bpf program from binary *OBJ* and pin as *FILE*.
> > + **bpftool prog { load | loadall }** *OBJ* *FILE* [**type** *TYPE*] [**map** {**idx** *IDX* | **name** *NAME*} *MAP*] [**dev** *NAME*]
> > + Load bpf program(s) from binary *OBJ* and pin as *FILE*.
> > + Both **bpftool prog load** and **bpftool prog loadall** load
> > + all maps and programs from the *OBJ* and differ only in
> > + pinning. **load** pins only the first program from the *OBJ*
> > + as *FILE*. **loadall** pins all programs from the *OBJ*
> > + under *FILE* directory.
> > **type** is optional, if not specified program type will be
> > inferred from section names.
> > By default bpftool will create new maps as declared in the ELF
>
> Thanks a lot for all the changes! The series looks really good to me
> now. The last nit I might have is that we could maybe replace "FILE"
> with "PATH" (as it can now be a directory), in the doc an below. No need
> to respin just for this, though.
Agreed, makes sense, will do another respin to address Jakub's comments
anyway. Thanks for a review!
> > @@ -1035,7 +1067,8 @@ static int do_help(int argc, char **argv)
> > " %s %s dump xlated PROG [{ file FILE | opcodes | visual }]\n"
> > " %s %s dump jited PROG [{ file FILE | opcodes }]\n"
> > " %s %s pin PROG FILE\n"
> > - " %s %s load OBJ FILE [type TYPE] [dev NAME] \\\n"
> > + " %s %s { load | loadall } OBJ FILE \\\n"
> > + " [type TYPE] [dev NAME] \\\n"
> > " [map { idx IDX | name NAME } MAP]\n"
> > " %s %s attach PROG ATTACH_TYPE MAP\n"
> > " %s %s detach PROG ATTACH_TYPE MAP\n"
^ permalink raw reply
* Re: [PATCH iproute2] bridge: fdb: remove redundant dev string in show output
From: Stephen Hemminger @ 2018-11-09 15:54 UTC (permalink / raw)
To: Phil Sutter; +Cc: Roopa Prabhu, netdev, nikolay, dsahern
In-Reply-To: <20181108093505.GK6440@orbyte.nwl.cc>
On Thu, 8 Nov 2018 10:35:05 +0100
Phil Sutter <phil@nwl.cc> wrote:
> Hi Roopa,
>
> On Wed, Nov 07, 2018 at 03:14:09PM -0800, Roopa Prabhu wrote:
> > From: Roopa Prabhu <roopa@cumulusnetworks.com>
> >
> > After commit 4abb8c723a64 ("bridge: fdb: Fix for missing
> > keywords in non-JSON output"), I am seeing a double print for dev
> > in bridge fdb show. eg:
> > "44:38:39:00:6a:82 dev dev bridge vlan 1 master bridge permanent"
> >
> > this patch removes the redundant print.
> >
> > Fixes: 4abb8c723a64 ("bridge: fdb: Fix for missing keywords in non-JSON output")
Applied.
^ permalink raw reply
* Re: Should the bridge learn from frames with link local destination MAC address?
From: Stephen Hemminger @ 2018-11-09 16:00 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Roopa Prabhu, Nikolay Aleksandrov, netdev, Florian Fainelli
In-Reply-To: <20181109032443.GA23331@lunn.ch>
On Fri, 9 Nov 2018 04:24:43 +0100
Andrew Lunn <andrew@lunn.ch> wrote:
> Hi Roopa, Nikolay
>
> br_handle_frame() looks out for frames with a destination MAC
> addresses with is Ethernet link local, those which fit
> 01-80-C2-00-00-XX. It does not normally forward these, but it will
> deliver them locally.
>
> Should the bridge perform learning on such frames?
>
> I've got a setup with two bridges connected together with multiple
> links between them. STP has done its thing, and blocked one of the
> ports to solve the loop.
>
> host0 host1
> +-----------------+ +-----------------+
> | lan0 forwarding |-----| lan0 forwarding |
> | | | |
> | lan1 forwarding |-----| lan1 blocked |
> +-----------------+ +-----------------+
>
> I have LLDP running on both system, and they are sending out periodic
> frames on each port.
>
> Now, lan0 and lan1 on host1 use the same MAC address. So i see the
> MAC address bouncing between ports because of the LLDP packets.
>
> # bridge monitor
> 00:26:55:d2:27:a8 dev lan1 master br0
> 00:26:55:d2:27:a8 dev lan0 master br0
> 00:26:55:d2:27:a8 dev lan1 master br0
> 00:26:55:d2:27:a8 dev lan0 master br0
> 00:26:55:d2:27:a8 dev lan1 master br0
>
> This then results in normal traffic from host0 to host1 being sent to
> the blocked port for some of the time.
>
> LLDP is using 01-80-C2-00-00-0E, a link local MAC address. If the
> bridge did not learn on such frames, i think this setup would
> work. The bridge would learn from ARP, IP etc, coming from the
> forwarding port of host1, and the blocked port would be ignored.
>
> I've tried a similar setup with a hardware switch, Marvell 6352. It
> never seems to learn from such frames.
>
> Thanks
> Andrew
I agree with your analysis. A properly operating 802 compliant bridge
should not learn link local addresses. But changing that in Linux bridge
would probably break some users. There is already a hack to forward link
local frames. There are many usages of Linux vswitch where this behavior
might be a problem:
1. a container or VM hub
2. bump in the wire filter
3. L2 nat etc.
So what ever you decide it has to be optional and unfortunately default
to off.
^ permalink raw reply
* Re: bring back IPX and NCPFS, please!
From: Stephen Hemminger @ 2018-11-09 16:01 UTC (permalink / raw)
To: Johannes C. Schulz; +Cc: netdev
In-Reply-To: <CAFfL_owvKC2rBz6U=aomgbJzKLu-x+RFDSwMQKKj8=DJ5Mdm=Q@mail.gmail.com>
On Fri, 9 Nov 2018 14:23:27 +0100
"Johannes C. Schulz" <enzephalon76@googlemail.com> wrote:
> Hello all!
>
> I like to please you to bring back IPX and NCPFS modules to the kernel.
> Whyever my admins using Novell-shares on our network which I'm not be
> able to use anymore - I'm forced to use cifs instead (and the admins
> will kill the cifs-shares in some time), because my kernel (4.18) does
> not have support for ncpfs anymore.
> Maybe we at my work are not enough people that just for us this
> modules will come back, but maybe out there are other people.
> Thank you.
Are you willing to sign up to maintain it, test it and fix bugs?
^ permalink raw reply
* Re: [PATCH iproute2] bridge: fdb: remove redundant dev string in show output
From: Stephen Hemminger @ 2018-11-09 16:05 UTC (permalink / raw)
To: Roopa Prabhu; +Cc: netdev, phil, nikolay, dsahern
In-Reply-To: <1541632449-9993-1-git-send-email-roopa@cumulusnetworks.com>
On Wed, 7 Nov 2018 15:14:09 -0800
Roopa Prabhu <roopa@cumulusnetworks.com> wrote:
> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>
> After commit 4abb8c723a64 ("bridge: fdb: Fix for missing
> keywords in non-JSON output"), I am seeing a double print for dev
> in bridge fdb show. eg:
> "44:38:39:00:6a:82 dev dev bridge vlan 1 master bridge permanent"
>
> this patch removes the redundant print.
>
> Fixes: 4abb8c723a64 ("bridge: fdb: Fix for missing keywords in non-JSON output")
> CC: Phil Sutter <phil@nwl.cc>
> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH iproute2] man: ss.8: break and indent long line
From: Stephen Hemminger @ 2018-11-09 16:06 UTC (permalink / raw)
To: Luca Boccassi; +Cc: netdev, dsahern
In-Reply-To: <20181102132748.22178-1-bluca@debian.org>
On Fri, 2 Nov 2018 13:27:48 +0000
Luca Boccassi <bluca@debian.org> wrote:
> Fixes groff warning:
> ss.8 92: warning [p 2, 2.8i]: can't break line
>
> And makes the line also more readable.
>
> Signed-off-by: Luca Boccassi <bluca@debian.org>
Applied
^ permalink raw reply
* Re: [PATCH iproute2] Fix warning in tc-skbprio.8 manpage
From: Stephen Hemminger @ 2018-11-09 16:06 UTC (permalink / raw)
To: Luca Boccassi; +Cc: netdev, dsahern
In-Reply-To: <20181102105741.25381-1-bluca@debian.org>
On Fri, 2 Nov 2018 10:57:41 +0000
Luca Boccassi <bluca@debian.org> wrote:
> ". If" gets interpreted as a macro, so move the period to the previous
> line:
>
> 33: warning: macro `If' not defined
>
> Fixes: 141b55f8544e ("Add SKB Priority qdisc support in tc(8)")
>
> Signed-off-by: Luca Boccassi <bluca@debian.org>
Applied
^ permalink raw reply
* Re: [PATCH iproute2 1/2] testsuite: build generate_nlmsg with QUIET_CC
From: Stephen Hemminger @ 2018-11-09 16:08 UTC (permalink / raw)
To: Luca Boccassi; +Cc: netdev, dsahern
In-Reply-To: <20181102123544.13000-1-bluca@debian.org>
On Fri, 2 Nov 2018 12:35:43 +0000
Luca Boccassi <bluca@debian.org> wrote:
> Follow the standard pattern, and respect user's verbosity setting.
>
> Signed-off-by: Luca Boccassi <bluca@debian.org>
Both applied
^ permalink raw reply
* Re: bring back IPX and NCPFS, please!
From: Willy Tarreau @ 2018-11-09 16:09 UTC (permalink / raw)
To: Johannes C. Schulz; +Cc: netdev
In-Reply-To: <CAFfL_owvKC2rBz6U=aomgbJzKLu-x+RFDSwMQKKj8=DJ5Mdm=Q@mail.gmail.com>
On Fri, Nov 09, 2018 at 02:23:27PM +0100, Johannes C. Schulz wrote:
> Hello all!
>
> I like to please you to bring back IPX and NCPFS modules to the kernel.
> Whyever my admins using Novell-shares on our network which I'm not be
> able to use anymore - I'm forced to use cifs instead (and the admins
> will kill the cifs-shares in some time), because my kernel (4.18) does
> not have support for ncpfs anymore.
> Maybe we at my work are not enough people that just for us this
> modules will come back, but maybe out there are other people.
> Thank you.
Well, like any code, it requires time and skills. If nobody with the
required skills is available for this anymore, there's no way you'll
get a feature back. However you could always step up to maintain it
yourself if you have the time and are willing to develop your own
skills at it. It's how maintainers change over time for certain parts
of the system, so you have an opportunity here.
Just my two cents,
Willy
^ permalink raw reply
* Re: [iproute2 PATCH v2] tc: flower: Classify packets based port ranges
From: Stephen Hemminger @ 2018-11-09 16:11 UTC (permalink / raw)
To: Amritha Nambiar
Cc: netdev, jakub.kicinski, sridhar.samudrala, jhs, xiyou.wangcong,
jiri
In-Reply-To: <154162577012.57835.17845635441983538034.stgit@anamhost.jf.intel.com>
On Wed, 07 Nov 2018 13:22:50 -0800
Amritha Nambiar <amritha.nambiar@intel.com> wrote:
> Added support for filtering based on port ranges.
>
> Example:
> 1. Match on a port range:
> -------------------------
> $ tc filter add dev enp4s0 protocol ip parent ffff:\
> prio 1 flower ip_proto tcp dst_port range 20-30 skip_hw\
> action drop
>
> $ tc -s filter show dev enp4s0 parent ffff:
> filter protocol ip pref 1 flower chain 0
> filter protocol ip pref 1 flower chain 0 handle 0x1
> eth_type ipv4
> ip_proto tcp
> dst_port range 20-30
> skip_hw
> not_in_hw
> action order 1: gact action drop
> random type none pass val 0
> index 1 ref 1 bind 1 installed 85 sec used 3 sec
> Action statistics:
> Sent 460 bytes 10 pkt (dropped 10, overlimits 0 requeues 0)
> backlog 0b 0p requeues 0
>
> 2. Match on IP address and port range:
> --------------------------------------
> $ tc filter add dev enp4s0 protocol ip parent ffff:\
> prio 1 flower dst_ip 192.168.1.1 ip_proto tcp dst_port range 100-200\
> skip_hw action drop
>
> $ tc -s filter show dev enp4s0 parent ffff:
> filter protocol ip pref 1 flower chain 0 handle 0x2
> eth_type ipv4
> ip_proto tcp
> dst_ip 192.168.1.1
> dst_port range 100-200
> skip_hw
> not_in_hw
> action order 1: gact action drop
> random type none pass val 0
> index 2 ref 1 bind 1 installed 58 sec used 2 sec
> Action statistics:
> Sent 920 bytes 20 pkt (dropped 20, overlimits 0 requeues 0)
> backlog 0b 0p requeues 0
>
> v2:
> Addressed Jiri's comment to sync output format with input
>
> Signed-off-by: Amritha Nambiar <amritha.nambiar@intel.com>
Please resubmit to iproute2-next after the UAPI changes have been accepted
into kernel (net-next).
^ permalink raw reply
* Re: [PATCH iproute2] tc: f_u32: allow skip_hw and skip_sw flags to be last
From: Stephen Hemminger @ 2018-11-09 16:13 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: dsahern, netdev, oss-drivers
In-Reply-To: <20181106032327.9470-1-jakub.kicinski@netronome.com>
On Mon, 5 Nov 2018 19:23:27 -0800
Jakub Kicinski <jakub.kicinski@netronome.com> wrote:
> u32 uses NEXT_ARG() incorrectly when parsing skip_hw and skip_sw
> flags. NEXT_ARG() ensures there is another argument on the command
> line, and is used in handling <keyword> <value> syntax to move past
> <keyword> and ensure there is a <value> to read.
>
> Commit 5e5b3008d1fb ("tc: f_u32: Add support for skip_hw and skip_sw
> flags") seems to have copy pasted the handling from the previous
> command - "police", which needs an extra parameter and is kind of
> special due to the use of parse_police() helper.
>
> The combination of NEXT_ARG() and continue worked fine as long as
> skip_sw/skip_hw wasn't last, e.g.:
>
> $ tc filter add dev dummy0 ingress prio 101 protocol ipv6 \
> u32 match ip6 priority 0xa0 0xe0 skip_hw action pass
>
> But would fail if it was last:
>
> $ tc filter add dev dummy0 ingress prio 101 protocol ipv6 \
> u32 match ip6 priority 0xa0 0xe0 flowid :1 skip_hw
> Command line is not complete. Try option "help"
>
> Remove the NEXT_ARG()s and the continues, and let the argc--; argv++;
> at the end of the loop do its job.
>
> Fixes: 5e5b3008d1fb ("tc: f_u32: Add support for skip_hw and skip_sw flags")
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Applied
^ permalink raw reply
* Re: [PATCH mlx5-next 02/10] IB/mlx5: Avoid hangs due to a missing completion
From: Leon Romanovsky @ 2018-11-09 16:17 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Doug Ledford, RDMA mailing list, Artemy Kovalyov, Majd Dibbiny,
Moni Shoua, Saeed Mahameed, linux-netdev
In-Reply-To: <20181108194439.GD5548@mellanox.com>
[-- Attachment #1: Type: text/plain, Size: 4191 bytes --]
On Thu, Nov 08, 2018 at 07:44:44PM +0000, Jason Gunthorpe wrote:
> On Thu, Nov 08, 2018 at 09:10:09PM +0200, Leon Romanovsky wrote:
> > From: Moni Shoua <monis@mellanox.com>
> >
> > Fix 2 flows that may cause a process to hang on wait_for_completion():
> >
> > 1. When callback for create MKEY command returns with bad status
> > 2. When callback for create MKEY command is called before executer of
> > command calls wait_for_completion()
> >
> > The following call trace might be triggered in the above flows:
> >
> > INFO: task echo_server:1655 blocked for more than 120 seconds.
> > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> > echo_server D ffff880813fb6898 0 1655 1 0x00000004
> > ffff880423f5b880 0000000000000086 ffff880402290fd0 ffff880423f5bfd8
> > ffff880423f5bfd8 ffff880423f5bfd8 ffff880402290fd0 ffff880813fb68a0
> > 7fffffffffffffff ffff880813fb6898 ffff880402290fd0 ffff880813fb6898
> > Call Trace:
> > [<ffffffff816a94c9>] schedule+0x29/0x70
> > [<ffffffff816a6fd9>] schedule_timeout+0x239/0x2c0
> > [<ffffffffc07309e2>] ? mlx5_cmd_exec_cb+0x22/0x30 [mlx5_core]
> > [<ffffffffc073e697>] ? mlx5_core_create_mkey_cb+0xb7/0x220 [mlx5_core]
> > [<ffffffff811b94b7>] ? mm_drop_all_locks+0xd7/0x110
> > [<ffffffff816a987d>] wait_for_completion+0xfd/0x140
> > [<ffffffff810c4810>] ? wake_up_state+0x20/0x20
> > [<ffffffffc08fd308>] mlx5_mr_cache_alloc+0xa8/0x170 [mlx5_ib]
> > [<ffffffffc0909626>] implicit_mr_alloc+0x36/0x190 [mlx5_ib]
> > [<ffffffffc090a26e>] mlx5_ib_alloc_implicit_mr+0x4e/0xa0 [mlx5_ib]
> > [<ffffffffc08ff2f3>] mlx5_ib_reg_user_mr+0x93/0x6a0 [mlx5_ib]
> > [<ffffffffc0907410>] ? mlx5_ib_exp_query_device+0xab0/0xbc0 [mlx5_ib]
> > [<ffffffffc04998be>] ib_uverbs_exp_reg_mr+0x2fe/0x550 [ib_uverbs]
> > [<ffffffff811edaff>] ? do_huge_pmd_anonymous_page+0x2bf/0x530
> > [<ffffffffc048f6cc>] ib_uverbs_write+0x3ec/0x490 [ib_uverbs]
> > [<ffffffff81200d2d>] vfs_write+0xbd/0x1e0
> > [<ffffffff81201b3f>] SyS_write+0x7f/0xe0
> > [<ffffffff816b4fc9>] system_call_fastpath+0x16/0x1b
> >
> > Fixes: 49780d42dfc9 ("IB/mlx5: Expose MR cache for mlx5_ib")
> > Signed-off-by: Moni Shoua <monis@mellanox.com>
> > Reviewed-by: Majd Dibbiny <majd@mellanox.com>
> > Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> > drivers/infiniband/hw/mlx5/mlx5_ib.h | 1 +
> > drivers/infiniband/hw/mlx5/mr.c | 15 ++++++++++++---
> > 2 files changed, 13 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/infiniband/hw/mlx5/mlx5_ib.h b/drivers/infiniband/hw/mlx5/mlx5_ib.h
> > index b651a7a6fde9..cd9335e368bd 100644
> > +++ b/drivers/infiniband/hw/mlx5/mlx5_ib.h
> > @@ -644,6 +644,7 @@ struct mlx5_cache_ent {
> > struct delayed_work dwork;
> > int pending;
> > struct completion compl;
> > + atomic_t do_complete;
> > };
> >
> > struct mlx5_mr_cache {
> > diff --git a/drivers/infiniband/hw/mlx5/mr.c b/drivers/infiniband/hw/mlx5/mr.c
> > index 9b195d65a13e..259dd49c6874 100644
> > +++ b/drivers/infiniband/hw/mlx5/mr.c
> > @@ -143,7 +143,7 @@ static void reg_mr_callback(int status, void *context)
> > kfree(mr);
> > dev->fill_delay = 1;
> > mod_timer(&dev->delay_timer, jiffies + HZ);
> > - return;
> > + goto do_complete;
> > }
> >
> > mr->mmkey.type = MLX5_MKEY_MR;
> > @@ -167,8 +167,13 @@ static void reg_mr_callback(int status, void *context)
> > pr_err("Error inserting to mkey tree. 0x%x\n", -err);
> > write_unlock_irqrestore(&table->lock, flags);
> >
> > - if (!completion_done(&ent->compl))
> > +do_complete:
> > + spin_lock_irqsave(&ent->lock, flags);
> > + if (atomic_read(&ent->do_complete)) {
> > complete(&ent->compl);
> > + atomic_dec(&ent->do_complete);
> > + }
> > + spin_unlock_irqrestore(&ent->lock, flags);
>
> Oh, this is quite an ugly way to use completions, I think this has
> veered into misusing completion territory.. The completion_done was
> never right...
>
> add_keys should accept a flag indicating that this MR has a completor
> waiting and should trigger complete() on CB finishing... Can probably
> store the flag someplace in the MR.
I reread this patch again ans you are right.
Let's drop this patch.
Thanks
>
> Jason
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v4] Wait for running BPF programs when updating map-in-map
From: Chenbo Feng @ 2018-11-10 2:01 UTC (permalink / raw)
To: joel
Cc: Alexei Starovoitov, Daniel Colascione, Joel Fernandes,
linux-kernel, Tim Murray, netdev, Lorenzo Colitti,
Mathieu Desnoyers, Alexei Starovoitov, Daniel Borkmann, stable
In-Reply-To: <20181018233633.GA89903@joelaf.mtv.corp.google.com>
Hi netdev,
Could we queue up this patch to stable 4.14 and stable 4.19? I can
provide a backport patch if needed. I checked it is a clean
cherry-pick for 4.19 but have some minor conflict for 4.14.
Thanks
Chenbo Feng
On Thu, Oct 18, 2018 at 4:36 PM Joel Fernandes <joel@joelfernandes.org> wrote:
>
> On Thu, Oct 18, 2018 at 08:46:59AM -0700, Alexei Starovoitov wrote:
> > On Tue, Oct 16, 2018 at 10:39:57AM -0700, Joel Fernandes wrote:
> > > On Fri, Oct 12, 2018 at 7:31 PM, Alexei Starovoitov
> > > <alexei.starovoitov@gmail.com> wrote:
> > > > On Fri, Oct 12, 2018 at 03:54:27AM -0700, Daniel Colascione wrote:
> > > >> The map-in-map frequently serves as a mechanism for atomic
> > > >> snapshotting of state that a BPF program might record. The current
> > > >> implementation is dangerous to use in this way, however, since
> > > >> userspace has no way of knowing when all programs that might have
> > > >> retrieved the "old" value of the map may have completed.
> > > >>
> > > >> This change ensures that map update operations on map-in-map map types
> > > >> always wait for all references to the old map to drop before returning
> > > >> to userspace.
> > > >>
> > > >> Signed-off-by: Daniel Colascione <dancol@google.com>
> > > >> ---
> > > >> kernel/bpf/syscall.c | 14 ++++++++++++++
> > > >> 1 file changed, 14 insertions(+)
> > > >>
> > > >> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> > > >> index 8339d81cba1d..d7c16ae1e85a 100644
> > > >> --- a/kernel/bpf/syscall.c
> > > >> +++ b/kernel/bpf/syscall.c
> > > >> @@ -741,6 +741,18 @@ static int map_lookup_elem(union bpf_attr *attr)
> > > >> return err;
> > > >> }
> > > >>
> > > >> +static void maybe_wait_bpf_programs(struct bpf_map *map)
> > > >> +{
> > > >> + /* Wait for any running BPF programs to complete so that
> > > >> + * userspace, when we return to it, knows that all programs
> > > >> + * that could be running use the new map value.
> > > >> + */
> > > >> + if (map->map_type == BPF_MAP_TYPE_HASH_OF_MAPS ||
> > > >> + map->map_type == BPF_MAP_TYPE_ARRAY_OF_MAPS) {
> > > >> + synchronize_rcu();
> > > >> + }
> > > >
> > > > extra {} were not necessary. I removed them while applying to bpf-next.
> > > > Please run checkpatch.pl next time.
> > > > Thanks
> > >
> > > Thanks Alexei for taking it. Me and Lorenzo were discussing that not
> > > having this causes incorrect behavior for apps using map-in-map for
> > > this. So I CC'd stable as well.
> >
> > It is too late in the release cycle.
> > We can submit it to stable releases after the merge window.
> >
>
> Sounds good, thanks.
>
> - Joel
>
^ permalink raw reply
* Re: Kernel 4.19 network performance - forwarding/routing normal users traffic
From: David Ahern @ 2018-11-09 16:21 UTC (permalink / raw)
To: Paweł Staszewski, Jesper Dangaard Brouer; +Cc: netdev, Yoel Caspersen
In-Reply-To: <77027868-2b96-8c1d-f485-c7b36c6d9fa9@itcare.pl>
On 11/9/18 3:20 AM, Paweł Staszewski wrote:
>
> I just catch some weird behavior :)
> All was working fine for about 20k packets
>
> Then after xdp start to forward every 10 packets
Interesting. Any counter showing drops?
> ping 172.16.0.2 -i 0.1
> PING 172.16.0.2 (172.16.0.2) 56(84) bytes of data.
> 64 bytes from 172.16.0.2: icmp_seq=1 ttl=64 time=5.12 ms
> 64 bytes from 172.16.0.2: icmp_seq=9 ttl=64 time=5.20 ms
> 64 bytes from 172.16.0.2: icmp_seq=19 ttl=64 time=4.85 ms
> 64 bytes from 172.16.0.2: icmp_seq=29 ttl=64 time=4.91 ms
> 64 bytes from 172.16.0.2: icmp_seq=38 ttl=64 time=4.85 ms
> 64 bytes from 172.16.0.2: icmp_seq=48 ttl=64 time=5.00 ms
> ^C
> --- 172.16.0.2 ping statistics ---
> 55 packets transmitted, 6 received, 89% packet loss, time 5655ms
> rtt min/avg/max/mdev = 4.850/4.992/5.203/0.145 ms
>
>
> And again after some time back to normal
>
> ping 172.16.0.2 -i 0.1
> PING 172.16.0.2 (172.16.0.2) 56(84) bytes of data.
> 64 bytes from 172.16.0.2: icmp_seq=1 ttl=64 time=5.02 ms
> 64 bytes from 172.16.0.2: icmp_seq=2 ttl=64 time=5.06 ms
> 64 bytes from 172.16.0.2: icmp_seq=3 ttl=64 time=5.19 ms
> 64 bytes from 172.16.0.2: icmp_seq=4 ttl=64 time=5.07 ms
> 64 bytes from 172.16.0.2: icmp_seq=5 ttl=64 time=5.08 ms
> 64 bytes from 172.16.0.2: icmp_seq=6 ttl=64 time=5.14 ms
> 64 bytes from 172.16.0.2: icmp_seq=7 ttl=64 time=5.08 ms
> 64 bytes from 172.16.0.2: icmp_seq=8 ttl=64 time=5.17 ms
> 64 bytes from 172.16.0.2: icmp_seq=9 ttl=64 time=5.04 ms
> 64 bytes from 172.16.0.2: icmp_seq=10 ttl=64 time=5.10 ms
> 64 bytes from 172.16.0.2: icmp_seq=11 ttl=64 time=5.11 ms
> 64 bytes from 172.16.0.2: icmp_seq=12 ttl=64 time=5.13 ms
> 64 bytes from 172.16.0.2: icmp_seq=13 ttl=64 time=5.12 ms
> 64 bytes from 172.16.0.2: icmp_seq=14 ttl=64 time=5.15 ms
> 64 bytes from 172.16.0.2: icmp_seq=15 ttl=64 time=5.13 ms
> 64 bytes from 172.16.0.2: icmp_seq=16 ttl=64 time=5.04 ms
> 64 bytes from 172.16.0.2: icmp_seq=17 ttl=64 time=5.12 ms
> 64 bytes from 172.16.0.2: icmp_seq=18 ttl=64 time=5.07 ms
> 64 bytes from 172.16.0.2: icmp_seq=19 ttl=64 time=5.06 ms
> 64 bytes from 172.16.0.2: icmp_seq=20 ttl=64 time=5.12 ms
> 64 bytes from 172.16.0.2: icmp_seq=21 ttl=64 time=5.21 ms
> 64 bytes from 172.16.0.2: icmp_seq=22 ttl=64 time=4.98 ms
> ^C
> --- 172.16.0.2 ping statistics ---
> 22 packets transmitted, 22 received, 0% packet loss, time 2105ms
> rtt min/avg/max/mdev = 4.988/5.104/5.210/0.089 ms
>
>
> I will try to catch this with debug enabled
>
>
>
>
>
> Wondering also - cause xdp will bypass now vlan counters and other stuff
> like tcpdump
yes, xdp is before tcpdump based sockets.
And the counters (vlan just being the current example) is another
problem to be solved. The vlan net_device never sees the packet and you
can not arbitrarily bump the counters just because the device lookups
reference them.
>
> Is there possible to add only counters from xdp for vlans ?
> This will help me in testing.
I will take a look today at adding counters that you can dump using
bpftool. It will be a temporary solution for this xdp program only.
>
>
> And also - for non lab scenario there should be possible to sniff
> sometimes on interface :)
Yes, sampling is another problem.
> Soo wondering if need to attack another xdp program to interface or all
> this can be done by one
>
> I think this is time where i will need to learn more about xdp :)
>
>
^ 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