* Re: Question about ip_defrag
From: Florian Westphal @ 2017-08-29 13:46 UTC (permalink / raw)
To: liujian (CE)
Cc: Florian Westphal, Jesper Dangaard Brouer, netdev@vger.kernel.org,
Wangkefeng (Kevin), weiyongjun (A)
In-Reply-To: <4F88C5DDA1E80143B232E89585ACE27D018F4850@DGGEMA502-MBX.china.huawei.com>
liujian (CE) <liujian56@huawei.com> wrote:
[ trimming cc list ]
> Now, I have not the real environment.
> I use iperf generate fragment packets;
> and I always change NIC rx irq's affinity cpu, to make sure frag_mem_limit reach to thresh.
> my test machine, CPU num is 384.
Oh well, that explains it.
> > > + if (frag_mem_limit(nf) > nf->low_thresh) {
> > > inet_frag_schedule_worker(f);
> > > + update_frag_mem_limit(nf, SKB_TRUESIZE(1500) * 16);
> > > + }
You need to reduce this to a lower value.
Your cpu count * batch_value needs to be less than
low_thresh to avoid problems.
Wtih 384 cpus its close to 12 mbyte...
Perhaps do this:
update_frag_mem_limit(nf, 2 * 1024*1024 / NR_CPUS);
However, I think its better to revert the percpu counter change and
move back to a single atomic_t count.
^ permalink raw reply
* Re: [PATCH net-next v2] bridge: fdb add and delete tracepoints
From: Roopa Prabhu @ 2017-08-29 13:49 UTC (permalink / raw)
To: Andrew Lunn
Cc: Nikolay Aleksandrov, netdev@vger.kernel.org, Florian Fainelli,
davem@davemloft.net, bridge
In-Reply-To: <20170829133648.GF22093@lunn.ch>
On Tue, Aug 29, 2017 at 6:36 AM, Andrew Lunn <andrew@lunn.ch> wrote:
> On Mon, Aug 28, 2017 at 09:22:48PM -0700, Roopa Prabhu wrote:
>> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>>
>> A few useful tracepoints to trace bridge forwarding
>> database updates.
>
> Hi Roopa
>
> Once accepted, it would be nice to add mdb tracepoints as well. I
> expect the implementation would be very similar.
>
yes, sounds great. will do.
^ permalink raw reply
* Re: [PATCH v4 4/5] net: stmmac: dwmac-sun8i: choose internal PHY via phy-is-integrated
From: Andrew Lunn @ 2017-08-29 14:06 UTC (permalink / raw)
To: Corentin Labbe
Cc: mark.rutland, devicetree, f.fainelli, alexandre.torgue, netdev,
linux, linux-kernel, wens, robh+dt, peppe.cavallaro,
maxime.ripard, linux-arm-kernel, icenowy
In-Reply-To: <20170829083432.GA28818@Red>
> Do you agree that another mdio_mux_init() must be written ? (taking
> a of_node (in our case: mdio-mux) instead of a device)
Yes, you are correct, it is using dev->of_node. So you need to
refactor the code a little, to allow an of_node to be passed.
Andrew
^ permalink raw reply
* Re: [PATCH] staging: r8822be: Fix typo for CONFIG_RTLWIFI_DEBUG
From: Larry Finger @ 2017-08-29 14:10 UTC (permalink / raw)
To: Andreas Ziegler, Greg KH
Cc: devel, Yan-Hsuan Chuang, Birming Chiu, netdev, Steven Ting
In-Reply-To: <1504006208-18965-1-git-send-email-andreas.ziegler@fau.de>
On 08/29/2017 06:30 AM, Andreas Ziegler wrote:
> The debugging output in deinit_priv is guarded by an #ifdef using
> CONFIG_RTL_DEBUG. This symbol does not exist and should be
> CONFIG_RTLWIFI_DEBUG instead.
>
> Signed-off-by: Andreas Ziegler <andreas.ziegler@fau.de>
NACK.
Yes, there is a problem; however, CONFIG_RTLWIFI_DEBUG is not the value that
should be used. That one is reserved for the non-staging drivers in
drivers/net/wireless/realtek/rtlwifi/. The correct symbol for r8822be is
CONFIG_RTLWIFI_DEBUG_ST.
Larry
> ---
> drivers/staging/rtlwifi/halmac/rtl_halmac.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/rtlwifi/halmac/rtl_halmac.c b/drivers/staging/rtlwifi/halmac/rtl_halmac.c
> index 031bf2c..888ca43 100644
> --- a/drivers/staging/rtlwifi/halmac/rtl_halmac.c
> +++ b/drivers/staging/rtlwifi/halmac/rtl_halmac.c
> @@ -386,7 +386,7 @@ static void deinit_priv(struct rtl_halmac *halmac)
> u32 count, size;
>
> count = HALMAC_FEATURE_ALL + 1;
> -#ifdef CONFIG_RTL_DEBUG
> +#ifdef CONFIG_RTLWIFI_DEBUG
> {
> struct submit_ctx *sctx;
> u32 i;
> @@ -405,7 +405,7 @@ static void deinit_priv(struct rtl_halmac *halmac)
> rtl_mfree((u8 *)sctx, sizeof(*sctx));
> }
> }
> -#endif /* !CONFIG_RTL_DEBUG */
> +#endif /* !CONFIG_RTLWIFI_DEBUG */
> size = sizeof(*indicator) * count;
> kfree((u8 *)indicator);
> }
>
^ permalink raw reply
* [PATCH net-next 0/7] XDP redirect tracepoints
From: Jesper Dangaard Brouer @ 2017-08-29 14:37 UTC (permalink / raw)
To: netdev; +Cc: John Fastabend, Jesper Dangaard Brouer
I feel this is as far as I can take the tracepoint infrastructure to
assist XDP monitoring.
Tracepoints comes with a base overhead of 25 nanosec for an attached
bpf_prog, and 48 nanosec for using a full perf record. This is
problematic for the XDP use-case, but it is very convenient to use the
existing perf infrastructure.
>From a performance perspective, the real solution would be to attach
another bpf_prog (that understand xdp_buff), but I'm not sure we want
to introduce yet another bpf attach API for this.
One thing left is to standardize the possible err return codes, to a
limited set, to allow easier (and faster) mapping into a bpf map.
---
Jesper Dangaard Brouer (7):
xdp: remove redundant argument to trace_xdp_redirect
xdp: tracepoint xdp_redirect also need a map argument
xdp: make xdp tracepoints report bpf prog id instead of prog_tag
xdp: separate xdp_redirect tracepoint in error case
xdp: separate xdp_redirect tracepoint in map case
samples/bpf: xdp_redirect load XDP dummy prog on TX device
samples/bpf: xdp_monitor tool based on tracepoints
include/trace/events/xdp.h | 100 ++++++++++--
net/core/filter.c | 37 +++-
samples/bpf/Makefile | 4
samples/bpf/xdp_monitor_kern.c | 88 ++++++++++
samples/bpf/xdp_monitor_user.c | 295 +++++++++++++++++++++++++++++++++++
samples/bpf/xdp_redirect_kern.c | 11 +
samples/bpf/xdp_redirect_map_kern.c | 11 +
samples/bpf/xdp_redirect_map_user.c | 22 ++-
samples/bpf/xdp_redirect_user.c | 21 ++
9 files changed, 543 insertions(+), 46 deletions(-)
create mode 100644 samples/bpf/xdp_monitor_kern.c
create mode 100644 samples/bpf/xdp_monitor_user.c
^ permalink raw reply
* [PATCH net-next 1/7] xdp: remove redundant argument to trace_xdp_redirect
From: Jesper Dangaard Brouer @ 2017-08-29 14:37 UTC (permalink / raw)
To: netdev; +Cc: John Fastabend, Jesper Dangaard Brouer
In-Reply-To: <150401743083.16384.15778781741742858567.stgit@firesoul>
Supplying the action argument XDP_REDIRECT to the tracepoint xdp_redirect
is redundant as it is only called in-case this action was specified.
Remove the argument, but keep "act" member of the tracepoint struct and
populate it with XDP_REDIRECT. This makes it easier to write a common bpf_prog
processing events.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
---
include/trace/events/xdp.h | 6 +++---
net/core/filter.c | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/trace/events/xdp.h b/include/trace/events/xdp.h
index 27cf2ef35f5f..f684f3b36bca 100644
--- a/include/trace/events/xdp.h
+++ b/include/trace/events/xdp.h
@@ -52,10 +52,10 @@ TRACE_EVENT(xdp_exception,
TRACE_EVENT(xdp_redirect,
TP_PROTO(const struct net_device *dev,
- const struct bpf_prog *xdp, u32 act,
+ const struct bpf_prog *xdp,
int to_index, int err),
- TP_ARGS(dev, xdp, act, to_index, err),
+ TP_ARGS(dev, xdp, to_index, err),
TP_STRUCT__entry(
__array(u8, prog_tag, 8)
@@ -68,7 +68,7 @@ TRACE_EVENT(xdp_redirect,
TP_fast_assign(
BUILD_BUG_ON(sizeof(__entry->prog_tag) != sizeof(xdp->tag));
memcpy(__entry->prog_tag, xdp->tag, sizeof(xdp->tag));
- __entry->act = act;
+ __entry->act = XDP_REDIRECT;
__entry->ifindex = dev->ifindex;
__entry->to_index = to_index;
__entry->err = err;
diff --git a/net/core/filter.c b/net/core/filter.c
index 4bcd6baa80c9..de31fb684ad4 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -2524,7 +2524,7 @@ static int xdp_do_redirect_map(struct net_device *dev, struct xdp_buff *xdp,
if (likely(!err))
ri->map_to_flush = map;
out:
- trace_xdp_redirect(dev, xdp_prog, XDP_REDIRECT, index, err);
+ trace_xdp_redirect(dev, xdp_prog, index, err);
return err;
}
@@ -2548,7 +2548,7 @@ int xdp_do_redirect(struct net_device *dev, struct xdp_buff *xdp,
err = __bpf_tx_xdp(fwd, NULL, xdp, 0);
out:
- trace_xdp_redirect(dev, xdp_prog, XDP_REDIRECT, index, err);
+ trace_xdp_redirect(dev, xdp_prog, index, err);
return err;
}
EXPORT_SYMBOL_GPL(xdp_do_redirect);
@@ -2582,7 +2582,7 @@ int xdp_do_generic_redirect(struct net_device *dev, struct sk_buff *skb,
skb->dev = fwd;
out:
- trace_xdp_redirect(dev, xdp_prog, XDP_REDIRECT, index, err);
+ trace_xdp_redirect(dev, xdp_prog, index, err);
return err;
}
EXPORT_SYMBOL_GPL(xdp_do_generic_redirect);
^ permalink raw reply related
* [PATCH net-next 2/7] xdp: tracepoint xdp_redirect also need a map argument
From: Jesper Dangaard Brouer @ 2017-08-29 14:37 UTC (permalink / raw)
To: netdev; +Cc: John Fastabend, Jesper Dangaard Brouer
In-Reply-To: <150401743083.16384.15778781741742858567.stgit@firesoul>
To make sense of the map index, the tracepoint user also need to know
that map we are talking about. Supply the map pointer but only expose
the map->id.
The 'to_index' is renamed 'to_ifindex'. In the xdp_redirect_map case,
this is the result of the devmap lookup. The map lookup key is exposed
as map_index, which is needed to troubleshoot in case the lookup failed.
The 'to_ifindex' is placed after 'err' to keep TP_STRUCT as common as
possible.
This also keeps the TP_STRUCT similar enough, that userspace can write
a monitor program, that doesn't need to care about whether
bpf_redirect or bpf_redirect_map were used.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
---
include/trace/events/xdp.h | 38 ++++++++++++++++++++++++++++++--------
net/core/filter.c | 6 +++---
2 files changed, 33 insertions(+), 11 deletions(-)
diff --git a/include/trace/events/xdp.h b/include/trace/events/xdp.h
index f684f3b36bca..573dcfa1aeaa 100644
--- a/include/trace/events/xdp.h
+++ b/include/trace/events/xdp.h
@@ -49,20 +49,23 @@ TRACE_EVENT(xdp_exception,
__entry->ifindex)
);
-TRACE_EVENT(xdp_redirect,
+DECLARE_EVENT_CLASS(xdp_redirect_template,
TP_PROTO(const struct net_device *dev,
const struct bpf_prog *xdp,
- int to_index, int err),
+ int to_ifindex, int err,
+ const struct bpf_map *map, u32 map_index),
- TP_ARGS(dev, xdp, to_index, err),
+ TP_ARGS(dev, xdp, to_ifindex, err, map, map_index),
TP_STRUCT__entry(
__array(u8, prog_tag, 8)
__field(u32, act)
__field(int, ifindex)
- __field(int, to_index)
__field(int, err)
+ __field(int, to_ifindex)
+ __field(u32, map_id)
+ __field(int, map_index)
),
TP_fast_assign(
@@ -70,16 +73,35 @@ TRACE_EVENT(xdp_redirect,
memcpy(__entry->prog_tag, xdp->tag, sizeof(xdp->tag));
__entry->act = XDP_REDIRECT;
__entry->ifindex = dev->ifindex;
- __entry->to_index = to_index;
__entry->err = err;
+ __entry->to_ifindex = to_ifindex;
+ __entry->map_id = map ? map->id : 0;
+ __entry->map_index = map_index;
),
- TP_printk("prog=%s action=%s ifindex=%d to_index=%d err=%d",
+ TP_printk("prog=%s action=%s ifindex=%d to_ifindex=%d err=%d"
+ " map_id=%d map_index=%d",
__print_hex_str(__entry->prog_tag, 8),
__print_symbolic(__entry->act, __XDP_ACT_SYM_TAB),
- __entry->ifindex, __entry->to_index,
- __entry->err)
+ __entry->ifindex, __entry->to_ifindex,
+ __entry->err,
+ __entry->map_id, __entry->map_index)
);
+
+DEFINE_EVENT(xdp_redirect_template, xdp_redirect,
+ TP_PROTO(const struct net_device *dev,
+ const struct bpf_prog *xdp,
+ int to_ifindex, int err,
+ const struct bpf_map *map, u32 map_index),
+ TP_ARGS(dev, xdp, to_ifindex, err, map, map_index)
+);
+
+#define _trace_xdp_redirect(dev, xdp, to, err) \
+ trace_xdp_redirect(dev, xdp, to, err, NULL, 0);
+
+#define trace_xdp_redirect_map(dev, xdp, fwd, err, map, idx) \
+ trace_xdp_redirect(dev, xdp, fwd ? fwd->ifindex : 0, err, map, idx);
+
#endif /* _TRACE_XDP_H */
#include <trace/define_trace.h>
diff --git a/net/core/filter.c b/net/core/filter.c
index de31fb684ad4..31eab77cc842 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -2524,7 +2524,7 @@ static int xdp_do_redirect_map(struct net_device *dev, struct xdp_buff *xdp,
if (likely(!err))
ri->map_to_flush = map;
out:
- trace_xdp_redirect(dev, xdp_prog, index, err);
+ trace_xdp_redirect_map(dev, xdp_prog, fwd, err, map, index);
return err;
}
@@ -2548,7 +2548,7 @@ int xdp_do_redirect(struct net_device *dev, struct xdp_buff *xdp,
err = __bpf_tx_xdp(fwd, NULL, xdp, 0);
out:
- trace_xdp_redirect(dev, xdp_prog, index, err);
+ _trace_xdp_redirect(dev, xdp_prog, index, err);
return err;
}
EXPORT_SYMBOL_GPL(xdp_do_redirect);
@@ -2582,7 +2582,7 @@ int xdp_do_generic_redirect(struct net_device *dev, struct sk_buff *skb,
skb->dev = fwd;
out:
- trace_xdp_redirect(dev, xdp_prog, index, err);
+ _trace_xdp_redirect(dev, xdp_prog, index, err);
return err;
}
EXPORT_SYMBOL_GPL(xdp_do_generic_redirect);
^ permalink raw reply related
* [PATCH net-next 3/7] xdp: make xdp tracepoints report bpf prog id instead of prog_tag
From: Jesper Dangaard Brouer @ 2017-08-29 14:37 UTC (permalink / raw)
To: netdev; +Cc: John Fastabend, Jesper Dangaard Brouer
In-Reply-To: <150401743083.16384.15778781741742858567.stgit@firesoul>
Given previous patch expose the map_id, it seems natural to also
report the bpf prog id.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
---
include/trace/events/xdp.h | 18 ++++++++----------
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/include/trace/events/xdp.h b/include/trace/events/xdp.h
index 573dcfa1aeaa..89eba564e199 100644
--- a/include/trace/events/xdp.h
+++ b/include/trace/events/xdp.h
@@ -31,20 +31,19 @@ TRACE_EVENT(xdp_exception,
TP_ARGS(dev, xdp, act),
TP_STRUCT__entry(
- __array(u8, prog_tag, 8)
+ __field(int, prog_id)
__field(u32, act)
__field(int, ifindex)
),
TP_fast_assign(
- BUILD_BUG_ON(sizeof(__entry->prog_tag) != sizeof(xdp->tag));
- memcpy(__entry->prog_tag, xdp->tag, sizeof(xdp->tag));
+ __entry->prog_id = xdp->aux->id;
__entry->act = act;
__entry->ifindex = dev->ifindex;
),
- TP_printk("prog=%s action=%s ifindex=%d",
- __print_hex_str(__entry->prog_tag, 8),
+ TP_printk("prog_id=%d action=%s ifindex=%d",
+ __entry->prog_id,
__print_symbolic(__entry->act, __XDP_ACT_SYM_TAB),
__entry->ifindex)
);
@@ -59,7 +58,7 @@ DECLARE_EVENT_CLASS(xdp_redirect_template,
TP_ARGS(dev, xdp, to_ifindex, err, map, map_index),
TP_STRUCT__entry(
- __array(u8, prog_tag, 8)
+ __field(int, prog_id)
__field(u32, act)
__field(int, ifindex)
__field(int, err)
@@ -69,8 +68,7 @@ DECLARE_EVENT_CLASS(xdp_redirect_template,
),
TP_fast_assign(
- BUILD_BUG_ON(sizeof(__entry->prog_tag) != sizeof(xdp->tag));
- memcpy(__entry->prog_tag, xdp->tag, sizeof(xdp->tag));
+ __entry->prog_id = xdp->aux->id;
__entry->act = XDP_REDIRECT;
__entry->ifindex = dev->ifindex;
__entry->err = err;
@@ -79,9 +77,9 @@ DECLARE_EVENT_CLASS(xdp_redirect_template,
__entry->map_index = map_index;
),
- TP_printk("prog=%s action=%s ifindex=%d to_ifindex=%d err=%d"
+ TP_printk("prog_id=%d action=%s ifindex=%d to_ifindex=%d err=%d"
" map_id=%d map_index=%d",
- __print_hex_str(__entry->prog_tag, 8),
+ __entry->prog_id,
__print_symbolic(__entry->act, __XDP_ACT_SYM_TAB),
__entry->ifindex, __entry->to_ifindex,
__entry->err,
^ permalink raw reply related
* [PATCH net-next 4/7] xdp: separate xdp_redirect tracepoint in error case
From: Jesper Dangaard Brouer @ 2017-08-29 14:37 UTC (permalink / raw)
To: netdev; +Cc: John Fastabend, Jesper Dangaard Brouer
In-Reply-To: <150401743083.16384.15778781741742858567.stgit@firesoul>
There is a need to separate the xdp_redirect tracepoint into two
tracepoints, for separating the error case from the normal forward
case.
Due to the extreme speeds XDP is operating at, loading a tracepoint
have a measurable impact. Single core XDP REDIRECT (ethtool tuned
rx-usecs 25) can do 13.7 Mpps forwarding, but loading a simple
bpf_prog at the tracepoint (with a return 0) reduce perf to 10.2 Mpps
(CPU E5-1650 v4 @ 3.60GHz, driver: ixgbe)
The overhead of loading a bpf-based tracepoint can be calculated to
cost 25 nanosec ((1/13782002-1/10267937)*10^9 = -24.83 ns).
Using perf record on the tracepoint event, with a non-matching --filter
expression, the overhead is much larger. Performance drops to 8.3 Mpps,
cost 48 nanosec ((1/13782002-1/8312497)*10^9 = -47.74))
Having a separate tracepoint for err cases, which should be less
frequent, allow running a continuous monitor for errors while not
affecting the redirect forward performance (this have also been
verified by measurements).
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
---
include/trace/events/xdp.h | 22 ++++++++++++++++++----
net/core/filter.c | 37 ++++++++++++++++++++++++-------------
2 files changed, 42 insertions(+), 17 deletions(-)
diff --git a/include/trace/events/xdp.h b/include/trace/events/xdp.h
index 89eba564e199..1eebad55ebd4 100644
--- a/include/trace/events/xdp.h
+++ b/include/trace/events/xdp.h
@@ -94,11 +94,25 @@ DEFINE_EVENT(xdp_redirect_template, xdp_redirect,
TP_ARGS(dev, xdp, to_ifindex, err, map, map_index)
);
-#define _trace_xdp_redirect(dev, xdp, to, err) \
- trace_xdp_redirect(dev, xdp, to, err, NULL, 0);
+DEFINE_EVENT(xdp_redirect_template, xdp_redirect_err,
+ TP_PROTO(const struct net_device *dev,
+ const struct bpf_prog *xdp,
+ int to_ifindex, int err,
+ const struct bpf_map *map, u32 map_index),
+ TP_ARGS(dev, xdp, to_ifindex, err, map, map_index)
+);
+
+#define _trace_xdp_redirect(dev, xdp, to) \
+ trace_xdp_redirect(dev, xdp, to, 0, NULL, 0);
+
+#define _trace_xdp_redirect_err(dev, xdp, to, err) \
+ trace_xdp_redirect_err(dev, xdp, to, err, NULL, 0);
+
+#define trace_xdp_redirect_map(dev, xdp, fwd, map, idx) \
+ trace_xdp_redirect(dev, xdp, fwd ? fwd->ifindex : 0, 0, map, idx);
-#define trace_xdp_redirect_map(dev, xdp, fwd, err, map, idx) \
- trace_xdp_redirect(dev, xdp, fwd ? fwd->ifindex : 0, err, map, idx);
+#define trace_xdp_redirect_map_err(dev, xdp, fwd, map, idx, err) \
+ trace_xdp_redirect_err(dev, xdp, fwd ? fwd->ifindex : 0, err, map, idx);
#endif /* _TRACE_XDP_H */
diff --git a/net/core/filter.c b/net/core/filter.c
index 31eab77cc842..096e78de0b97 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -2515,16 +2515,20 @@ static int xdp_do_redirect_map(struct net_device *dev, struct xdp_buff *xdp,
fwd = __dev_map_lookup_elem(map, index);
if (!fwd) {
err = -EINVAL;
- goto out;
+ goto err;
}
if (ri->map_to_flush && ri->map_to_flush != map)
xdp_do_flush_map();
err = __bpf_tx_xdp(fwd, map, xdp, index);
- if (likely(!err))
- ri->map_to_flush = map;
-out:
- trace_xdp_redirect_map(dev, xdp_prog, fwd, err, map, index);
+ if (unlikely(err))
+ goto err;
+
+ ri->map_to_flush = map;
+ trace_xdp_redirect_map(dev, xdp_prog, fwd, map, index);
+ return 0;
+err:
+ trace_xdp_redirect_map_err(dev, xdp_prog, fwd, map, index, err);
return err;
}
@@ -2543,12 +2547,17 @@ int xdp_do_redirect(struct net_device *dev, struct xdp_buff *xdp,
ri->ifindex = 0;
if (unlikely(!fwd)) {
err = -EINVAL;
- goto out;
+ goto err;
}
err = __bpf_tx_xdp(fwd, NULL, xdp, 0);
-out:
- _trace_xdp_redirect(dev, xdp_prog, index, err);
+ if (unlikely(err))
+ goto err;
+
+ _trace_xdp_redirect(dev, xdp_prog, index);
+ return 0;
+err:
+ _trace_xdp_redirect_err(dev, xdp_prog, index, err);
return err;
}
EXPORT_SYMBOL_GPL(xdp_do_redirect);
@@ -2566,23 +2575,25 @@ int xdp_do_generic_redirect(struct net_device *dev, struct sk_buff *skb,
ri->ifindex = 0;
if (unlikely(!fwd)) {
err = -EINVAL;
- goto out;
+ goto err;
}
if (unlikely(!(fwd->flags & IFF_UP))) {
err = -ENETDOWN;
- goto out;
+ goto err;
}
len = fwd->mtu + fwd->hard_header_len + VLAN_HLEN;
if (skb->len > len) {
err = -EMSGSIZE;
- goto out;
+ goto err;
}
skb->dev = fwd;
-out:
- _trace_xdp_redirect(dev, xdp_prog, index, err);
+ _trace_xdp_redirect(dev, xdp_prog, index);
+ return 0;
+err:
+ _trace_xdp_redirect_err(dev, xdp_prog, index, err);
return err;
}
EXPORT_SYMBOL_GPL(xdp_do_generic_redirect);
^ permalink raw reply related
* [PATCH net-next 5/7] xdp: separate xdp_redirect tracepoint in map case
From: Jesper Dangaard Brouer @ 2017-08-29 14:38 UTC (permalink / raw)
To: netdev; +Cc: John Fastabend, Jesper Dangaard Brouer
In-Reply-To: <150401743083.16384.15778781741742858567.stgit@firesoul>
Creating as specific xdp_redirect_map variant of the xdp tracepoints
allow users to write simpler/faster BPF progs that get attached to
these tracepoints.
Goal is to still keep the tracepoints in xdp_redirect and xdp_redirect_map
similar enough, that a tool can read the top part of the TP_STRUCT and
produce similar monitor statistics.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
---
include/trace/events/xdp.h | 46 ++++++++++++++++++++++++++++++++++++--------
net/core/filter.c | 4 ++--
2 files changed, 40 insertions(+), 10 deletions(-)
diff --git a/include/trace/events/xdp.h b/include/trace/events/xdp.h
index 1eebad55ebd4..862575ac8da9 100644
--- a/include/trace/events/xdp.h
+++ b/include/trace/events/xdp.h
@@ -77,13 +77,11 @@ DECLARE_EVENT_CLASS(xdp_redirect_template,
__entry->map_index = map_index;
),
- TP_printk("prog_id=%d action=%s ifindex=%d to_ifindex=%d err=%d"
- " map_id=%d map_index=%d",
+ TP_printk("prog_id=%d action=%s ifindex=%d to_ifindex=%d err=%d",
__entry->prog_id,
__print_symbolic(__entry->act, __XDP_ACT_SYM_TAB),
__entry->ifindex, __entry->to_ifindex,
- __entry->err,
- __entry->map_id, __entry->map_index)
+ __entry->err)
);
DEFINE_EVENT(xdp_redirect_template, xdp_redirect,
@@ -108,11 +106,43 @@ DEFINE_EVENT(xdp_redirect_template, xdp_redirect_err,
#define _trace_xdp_redirect_err(dev, xdp, to, err) \
trace_xdp_redirect_err(dev, xdp, to, err, NULL, 0);
-#define trace_xdp_redirect_map(dev, xdp, fwd, map, idx) \
- trace_xdp_redirect(dev, xdp, fwd ? fwd->ifindex : 0, 0, map, idx);
+DEFINE_EVENT_PRINT(xdp_redirect_template, xdp_redirect_map,
+ TP_PROTO(const struct net_device *dev,
+ const struct bpf_prog *xdp,
+ int to_ifindex, int err,
+ const struct bpf_map *map, u32 map_index),
+ TP_ARGS(dev, xdp, to_ifindex, err, map, map_index),
+ TP_printk("prog_id=%d action=%s ifindex=%d to_ifindex=%d err=%d"
+ " map_id=%d map_index=%d",
+ __entry->prog_id,
+ __print_symbolic(__entry->act, __XDP_ACT_SYM_TAB),
+ __entry->ifindex, __entry->to_ifindex,
+ __entry->err,
+ __entry->map_id, __entry->map_index)
+);
+
+DEFINE_EVENT_PRINT(xdp_redirect_template, xdp_redirect_map_err,
+ TP_PROTO(const struct net_device *dev,
+ const struct bpf_prog *xdp,
+ int to_ifindex, int err,
+ const struct bpf_map *map, u32 map_index),
+ TP_ARGS(dev, xdp, to_ifindex, err, map, map_index),
+ TP_printk("prog_id=%d action=%s ifindex=%d to_ifindex=%d err=%d"
+ " map_id=%d map_index=%d",
+ __entry->prog_id,
+ __print_symbolic(__entry->act, __XDP_ACT_SYM_TAB),
+ __entry->ifindex, __entry->to_ifindex,
+ __entry->err,
+ __entry->map_id, __entry->map_index)
+);
+
+#define _trace_xdp_redirect_map(dev, xdp, fwd, map, idx) \
+ trace_xdp_redirect_map(dev, xdp, fwd ? fwd->ifindex : 0, \
+ 0, map, idx);
-#define trace_xdp_redirect_map_err(dev, xdp, fwd, map, idx, err) \
- trace_xdp_redirect_err(dev, xdp, fwd ? fwd->ifindex : 0, err, map, idx);
+#define _trace_xdp_redirect_map_err(dev, xdp, fwd, map, idx, err) \
+ trace_xdp_redirect_map_err(dev, xdp, fwd ? fwd->ifindex : 0, \
+ err, map, idx);
#endif /* _TRACE_XDP_H */
diff --git a/net/core/filter.c b/net/core/filter.c
index 096e78de0b97..c6a37fe0285b 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -2525,10 +2525,10 @@ static int xdp_do_redirect_map(struct net_device *dev, struct xdp_buff *xdp,
goto err;
ri->map_to_flush = map;
- trace_xdp_redirect_map(dev, xdp_prog, fwd, map, index);
+ _trace_xdp_redirect_map(dev, xdp_prog, fwd, map, index);
return 0;
err:
- trace_xdp_redirect_map_err(dev, xdp_prog, fwd, map, index, err);
+ _trace_xdp_redirect_map_err(dev, xdp_prog, fwd, map, index, err);
return err;
}
^ permalink raw reply related
* [PATCH net-next 6/7] samples/bpf: xdp_redirect load XDP dummy prog on TX device
From: Jesper Dangaard Brouer @ 2017-08-29 14:38 UTC (permalink / raw)
To: netdev; +Cc: John Fastabend, Jesper Dangaard Brouer
In-Reply-To: <150401743083.16384.15778781741742858567.stgit@firesoul>
For supporting XDP_REDIRECT, a device driver must (obviously)
implement the "TX" function ndo_xdp_xmit(). An additional requirement
is you cannot TX out a device, unless it also have a xdp bpf program
attached. This dependency is caused by the driver code need to setup
XDP resources before it can ndo_xdp_xmit.
Update bpf samples xdp_redirect and xdp_redirect_map to automatically
attach a dummy XDP program to the configured ifindex_out device. Use
the XDP flag XDP_FLAGS_UPDATE_IF_NOEXIST on the dummy load, to avoid
overriding an existing XDP prog on the device.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
---
samples/bpf/xdp_redirect_kern.c | 11 ++++++++++-
samples/bpf/xdp_redirect_map_kern.c | 11 ++++++++++-
samples/bpf/xdp_redirect_map_user.c | 22 +++++++++++++++-------
samples/bpf/xdp_redirect_user.c | 21 +++++++++++++++------
4 files changed, 50 insertions(+), 15 deletions(-)
diff --git a/samples/bpf/xdp_redirect_kern.c b/samples/bpf/xdp_redirect_kern.c
index a34ad457a684..1c90288d0203 100644
--- a/samples/bpf/xdp_redirect_kern.c
+++ b/samples/bpf/xdp_redirect_kern.c
@@ -26,6 +26,9 @@ struct bpf_map_def SEC("maps") tx_port = {
.max_entries = 1,
};
+/* Count RX packets, as XDP bpf_prog doesn't get direct TX-success
+ * feedback. Redirect TX errors can be caught via a tracepoint.
+ */
struct bpf_map_def SEC("maps") rxcnt = {
.type = BPF_MAP_TYPE_PERCPU_ARRAY,
.key_size = sizeof(u32),
@@ -33,7 +36,6 @@ struct bpf_map_def SEC("maps") rxcnt = {
.max_entries = 1,
};
-
static void swap_src_dst_mac(void *data)
{
unsigned short *p = data;
@@ -78,4 +80,11 @@ int xdp_redirect_prog(struct xdp_md *ctx)
return bpf_redirect(*ifindex, 0);
}
+/* Redirect require an XDP bpf_prog loaded on the TX device */
+SEC("xdp_redirect_dummy")
+int xdp_redirect_dummy(struct xdp_md *ctx)
+{
+ return XDP_PASS;
+}
+
char _license[] SEC("license") = "GPL";
diff --git a/samples/bpf/xdp_redirect_map_kern.c b/samples/bpf/xdp_redirect_map_kern.c
index 2faf196e17ea..79795d41ad0d 100644
--- a/samples/bpf/xdp_redirect_map_kern.c
+++ b/samples/bpf/xdp_redirect_map_kern.c
@@ -26,6 +26,9 @@ struct bpf_map_def SEC("maps") tx_port = {
.max_entries = 100,
};
+/* Count RX packets, as XDP bpf_prog doesn't get direct TX-success
+ * feedback. Redirect TX errors can be caught via a tracepoint.
+ */
struct bpf_map_def SEC("maps") rxcnt = {
.type = BPF_MAP_TYPE_PERCPU_ARRAY,
.key_size = sizeof(u32),
@@ -33,7 +36,6 @@ struct bpf_map_def SEC("maps") rxcnt = {
.max_entries = 1,
};
-
static void swap_src_dst_mac(void *data)
{
unsigned short *p = data;
@@ -80,4 +82,11 @@ int xdp_redirect_map_prog(struct xdp_md *ctx)
return bpf_redirect_map(&tx_port, vport, 0);
}
+/* Redirect require an XDP bpf_prog loaded on the TX device */
+SEC("xdp_redirect_dummy")
+int xdp_redirect_dummy(struct xdp_md *ctx)
+{
+ return XDP_PASS;
+}
+
char _license[] SEC("license") = "GPL";
diff --git a/samples/bpf/xdp_redirect_map_user.c b/samples/bpf/xdp_redirect_map_user.c
index a1ad00fdaa8a..d4d86a273fba 100644
--- a/samples/bpf/xdp_redirect_map_user.c
+++ b/samples/bpf/xdp_redirect_map_user.c
@@ -16,6 +16,7 @@
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
+#include <stdbool.h>
#include <string.h>
#include <unistd.h>
#include <libgen.h>
@@ -26,17 +27,18 @@
static int ifindex_in;
static int ifindex_out;
+static bool ifindex_out_xdp_dummy_attached = true;
static __u32 xdp_flags;
static void int_exit(int sig)
{
set_link_xdp_fd(ifindex_in, -1, xdp_flags);
+ if (ifindex_out_xdp_dummy_attached)
+ set_link_xdp_fd(ifindex_out, -1, xdp_flags);
exit(0);
}
-/* simple per-protocol drop counter
- */
static void poll_stats(int interval, int ifindex)
{
unsigned int nr_cpus = bpf_num_possible_cpus();
@@ -70,7 +72,6 @@ static void usage(const char *prog)
prog);
}
-
int main(int argc, char **argv)
{
const char *optstr = "SN";
@@ -112,14 +113,21 @@ int main(int argc, char **argv)
return 1;
}
- signal(SIGINT, int_exit);
- signal(SIGTERM, int_exit);
-
if (set_link_xdp_fd(ifindex_in, prog_fd[0], xdp_flags) < 0) {
- printf("link set xdp fd failed\n");
+ printf("ERROR: link set xdp fd failed on %d\n", ifindex_in);
return 1;
}
+ /* Loading dummy XDP prog on out-device */
+ if (set_link_xdp_fd(ifindex_out, prog_fd[1],
+ (xdp_flags | XDP_FLAGS_UPDATE_IF_NOEXIST)) < 0) {
+ printf("WARN: link set xdp fd failed on %d\n", ifindex_out);
+ ifindex_out_xdp_dummy_attached = false;
+ }
+
+ signal(SIGINT, int_exit);
+ signal(SIGTERM, int_exit);
+
printf("map[0] (vports) = %i, map[1] (map) = %i, map[2] (count) = %i\n",
map_fd[0], map_fd[1], map_fd[2]);
diff --git a/samples/bpf/xdp_redirect_user.c b/samples/bpf/xdp_redirect_user.c
index f705a1905d2d..4475d837bf2c 100644
--- a/samples/bpf/xdp_redirect_user.c
+++ b/samples/bpf/xdp_redirect_user.c
@@ -16,6 +16,7 @@
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
+#include <stdbool.h>
#include <string.h>
#include <unistd.h>
#include <libgen.h>
@@ -26,17 +27,18 @@
static int ifindex_in;
static int ifindex_out;
+static bool ifindex_out_xdp_dummy_attached = true;
static __u32 xdp_flags;
static void int_exit(int sig)
{
set_link_xdp_fd(ifindex_in, -1, xdp_flags);
+ if (ifindex_out_xdp_dummy_attached)
+ set_link_xdp_fd(ifindex_out, -1, xdp_flags);
exit(0);
}
-/* simple per-protocol drop counter
- */
static void poll_stats(int interval, int ifindex)
{
unsigned int nr_cpus = bpf_num_possible_cpus();
@@ -112,14 +114,21 @@ int main(int argc, char **argv)
return 1;
}
- signal(SIGINT, int_exit);
- signal(SIGTERM, int_exit);
-
if (set_link_xdp_fd(ifindex_in, prog_fd[0], xdp_flags) < 0) {
- printf("link set xdp fd failed\n");
+ printf("ERROR: link set xdp fd failed on %d\n", ifindex_in);
return 1;
}
+ /* Loading dummy XDP prog on out-device */
+ if (set_link_xdp_fd(ifindex_out, prog_fd[1],
+ (xdp_flags | XDP_FLAGS_UPDATE_IF_NOEXIST)) < 0) {
+ printf("WARN: link set xdp fd failed on %d\n", ifindex_out);
+ ifindex_out_xdp_dummy_attached = false;
+ }
+
+ signal(SIGINT, int_exit);
+ signal(SIGTERM, int_exit);
+
/* bpf redirect port */
ret = bpf_map_update_elem(map_fd[0], &key, &ifindex_out, 0);
if (ret) {
^ permalink raw reply related
* [PATCH net-next 7/7] samples/bpf: xdp_monitor tool based on tracepoints
From: Jesper Dangaard Brouer @ 2017-08-29 14:38 UTC (permalink / raw)
To: netdev; +Cc: John Fastabend, Jesper Dangaard Brouer
In-Reply-To: <150401743083.16384.15778781741742858567.stgit@firesoul>
This tool xdp_monitor demonstrate how to use the different xdp_redirect
tracepoints xdp_redirect{,_map}{,_err} from a BPF program.
The default mode is to only monitor the error counters, to avoid
affecting the per packet performance. Tracepoints comes with a base
overhead of 25 nanosec for an attached bpf_prog, and 48 nanosec for
using a full perf record (with non-matching filter). Thus, default
loading the --stats mode could affect the maximum performance.
This version of the tool is very simple and count all types of errors
as one. It will be natural to extend this later with the different
types of errors that can occur, which should help users quickly
identify common mistakes.
Because the TP_STRUCT was kept in sync all the tracepoints loads the
same BPF code. It would also be natural to extend the map version to
demonstrate how the map information could be used.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
---
samples/bpf/Makefile | 4 +
samples/bpf/xdp_monitor_kern.c | 88 ++++++++++++
samples/bpf/xdp_monitor_user.c | 295 ++++++++++++++++++++++++++++++++++++++++
3 files changed, 387 insertions(+)
create mode 100644 samples/bpf/xdp_monitor_kern.c
create mode 100644 samples/bpf/xdp_monitor_user.c
diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
index f1010fe759fe..cf17c7932a6e 100644
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -39,6 +39,7 @@ hostprogs-y += per_socket_stats_example
hostprogs-y += load_sock_ops
hostprogs-y += xdp_redirect
hostprogs-y += xdp_redirect_map
+hostprogs-y += xdp_monitor
hostprogs-y += syscall_tp
# Libbpf dependencies
@@ -83,6 +84,7 @@ test_map_in_map-objs := bpf_load.o $(LIBBPF) test_map_in_map_user.o
per_socket_stats_example-objs := $(LIBBPF) cookie_uid_helper_example.o
xdp_redirect-objs := bpf_load.o $(LIBBPF) xdp_redirect_user.o
xdp_redirect_map-objs := bpf_load.o $(LIBBPF) xdp_redirect_map_user.o
+xdp_monitor-objs := bpf_load.o $(LIBBPF) xdp_monitor_user.o
syscall_tp-objs := bpf_load.o $(LIBBPF) syscall_tp_user.o
# Tell kbuild to always build the programs
@@ -127,6 +129,7 @@ always += tcp_iw_kern.o
always += tcp_clamp_kern.o
always += xdp_redirect_kern.o
always += xdp_redirect_map_kern.o
+always += xdp_monitor_kern.o
always += syscall_tp_kern.o
HOSTCFLAGS += -I$(objtree)/usr/include
@@ -166,6 +169,7 @@ HOSTLOADLIBES_xdp_tx_iptunnel += -lelf
HOSTLOADLIBES_test_map_in_map += -lelf
HOSTLOADLIBES_xdp_redirect += -lelf
HOSTLOADLIBES_xdp_redirect_map += -lelf
+HOSTLOADLIBES_xdp_monitor += -lelf
HOSTLOADLIBES_syscall_tp += -lelf
# Allows pointing LLC/CLANG to a LLVM backend with bpf support, redefine on cmdline:
diff --git a/samples/bpf/xdp_monitor_kern.c b/samples/bpf/xdp_monitor_kern.c
new file mode 100644
index 000000000000..74f3fd8ed729
--- /dev/null
+++ b/samples/bpf/xdp_monitor_kern.c
@@ -0,0 +1,88 @@
+/* XDP monitor tool, based on tracepoints
+ *
+ * Copyright(c) 2017 Jesper Dangaard Brouer, Red Hat Inc.
+ */
+#include <uapi/linux/bpf.h>
+#include "bpf_helpers.h"
+
+struct bpf_map_def SEC("maps") redirect_err_cnt = {
+ .type = BPF_MAP_TYPE_PERCPU_ARRAY,
+ .key_size = sizeof(u32),
+ .value_size = sizeof(u64),
+ .max_entries = 2,
+ /* TODO: have entries for all possible errno's */
+};
+
+/* Tracepoint format: /sys/kernel/debug/tracing/events/xdp/xdp_redirect/format
+ * Code in: kernel/include/trace/events/xdp.h
+ */
+struct xdp_redirect_ctx {
+ unsigned short common_type; // offset:0; size:2; signed:0;
+ unsigned char common_flags; // offset:2; size:1; signed:0;
+ unsigned char common_preempt_count;// offset:3; size:1; signed:0;
+ int common_pid; // offset:4; size:4; signed:1;
+
+ int prog_id; // offset:8; size:4; signed:1;
+ u32 act; // offset:12 size:4; signed:0;
+ int ifindex; // offset:16 size:4; signed:1;
+ int err; // offset:20 size:4; signed:1;
+ int to_ifindex; // offset:24 size:4; signed:1;
+ u32 map_id; // offset:28 size:4; signed:0;
+ int map_index; // offset:32 size:4; signed:1;
+}; // offset:36
+
+enum {
+ XDP_REDIRECT_SUCCESS = 0,
+ XDP_REDIRECT_ERROR = 1
+};
+
+static __always_inline
+int xdp_redirect_collect_stat(struct xdp_redirect_ctx *ctx)
+{
+ u32 key = XDP_REDIRECT_ERROR;
+ int err = ctx->err;
+ u64 *cnt;
+
+ if (!err)
+ key = XDP_REDIRECT_SUCCESS;
+
+ cnt = bpf_map_lookup_elem(&redirect_err_cnt, &key);
+ if (!cnt)
+ return 0;
+ *cnt += 1;
+
+ return 0; /* Indicate event was filtered (no further processing)*/
+ /*
+ * Returning 1 here would allow e.g. a perf-record tracepoint
+ * to see and record these events, but it doesn't work well
+ * in-practice as stopping perf-record also unload this
+ * bpf_prog. Plus, there is additional overhead of doing so.
+ */
+}
+
+SEC("tracepoint/xdp/xdp_redirect_err")
+int trace_xdp_redirect_err(struct xdp_redirect_ctx *ctx)
+{
+ return xdp_redirect_collect_stat(ctx);
+}
+
+
+SEC("tracepoint/xdp/xdp_redirect_map_err")
+int trace_xdp_redirect_map_err(struct xdp_redirect_ctx *ctx)
+{
+ return xdp_redirect_collect_stat(ctx);
+}
+
+/* Likely unloaded when prog starts */
+SEC("tracepoint/xdp/xdp_redirect")
+int trace_xdp_redirect(struct xdp_redirect_ctx *ctx)
+{
+ return xdp_redirect_collect_stat(ctx);
+}
+
+/* Likely unloaded when prog starts */
+SEC("tracepoint/xdp/xdp_redirect_map")
+int trace_xdp_redirect_map(struct xdp_redirect_ctx *ctx)
+{
+ return xdp_redirect_collect_stat(ctx);
+}
diff --git a/samples/bpf/xdp_monitor_user.c b/samples/bpf/xdp_monitor_user.c
new file mode 100644
index 000000000000..b51b4f5e3257
--- /dev/null
+++ b/samples/bpf/xdp_monitor_user.c
@@ -0,0 +1,295 @@
+/* Copyright(c) 2017 Jesper Dangaard Brouer, Red Hat, Inc.
+ */
+static const char *__doc__=
+ "XDP monitor tool, based on tracepoints\n"
+;
+
+static const char *__doc_err_only__=
+ " NOTICE: Only tracking XDP redirect errors\n"
+ " Enable TX success stats via '--stats'\n"
+ " (which comes with a per packet processing overhead)\n"
+;
+
+#include <errno.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <stdbool.h>
+#include <stdint.h>
+#include <string.h>
+#include <ctype.h>
+#include <unistd.h>
+#include <locale.h>
+
+#include <getopt.h>
+#include <net/if.h>
+#include <time.h>
+
+#include "libbpf.h"
+#include "bpf_load.h"
+#include "bpf_util.h"
+
+static int verbose = 1;
+static bool debug = false;
+
+static const struct option long_options[] = {
+ {"help", no_argument, NULL, 'h' },
+ {"debug", no_argument, NULL, 'D' },
+ {"stats", no_argument, NULL, 'S' },
+ {"sec", required_argument, NULL, 's' },
+ {0, 0, NULL, 0 }
+};
+
+static void usage(char *argv[])
+{
+ int i;
+ printf("\nDOCUMENTATION:\n%s\n", __doc__);
+ printf("\n");
+ printf(" Usage: %s (options-see-below)\n",
+ argv[0]);
+ printf(" Listing options:\n");
+ for (i = 0; long_options[i].name != 0; i++) {
+ printf(" --%-15s", long_options[i].name);
+ if (long_options[i].flag != NULL)
+ printf(" flag (internal value:%d)",
+ *long_options[i].flag);
+ else
+ printf("(internal short-option: -%c)",
+ long_options[i].val);
+ printf("\n");
+ }
+ printf("\n");
+}
+
+#define NANOSEC_PER_SEC 1000000000 /* 10^9 */
+__u64 gettime(void)
+{
+ struct timespec t;
+ int res;
+
+ res = clock_gettime(CLOCK_MONOTONIC, &t);
+ if (res < 0) {
+ fprintf(stderr, "Error with gettimeofday! (%i)\n", res);
+ exit(EXIT_FAILURE);
+ }
+ return (__u64) t.tv_sec * NANOSEC_PER_SEC + t.tv_nsec;
+}
+
+enum {
+ REDIR_SUCCESS = 0,
+ REDIR_ERROR = 1,
+};
+#define REDIR_RES_MAX 2
+static const char *redir_names[REDIR_RES_MAX] = {
+ [REDIR_SUCCESS] = "Success",
+ [REDIR_ERROR] = "Error",
+};
+static const char *err2str(int err)
+{
+ if (err < REDIR_RES_MAX)
+ return redir_names[err];
+ return NULL;
+}
+
+struct record {
+ __u64 counter;
+ __u64 timestamp;
+};
+
+struct stats_record {
+ struct record xdp_redir[REDIR_RES_MAX];
+};
+
+static void stats_print_headers(bool err_only)
+{
+ if (err_only)
+ printf("\n%s\n", __doc_err_only__);
+
+ printf("%-14s %-10s %-18s %-9s\n",
+ "XDP_REDIRECT", "pps ", "pps-human-readable", "measure-period");
+}
+
+static void stats_print(struct stats_record *rec,
+ struct stats_record *prev,
+ bool err_only)
+{
+ int i = 0;
+
+ if (err_only)
+ i = REDIR_ERROR;
+
+ for (; i < REDIR_RES_MAX; i++) {
+ struct record *r = &rec->xdp_redir[i];
+ struct record *p = &prev->xdp_redir[i];
+ __u64 period = 0;
+ __u64 packets = 0;
+ double pps = 0;
+ double period_ = 0;
+
+ if (p->timestamp) {
+ packets = r->counter - p->counter;
+ period = r->timestamp - p->timestamp;
+ if (period > 0) {
+ period_ = ((double) period / NANOSEC_PER_SEC);
+ pps = packets / period_;
+ }
+ }
+
+ printf("%-14s %-10.0f %'-18.0f %f\n",
+ err2str(i), pps, pps, period_);
+ }
+}
+
+static __u64 get_key32_value64_percpu(int fd, __u32 key)
+{
+ /* For percpu maps, userspace gets a value per possible CPU */
+ unsigned int nr_cpus = bpf_num_possible_cpus();
+ __u64 values[nr_cpus];
+ __u64 sum = 0;
+ int i;
+
+ if ((bpf_map_lookup_elem(fd, &key, values)) != 0) {
+ fprintf(stderr,
+ "ERR: bpf_map_lookup_elem failed key:0x%X\n", key);
+ return 0;
+ }
+
+ /* Sum values from each CPU */
+ for (i = 0; i < nr_cpus; i++) {
+ sum += values[i];
+ }
+ return sum;
+}
+
+static bool stats_collect(int fd, struct stats_record *rec)
+{
+ int i;
+
+ /* TODO: Detect if someone unloaded the perf event_fd's, as
+ * this can happen by someone running perf-record -e
+ */
+
+ for (i = 0; i < REDIR_RES_MAX; i++) {
+ rec->xdp_redir[i].timestamp = gettime();
+ rec->xdp_redir[i].counter = get_key32_value64_percpu(fd, i);
+ }
+ return true;
+}
+
+static void stats_poll(int interval, bool err_only)
+{
+ struct stats_record rec, prev;
+ int map_fd;
+
+ memset(&rec, 0, sizeof(rec));
+
+ /* Trick to pretty printf with thousands separators use %' */
+ setlocale(LC_NUMERIC, "en_US");
+
+ /* Header */
+ if (verbose)
+ printf("\n%s", __doc__);
+
+ /* TODO Need more advanced stats on error types */
+ if (verbose)
+ printf(" - Stats map: %s\n", map_data[0].name);
+ map_fd = map_data[0].fd;
+
+ stats_print_headers(err_only);
+ fflush(stdout);
+
+ while (1) {
+ memcpy(&prev, &rec, sizeof(rec));
+ stats_collect(map_fd, &rec);
+ stats_print(&rec, &prev, err_only);
+ fflush(stdout);
+ sleep(interval);
+ }
+}
+
+void print_bpf_prog_info(void)
+{
+ int i;
+
+ /* Prog info */
+ printf("Loaded BPF prog have %d bpf program(s)\n", prog_cnt);
+ for (i = 0; i < prog_cnt; i++) {
+ printf(" - prog_fd[%d] = fd(%d)\n", i, prog_fd[i]);
+ }
+
+ /* Maps info */
+ printf("Loaded BPF prog have %d map(s)\n", map_data_count);
+ for (i = 0; i < map_data_count; i++) {
+ char *name = map_data[i].name;
+ int fd = map_data[i].fd;
+
+ printf(" - map_data[%d] = fd(%d) name:%s\n", i, fd, name);
+ }
+
+ /* Event info */
+ printf("Searching for (max:%d) event file descriptor(s)\n", prog_cnt);
+ for (i = 0; i < prog_cnt; i++) {
+ if (event_fd[i] != -1)
+ printf(" - event_fd[%d] = fd(%d)\n", i, event_fd[i]);
+ }
+}
+
+int main(int argc, char **argv)
+{
+ int longindex = 0, opt;
+ int ret = EXIT_SUCCESS;
+ char bpf_obj_file[256];
+
+ /* Default settings: */
+ bool errors_only = true;
+ int interval = 2;
+
+ snprintf(bpf_obj_file, sizeof(bpf_obj_file), "%s_kern.o", argv[0]);
+
+ /* Parse commands line args */
+ while ((opt = getopt_long(argc, argv, "h",
+ long_options, &longindex)) != -1) {
+ switch (opt) {
+ case 'D':
+ debug = true;
+ break;
+ case 'S':
+ errors_only = false;
+ break;
+ case 's':
+ interval = atoi(optarg);
+ break;
+ case 'h':
+ default:
+ usage(argv);
+ return EXIT_FAILURE;
+ }
+ }
+
+ if (load_bpf_file(bpf_obj_file)) {
+ printf("ERROR - bpf_log_buf: %s", bpf_log_buf);
+ return 1;
+ }
+ if (!prog_fd[0]) {
+ printf("ERROR - load_bpf_file: %s\n", strerror(errno));
+ return 1;
+ }
+
+ if (debug) {
+ print_bpf_prog_info();
+ }
+
+ /* Unload/stop tracepoint event by closing fd's */
+ if (errors_only) {
+ /* The prog_fd[i] and event_fd[i] depend on the
+ * order the functions was defined in _kern.c
+ */
+ close(event_fd[2]); /* tracepoint/xdp/xdp_redirect */
+ close(prog_fd[2]); /* func: trace_xdp_redirect */
+ close(event_fd[3]); /* tracepoint/xdp/xdp_redirect_map */
+ close(prog_fd[3]); /* func: trace_xdp_redirect_map */
+ }
+
+ stats_poll(interval, errors_only);
+
+ return ret;
+}
^ permalink raw reply related
* Re: [PATCH] staging: r8822be: Fix typo for CONFIG_RTLWIFI_DEBUG
From: Greg KH @ 2017-08-29 14:42 UTC (permalink / raw)
To: Larry Finger
Cc: Andreas Ziegler, devel, Yan-Hsuan Chuang, Birming Chiu, netdev,
Steven Ting
In-Reply-To: <fcab4e04-be42-5a05-c5ad-4947d2d41164@lwfinger.net>
On Tue, Aug 29, 2017 at 09:10:10AM -0500, Larry Finger wrote:
> On 08/29/2017 06:30 AM, Andreas Ziegler wrote:
> > The debugging output in deinit_priv is guarded by an #ifdef using
> > CONFIG_RTL_DEBUG. This symbol does not exist and should be
> > CONFIG_RTLWIFI_DEBUG instead.
> >
> > Signed-off-by: Andreas Ziegler <andreas.ziegler@fau.de>
>
> NACK.
>
> Yes, there is a problem; however, CONFIG_RTLWIFI_DEBUG is not the value that
> should be used. That one is reserved for the non-staging drivers in
> drivers/net/wireless/realtek/rtlwifi/. The correct symbol for r8822be is
> CONFIG_RTLWIFI_DEBUG_ST.
Yeah, kbuild just blew up on this as well, I wonder why my local build
testing didn't see that :(
Now dropped.
greg k-h
^ permalink raw reply
* Re: [PATCH 0/4] irda: move it to drivers/staging so we can delete it
From: Greg Kroah-Hartman @ 2017-08-29 14:48 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: driverdevel, Samuel Ortiz, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Stefano Brivio, David S. Miller
In-Reply-To: <CAMuHMdVb-oygJkkHwBOfSmNECAfF72QruJSmVTpqdUW+RNJbrg@mail.gmail.com>
On Tue, Aug 29, 2017 at 02:11:39PM +0200, Geert Uytterhoeven wrote:
> Hi Greg,
>
> On Tue, Aug 29, 2017 at 1:28 PM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Tue, Aug 29, 2017 at 01:11:31PM +0200, Stefano Brivio wrote:
> >> On Tue, 29 Aug 2017 12:59:00 +0200
> >> Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> >> > On Sun, Aug 27, 2017 at 5:03 PM, Greg Kroah-Hartman
> >> > <gregkh@linuxfoundation.org> wrote:
> >> > > The IRDA code has long been obsolete and broken. So, to keep people
> >> > > from trying to use it, and to prevent people from having to maintain it,
> >> > > let's move it to drivers/staging/ so that we can delete it entirely from
> >> > > the kernel in a few releases.
> >> >
> >> > (diving into an early boot crash)
> >> >
> >> > Have you tried running this? ;-)
> >> >
> >> > irda_init() and net_dev_init() are both subsys_initcall()s.
> >> > But the former now runs before the latter, leading to:
> >> >
> >> > Unable to handle kernel NULL pointer dereference at virtual address 00000004
> >>
> >> Should be fixed by https://patchwork.ozlabs.org/patch/807006/
> >> ("[net-next] staging: irda: force to be a kernel module") I guess...
> >
> > Yup, that's the fix for this issue.
> >
> > Geert, does that fix the problem for you?
>
> Thanks, that patch fixes the crash, obviously.
>
> It does mean you can no longer have IrDA in a non-modular kernel.
Given that irda doesn't really work, I doubt anyone is going to care
about it :)
thanks,
greg k-h
^ permalink raw reply
* Re: net.ipv4.tcp_max_syn_backlog implementation
From: Harsha Chenji @ 2017-08-29 15:05 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1503980243.11498.69.camel@edumazet-glaptop3.roam.corp.google.com>
According to the man:
The behavior of the backlog argument on TCP sockets changed with Linux
2.2. Now it specifies the queue length for *completely established
sockets waiting to be accepted*, instead of the number of incomplete
connection requests. The maximum length of the queue for incomplete
sockets can be set using /proc/sys/net/ipv4/tcp_max_syn_backlog. When
syncookies are enabled there is no logical maximum length and this
setting is ignored. See tcp(7) for more information.
On Tue, Aug 29, 2017 at 12:17 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Mon, 2017-08-28 at 23:47 -0400, Harsha Chenji wrote:
>> So I have ubuntu 12.04 x32 in a VM with syncookies turned off. I tried
>> to do a syn flood (with netwox) on 3 different processes. Each of them
>> returns a different value with netstat -na | grep -c RECV :
>>
>> nc -l 5555 returns 16 (netcat-traditional)
>> apache2 port 80 returns 256
>> vsftpd on 21 returns 64.
>> net.ipv4.tcp_max_syn_backlog is 512.
>>
>> Why do these different processes on different ports have different
>> queue lengths for incomplete connections? Where exactly in the kernel
>> is this decided?
>
> See 2nd argument in listen() system call, ie backlog
>
> man listen
>
> Without a synflood, just look at "ss -t state listening"
>
> The backlog is the 2nd column (Send)
>
>
>
^ permalink raw reply
* [iproute PATCH] lib/bpf: Fix bytecode-file parsing
From: Phil Sutter @ 2017-08-29 15:09 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Daniel Borkmann
The signedness of char type is implementation dependent, and there are
architectures on which it is unsigned by default. In that case, the
check whether fgetc() returned EOF failed because the return value was
assigned an (unsigned) char variable prior to comparison with EOF (which
is defined to -1). Fix this by using int as type for 'c' variable, which
also matches the declaration of fgetc().
While being at it, fix the parser logic to correctly handle multiple
empty lines and consecutive whitespace and tab characters to further
improve the parser's robustness. Note that this will still detect double
separator characters, so doesn't soften up the parser too much.
Fixes: 3da3ebfca85b8 ("bpf: Make bytecode-file reading a little more robust")
Cc: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
lib/bpf.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/lib/bpf.c b/lib/bpf.c
index 0bd0a95eafe6c..77eb8ee27114f 100644
--- a/lib/bpf.c
+++ b/lib/bpf.c
@@ -208,8 +208,9 @@ static int bpf_parse_string(char *arg, bool from_file, __u16 *bpf_len,
if (from_file) {
size_t tmp_len, op_len = sizeof("65535 255 255 4294967295,");
- char *tmp_string, *pos, c, c_prev = ' ';
+ char *tmp_string, *pos, c_prev = ' ';
FILE *fp;
+ int c;
tmp_len = sizeof("4096,") + BPF_MAXINSNS * op_len;
tmp_string = pos = calloc(1, tmp_len);
@@ -228,18 +229,20 @@ static int bpf_parse_string(char *arg, bool from_file, __u16 *bpf_len,
case '\n':
if (c_prev != ',')
*(pos++) = ',';
+ c_prev = ',';
break;
case ' ':
case '\t':
if (c_prev != ' ')
*(pos++) = c;
+ c_prev = ' ';
break;
default:
*(pos++) = c;
+ c_prev = c;
}
if (pos - tmp_string == tmp_len)
break;
- c_prev = c;
}
if (!feof(fp)) {
--
2.13.1
^ permalink raw reply related
* Re: [PATCH net-next] Revert "ipv4: make net_protocol const"
From: Stephen Hemminger @ 2017-08-29 15:14 UTC (permalink / raw)
To: Bhumika Goyal; +Cc: David Ahern, netdev, David Miller
In-Reply-To: <CAOH+1jF3G+Yo30Tk=cgnAPfD8UNe+FkkLjC1uGUd9eeG-ce5KA@mail.gmail.com>
On Tue, 29 Aug 2017 12:16:23 +0530
Bhumika Goyal <bhumirks@gmail.com> wrote:
> On Tue, Aug 29, 2017 at 1:53 AM, David Ahern <dsahern@gmail.com> wrote:
> > This reverts commit aa8db499ea67cff1f5f049033810ffede2fe5ae4.
> >
> > Early demux structs can not be made const. Doing so results in:
> > [ 84.967355] BUG: unable to handle kernel paging request at ffffffff81684b10
> > [ 84.969272] IP: proc_configure_early_demux+0x1e/0x3d
> > [ 84.970544] PGD 1a0a067
> > [ 84.970546] P4D 1a0a067
> > [ 84.971212] PUD 1a0b063
> > [ 84.971733] PMD 80000000016001e1
> >
> > [ 84.972669] Oops: 0003 [#1] SMP
> > [ 84.973065] Modules linked in: ip6table_filter ip6_tables veth vrf
> > [ 84.973833] CPU: 0 PID: 955 Comm: sysctl Not tainted 4.13.0-rc6+ #22
> > [ 84.974612] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
> > [ 84.975855] task: ffff88003854ce00 task.stack: ffffc900005a4000
> > [ 84.976580] RIP: 0010:proc_configure_early_demux+0x1e/0x3d
> > [ 84.977253] RSP: 0018:ffffc900005a7dd0 EFLAGS: 00010246
> > [ 84.977891] RAX: ffffffff81684b10 RBX: 0000000000000001 RCX: 0000000000000000
> > [ 84.978759] RDX: 0000000000000000 RSI: 0000000000000006 RDI: 0000000000000000
> > [ 84.979628] RBP: ffffc900005a7dd0 R08: 0000000000000000 R09: 0000000000000000
> > [ 84.980501] R10: 0000000000000001 R11: 0000000000000008 R12: 0000000000000001
> > [ 84.981373] R13: ffffffffffffffea R14: ffffffff81a9b4c0 R15: 0000000000000002
> > [ 84.982249] FS: 00007feb237b7700(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000
> > [ 84.983231] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [ 84.983941] CR2: ffffffff81684b10 CR3: 0000000038492000 CR4: 00000000000406f0
> > [ 84.984817] Call Trace:
> > [ 84.985133] proc_tcp_early_demux+0x29/0x30
> >
> > I think this is the second time such a patch has been reverted.
> >
> > Cc: Bhumika Goyal <bhumirks@gmail.com>
> > Signed-off-by: David Ahern <dsahern@gmail.com>
> > ---
> > Bhumika: How are you testing these constify changes? In this case a simple
> > sysctl -w net.ipv4.tcp_early_demux=1 would have shown the problem
> >
>
> I am compile testing them. In this case I did: make
> net/ipv4/af_inet.o and it compiled. Is this error because of
> typecasting net_protocol inside inet_add_protocol function?
>
> Thanks,
> Bhumika
>
>
> > net/ipv4/af_inet.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
> > index 19aee073ba29..d678820e4306 100644
> > --- a/net/ipv4/af_inet.c
> > +++ b/net/ipv4/af_inet.c
> > @@ -1596,7 +1596,7 @@ static const struct net_protocol igmp_protocol = {
> > };
> > #endif
> >
> > -static const struct net_protocol tcp_protocol = {
> > +static struct net_protocol tcp_protocol = {
> > .early_demux = tcp_v4_early_demux,
> > .early_demux_handler = tcp_v4_early_demux,
> > .handler = tcp_v4_rcv,
> > @@ -1606,7 +1606,7 @@ static const struct net_protocol tcp_protocol = {
> > .icmp_strict_tag_validation = 1,
> > };
> >
> > -static const struct net_protocol udp_protocol = {
> > +static struct net_protocol udp_protocol = {
> > .early_demux = udp_v4_early_demux,
> > .early_demux_handler = udp_v4_early_demux,
> > .handler = udp_rcv,
> > --
> > 2.1.4
> >
You need to change inet_proto datastructure first.
^ permalink raw reply
* Re: Fwd: DA850-evm MAC Address is random
From: Sekhar Nori @ 2017-08-29 15:16 UTC (permalink / raw)
To: Adam Ford; +Cc: Tony Lindgren, Grygorii Strashko, linux-omap, netdev
In-Reply-To: <CAHCN7xK2=PN5MOr48HOkZnwKwkM4ypcvQct+Ko+ChNFG3Pv62w@mail.gmail.com>
On Tuesday 29 August 2017 05:32 PM, Adam Ford wrote:
> On Tue, Aug 29, 2017 at 6:42 AM, Sekhar Nori <nsekhar@ti.com> wrote:
>> On Tuesday 29 August 2017 03:53 PM, Adam Ford wrote:
>>> On Tue, Aug 29, 2017 at 3:23 AM, Sekhar Nori <nsekhar@ti.com> wrote:
>>>> On Tuesday 29 August 2017 02:42 AM, Tony Lindgren wrote:
>>>>> * Adam Ford <aford173@gmail.com> [170828 13:33]:
>>>>>> On Mon, Aug 28, 2017 at 1:54 PM, Grygorii Strashko
>>>>>> <grygorii.strashko@ti.com> wrote:
>>>>>>> Cc: Sekhar
>>>>>>>
>>>>>>> On 08/28/2017 10:32 AM, Adam Ford wrote:
>>>>>>>>
>>>>>>>> The davinvi_emac MAC address seems to attempt a call to
>>>>>>>> ti_cm_get_macid in cpsw-common.c but it returns the message
>>>>>>>> 'davinci_emac davinci_emac.1: incompatible machine/device type for
>>>>>>>> reading mac address ' and then generates a random MAC address.
>>>>>>>>
>>>>>>>> The function appears to lookup varions boards using
>>>>>>>> 'of_machine_is_compaible' and supports dm8148, am33xx, am3517, dm816,
>>>>>>>> am4372 and dra7. I don't see the ti,davinci-dm6467-emac which is
>>>>>>>> what's shown in the da850 device tree.
>>>>>>>>
>>>>>>>> Is there a patch somewhere for supporting the da850-evm?
>>>>>>>
>>>>>>>
>>>>>>> Not sure if MAC address can be read from Control module.
>>>>>>> May be Sekhar can say more?
>>>>>>
>>>>>> My understanding is that the MAC address is programmed by Logic PD
>>>>>> into the SPI flash. The Bootloader reads this from either SPI or its
>>>>>> env variables. Looking at the partition info listed in the
>>>>>> da850-evm.dts file, it appears as if they've reserved space for it.
>>>>>> Unfortunately, I don't see any code that reads it out. I was hoping
>>>>
>>>> This code is present in U-Boot sources at
>>>> board/davinci/da8xxevm/da850evm.c. See the function get_mac_addr() and
>>>> its usage in misc_init_r().
>>>>
>>>>>> there might be a way to just pass cmdline parameter from the
>>>>>> bootloader to the kernel to accept the MAC address.
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> If not, is there a way to pass the MAC address from U-Boot to the
>>>>>>>> driver so it doesn't generate a random MAC?
>>>>>>>
>>>>>>>
>>>>>>> "local-mac-address" dt porp
>>>>>>
>>>>>> The downside here, is that we'd have to have the Bootloader modify the
>>>>>> device tree.
>>>>>
>>>>> That piece of code exists somewhere in u-boot already. Note how
>>>>
>>>> Yes, it is fdt_fixup_ethernet() and its usage is in common/image-fdt.c.
>>>>
>>>>> we are populating the mac address for USB Ethernet drivers in
>>>>> u-boot and then the Ethernet driver code parses it. See commit
>>>>> 055d31de7158 ("ARM: omap3: beagleboard-xm: dt: Add ethernet to
>>>>> the device tree") for some more information.
>>>>>
>>>>> I think u-boot needs the ethernet alias for finding the interface.
>>>>
>>>> That's exactly what was missing. I have sent a patch for fixing that and
>>>> copied you there.
>>>
>>> Thanks for doing that.
>>>
>>>>
>>>> Adam, if I can get your Tested-by, I will make an attempt to send it for
>>>> v4.13 itself.
>>>
>>> I will test it. Do need to run some instruction or do something
>>> special in U-Boot to pass this in the proper place for the kernel to
>>> pull it? Tony's patch reference showed
>>> command for fdt set, but I am not sure I fully understand the
>>> parameters that went along with that.
>>
>> Nope, just applying the patch and booting the with the new dtb should
>> result in the random mac address going away.
>
> Unfortunately, I am not seeing any change with the patch (at least
> with Kernel 4.12.9 from stable).
>
> netconsole: network logging started
> davinci_emac davinci_emac.1: incompatible machine/device type for
> reading mac address
> davinci_emac davinci_emac.1: using random MAC addr: ee:74:c3:3a:15:be
>
> Looking at the source for cpsw-common.c function ti_cm_get_macid()
> doesn't have a case for the ti,davinci-dm6467-emac so I wonder if
> there might be more to it.
Hmm, it did solve the issue for me when I tried latest -next. And
reverting the patch brought back the random mac address usage. Could you
try latest mainline or -next?
Meanwhile let me see whats going on with the observations you have.
Thanks,
Sekhar
^ permalink raw reply
* Re: Fwd: DA850-evm MAC Address is random
From: Adam Ford @ 2017-08-29 15:20 UTC (permalink / raw)
To: Sekhar Nori; +Cc: Tony Lindgren, Grygorii Strashko, linux-omap, netdev
In-Reply-To: <955b0b1b-9bb7-ad25-4d6c-676be1efb943@ti.com>
On Tue, Aug 29, 2017 at 10:16 AM, Sekhar Nori <nsekhar@ti.com> wrote:
> On Tuesday 29 August 2017 05:32 PM, Adam Ford wrote:
>> On Tue, Aug 29, 2017 at 6:42 AM, Sekhar Nori <nsekhar@ti.com> wrote:
>>> On Tuesday 29 August 2017 03:53 PM, Adam Ford wrote:
>>>> On Tue, Aug 29, 2017 at 3:23 AM, Sekhar Nori <nsekhar@ti.com> wrote:
>>>>> On Tuesday 29 August 2017 02:42 AM, Tony Lindgren wrote:
>>>>>> * Adam Ford <aford173@gmail.com> [170828 13:33]:
>>>>>>> On Mon, Aug 28, 2017 at 1:54 PM, Grygorii Strashko
>>>>>>> <grygorii.strashko@ti.com> wrote:
>>>>>>>> Cc: Sekhar
>>>>>>>>
>>>>>>>> On 08/28/2017 10:32 AM, Adam Ford wrote:
>>>>>>>>>
>>>>>>>>> The davinvi_emac MAC address seems to attempt a call to
>>>>>>>>> ti_cm_get_macid in cpsw-common.c but it returns the message
>>>>>>>>> 'davinci_emac davinci_emac.1: incompatible machine/device type for
>>>>>>>>> reading mac address ' and then generates a random MAC address.
>>>>>>>>>
>>>>>>>>> The function appears to lookup varions boards using
>>>>>>>>> 'of_machine_is_compaible' and supports dm8148, am33xx, am3517, dm816,
>>>>>>>>> am4372 and dra7. I don't see the ti,davinci-dm6467-emac which is
>>>>>>>>> what's shown in the da850 device tree.
>>>>>>>>>
>>>>>>>>> Is there a patch somewhere for supporting the da850-evm?
>>>>>>>>
>>>>>>>>
>>>>>>>> Not sure if MAC address can be read from Control module.
>>>>>>>> May be Sekhar can say more?
>>>>>>>
>>>>>>> My understanding is that the MAC address is programmed by Logic PD
>>>>>>> into the SPI flash. The Bootloader reads this from either SPI or its
>>>>>>> env variables. Looking at the partition info listed in the
>>>>>>> da850-evm.dts file, it appears as if they've reserved space for it.
>>>>>>> Unfortunately, I don't see any code that reads it out. I was hoping
>>>>>
>>>>> This code is present in U-Boot sources at
>>>>> board/davinci/da8xxevm/da850evm.c. See the function get_mac_addr() and
>>>>> its usage in misc_init_r().
>>>>>
>>>>>>> there might be a way to just pass cmdline parameter from the
>>>>>>> bootloader to the kernel to accept the MAC address.
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> If not, is there a way to pass the MAC address from U-Boot to the
>>>>>>>>> driver so it doesn't generate a random MAC?
>>>>>>>>
>>>>>>>>
>>>>>>>> "local-mac-address" dt porp
>>>>>>>
>>>>>>> The downside here, is that we'd have to have the Bootloader modify the
>>>>>>> device tree.
>>>>>>
>>>>>> That piece of code exists somewhere in u-boot already. Note how
>>>>>
>>>>> Yes, it is fdt_fixup_ethernet() and its usage is in common/image-fdt.c.
>>>>>
>>>>>> we are populating the mac address for USB Ethernet drivers in
>>>>>> u-boot and then the Ethernet driver code parses it. See commit
>>>>>> 055d31de7158 ("ARM: omap3: beagleboard-xm: dt: Add ethernet to
>>>>>> the device tree") for some more information.
>>>>>>
>>>>>> I think u-boot needs the ethernet alias for finding the interface.
>>>>>
>>>>> That's exactly what was missing. I have sent a patch for fixing that and
>>>>> copied you there.
>>>>
>>>> Thanks for doing that.
>>>>
>>>>>
>>>>> Adam, if I can get your Tested-by, I will make an attempt to send it for
>>>>> v4.13 itself.
>>>>
>>>> I will test it. Do need to run some instruction or do something
>>>> special in U-Boot to pass this in the proper place for the kernel to
>>>> pull it? Tony's patch reference showed
>>>> command for fdt set, but I am not sure I fully understand the
>>>> parameters that went along with that.
>>>
>>> Nope, just applying the patch and booting the with the new dtb should
>>> result in the random mac address going away.
>>
>> Unfortunately, I am not seeing any change with the patch (at least
>> with Kernel 4.12.9 from stable).
>>
>> netconsole: network logging started
>> davinci_emac davinci_emac.1: incompatible machine/device type for
>> reading mac address
>> davinci_emac davinci_emac.1: using random MAC addr: ee:74:c3:3a:15:be
>>
>> Looking at the source for cpsw-common.c function ti_cm_get_macid()
>> doesn't have a case for the ti,davinci-dm6467-emac so I wonder if
>> there might be more to it.
>
> Hmm, it did solve the issue for me when I tried latest -next. And
> reverting the patch brought back the random mac address usage. Could you
> try latest mainline or -next?
>
> Meanwhile let me see whats going on with the observations you have.
I will try again with -next this afternoon and see what I can find.
Can you tell me which U-Boot version you're using? I want to match
your setup. I want to see if something is missing during the hand-off
between the Bootloader and Linux.
>
> Thanks,
> Sekhar
^ permalink raw reply
* Re: [PATCH] DSA support for Micrel KSZ8895
From: kbuild test robot @ 2017-08-29 15:33 UTC (permalink / raw)
To: Pavel Machek
Cc: kbuild-all, Woojung.Huh, nathan.leigh.conrad, vivien.didelot,
f.fainelli, netdev, linux-kernel, Tristram.Ha, andrew, pavel
In-Reply-To: <20170827123658.GA727@amd>
[-- Attachment #1: Type: text/plain, Size: 4778 bytes --]
Hi Pavel,
[auto build test ERROR on net-next/master]
[also build test ERROR on v4.13-rc7 next-20170829]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Pavel-Machek/DSA-support-for-Micrel-KSZ8895/20170829-220156
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 4.9.0
reproduce:
wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=xtensa
All error/warnings (new ones prefixed by >>):
In file included from drivers/net/dsa/microchip/ksz_common.c:31:0:
>> drivers/net/dsa/microchip/ksz_9477_reg.h:19:2: error: #error This is not switch we have
#error This is not switch we have
^
--
drivers/net/dsa/microchip/ksz_8895.c: In function 'ksz_reset_switch':
drivers/net/dsa/microchip/ksz_8895.c:109:21: warning: unused variable 'dev' [-Wunused-variable]
struct ksz_device *dev = ds->priv;
^
drivers/net/dsa/microchip/ksz_8895.c: In function 'ksz_br_join':
drivers/net/dsa/microchip/ksz_8895.c:262:21: warning: unused variable 'dev' [-Wunused-variable]
struct ksz_device *dev = ds->priv;
^
drivers/net/dsa/microchip/ksz_8895.c: In function 'ksz_br_leave':
drivers/net/dsa/microchip/ksz_8895.c:270:21: warning: unused variable 'dev' [-Wunused-variable]
struct ksz_device *dev = ds->priv;
^
drivers/net/dsa/microchip/ksz_8895.c: At top level:
>> drivers/net/dsa/microchip/ksz_8895.c:469:12: warning: 'struct switchdev_obj_port_fdb' declared inside parameter list
struct switchdev_trans *trans)
^
>> drivers/net/dsa/microchip/ksz_8895.c:469:12: warning: its scope is only this definition or declaration, which is probably not what you want
drivers/net/dsa/microchip/ksz_8895.c:497:16: warning: 'struct switchdev_obj_port_fdb' declared inside parameter list
struct switchdev_trans *trans)
^
drivers/net/dsa/microchip/ksz_8895.c:503:21: warning: 'struct switchdev_obj_port_fdb' declared inside parameter list
const struct switchdev_obj_port_fdb *fdb)
^
drivers/net/dsa/microchip/ksz_8895.c:510:9: warning: 'struct switchdev_obj_port_fdb' declared inside parameter list
switchdev_obj_dump_cb_t *cb)
^
>> drivers/net/dsa/microchip/ksz_8895.c:576:2: error: unknown field 'port_vlan_dump' specified in initializer
.port_vlan_dump = ksz_port_vlan_dump,
^
>> drivers/net/dsa/microchip/ksz_8895.c:576:2: warning: initialization from incompatible pointer type
drivers/net/dsa/microchip/ksz_8895.c:576:2: warning: (near initialization for 'ksz_switch_ops.port_fdb_add')
>> drivers/net/dsa/microchip/ksz_8895.c:577:2: error: unknown field 'port_fdb_prepare' specified in initializer
.port_fdb_prepare = ksz_port_fdb_prepare,
^
drivers/net/dsa/microchip/ksz_8895.c:577:2: warning: initialization from incompatible pointer type
drivers/net/dsa/microchip/ksz_8895.c:577:2: warning: (near initialization for 'ksz_switch_ops.port_fdb_del')
drivers/net/dsa/microchip/ksz_8895.c:578:2: warning: initialization from incompatible pointer type
.port_fdb_dump = ksz_port_fdb_dump,
^
drivers/net/dsa/microchip/ksz_8895.c:578:2: warning: (near initialization for 'ksz_switch_ops.port_fdb_dump')
drivers/net/dsa/microchip/ksz_8895.c:579:2: warning: initialization from incompatible pointer type
.port_fdb_add = ksz_port_fdb_add,
^
drivers/net/dsa/microchip/ksz_8895.c:579:2: warning: (near initialization for 'ksz_switch_ops.port_fdb_add')
drivers/net/dsa/microchip/ksz_8895.c:580:2: warning: initialization from incompatible pointer type
.port_fdb_del = ksz_port_fdb_del,
^
drivers/net/dsa/microchip/ksz_8895.c:580:2: warning: (near initialization for 'ksz_switch_ops.port_fdb_del')
>> drivers/net/dsa/microchip/ksz_8895.c:584:2: error: unknown field 'port_mdb_dump' specified in initializer
.port_mdb_dump = ksz_port_mdb_dump,
^
drivers/net/dsa/microchip/ksz_8895.c:584:2: warning: initialization from incompatible pointer type
drivers/net/dsa/microchip/ksz_8895.c:584:2: warning: (near initialization for 'ksz_switch_ops.get_rxnfc')
vim +19 drivers/net/dsa/microchip/ksz_9477_reg.h
> 19 #error This is not switch we have
20 #ifndef __KSZ9477_REGS_H
21 #define __KSZ9477_REGS_H
22
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 50969 bytes --]
^ permalink raw reply
* Re: [PATCH] vsock: only load vmci transport on VMware hypervisor by default
From: Jorgen S. Hansen @ 2017-08-29 15:37 UTC (permalink / raw)
To: Dexuan Cui
Cc: Stefan Hajnoczi, davem@davemloft.net, netdev@vger.kernel.org,
gregkh@linuxfoundation.org, devel@linuxdriverproject.org,
KY Srinivasan, Haiyang Zhang, Stephen Hemminger, George Zhang,
Michal Kubecek, Asias He, Vitaly Kuznetsov, Cathy Avery,
jasowang@redhat.com, Rolf Neugebauer, Dave Scott, Marcelo Cerri,
apw@canonical.com
In-Reply-To: <KL1P15301MB0008087A3EF0A8D037CC4D52BF9F0@KL1P15301MB0008.APCP153.PROD.OUTLOOK.COM>
> On Aug 29, 2017, at 4:36 AM, Dexuan Cui <decui@microsoft.com> wrote:
>
>> From: Dexuan Cui
>> Sent: Tuesday, August 22, 2017 21:21
>>> ...
>>> ...
>>> The only problem here would be the potential for a guest and a host app
>> to
>>> have a conflict wrt port numbers, even though they would be able to
>>> operate fine, if restricted to their appropriate transport.
>>>
>>> Thanks,
>>> Jorgen
>>
>> Hi Jorgen, Stefan,
>> Thank you for the detailed analysis!
>> You have a much better understanding than me about the complex
>> scenarios. Can you please work out a patch? :-)
>
> Hi Jorgen, Stefan,
> May I know your plan for this?
I’d be happy to discuss this now, but I don’t have time to work on the
actual implementation in the next couple of weeks.
For the guest, we agree that registering a guest transport should be
tied to either the hypervisor running the guest, or the existence of
the appropriate virtual hardware.
My main concern is that our existing software relies on the current
behavior of auto-loading the VMCI transport on the host side. So
changing that behavior could cause trouble for our existing Linux
users.
I’m wondering whether it would be possible to support multiple host
side transports. Since it is theoretically possible to run multiple
hypervisors at the same time, there would even be a use case for this.
If the assignment of CIDs is made unique across all transports, a
connection initiated by the host side will get directed to the
appropriate transport based on the CID. Any traffic coming from a guest
will naturally be using the appropriate transport. Host side applications
will have to share the port space as well. This would require tracking
CIDs as a common resource across all transports, but make CIDs
unique VM addresses on a given host.
If we allow multiple host side transports, virtio host side support and
vmci should be able to coexist regardless of the order of initialization.
Thanks,
Jorgen
^ permalink raw reply
* Re: [PATCH net-next v2 00/10] net: dsa: add generic debugfs interface
From: Vivien Didelot @ 2017-08-29 15:57 UTC (permalink / raw)
To: Jiri Pirko, David Miller
Cc: netdev, linux-kernel, kernel, f.fainelli, andrew, privat, john,
Woojung.Huh, sean.wang, nikita.yoush, cphealy
In-Reply-To: <20170829062931.GB1977@nanopsycho.orion>
Hi David, Jiri,
Jiri Pirko <jiri@resnulli.us> writes:
> Tue, Aug 29, 2017 at 06:38:37AM CEST, davem@davemloft.net wrote:
>>From: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
>>Date: Mon, 28 Aug 2017 15:17:38 -0400
>>
>>> This patch series adds a generic debugfs interface for the DSA
>>> framework, so that all switch devices benefit from it, e.g. Marvell,
>>> Broadcom, Microchip or any other DSA driver.
>>
>>I've been thinking this over and I agree with the feedback given that
>>debugfs really isn't appropriate for this.
>>
>>Please create a DSA device class, and hang these values under
>>appropriate sysfs device nodes that can be easily found via
>>/sys/class/dsa/ just as easily as they would be /sys/kernel/debug/dsa/
>>
>>You really intend these values to be consistent across DSA devices,
>>and you don't intend to go willy-nilly changig these exported values
>>arbitrarily over time. That's what debugfs is for, throw-away
>>stuff.
>>
>>So please make these proper device sysfs attributes rather than
>>debugfs.
>
> As I wrote, I believe that there is a big overlap with devlink and its
> dpipe subset. I think that primary we should focus on extending whatever
> is needed for dsa there. The iface should be generic for all drivers,
> not only dsa. dsa-specific sysfs attributes should be last-resort solution,
> I believe we can avoid them.
Please note that this interface is only meant to provide a _debug_ and
_development_ interface to DSA users. It is enableable at compile time
and can be ditched anytime we want, in contrary to other interfaces
which cannot be broken or changed because they are part of the ABI.
I see sysfs as a script-friendly way to access and configure kernel
structures, so I agree with Jiri that it doesn't seem appropriate.
Extending devlink is a good option for long term, but it'll take a bit
of time to extend data structures and not duplicate stats and regs
accesses for ports which have a net device attached to it or not.
In the meantime, I didn't find anything more useful and easier to debug
a switch fabric than dumping side-by-side stats of all ports part of the
data plane, for example like this:
# watch -n1 pr -mt {switch0/port5,switch0/port6,switch1/port5,switch1/port3}/stats
where ports 5 and 6 of both switches are DSA/CPU ports (without net
devices attached to them) and port3 is a user port. This way one can
easily see where and why packets get dropped.
We could keep this interface and simply ditch net/dsa/debugfs.c when a
convenient devlink alternative is in place.
Thanks,
Vivien
^ permalink raw reply
* Re: net.ipv4.tcp_max_syn_backlog implementation
From: Eric Dumazet @ 2017-08-29 16:17 UTC (permalink / raw)
To: Harsha Chenji; +Cc: netdev
In-Reply-To: <CAMB9WxJ_QHJr1pHKFO0YcYdQhHBL2Ch7ugccmf9gztALiY5f-w@mail.gmail.com>
On Tue, 2017-08-29 at 11:05 -0400, Harsha Chenji wrote:
> According to the man:
>
> The behavior of the backlog argument on TCP sockets changed with Linux
> 2.2. Now it specifies the queue length for *completely established
> sockets waiting to be accepted*, instead of the number of incomplete
> connection requests. The maximum length of the queue for incomplete
> sockets can be set using /proc/sys/net/ipv4/tcp_max_syn_backlog. When
> syncookies are enabled there is no logical maximum length and this
> setting is ignored. See tcp(7) for more information.
>
>
The sysctl was simply there to make sure that someone would not :
listen(fd, 0x40000000);
It served to cap the 2nd argument of listen() to something that the
admin considered as acceptable.
This was particularly important few years back when handling of SYN_RECV
sockets involved O(N) behavior for SYNACK retransmits.
Nowadays, a backlog of 10,000,000 is okay, if you have ram to spend on
it.
> On Tue, Aug 29, 2017 at 12:17 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > On Mon, 2017-08-28 at 23:47 -0400, Harsha Chenji wrote:
> >> So I have ubuntu 12.04 x32 in a VM with syncookies turned off. I tried
> >> to do a syn flood (with netwox) on 3 different processes. Each of them
> >> returns a different value with netstat -na | grep -c RECV :
> >>
> >> nc -l 5555 returns 16 (netcat-traditional)
> >> apache2 port 80 returns 256
> >> vsftpd on 21 returns 64.
> >> net.ipv4.tcp_max_syn_backlog is 512.
> >>
> >> Why do these different processes on different ports have different
> >> queue lengths for incomplete connections? Where exactly in the kernel
> >> is this decided?
> >
> > See 2nd argument in listen() system call, ie backlog
> >
> > man listen
> >
> > Without a synflood, just look at "ss -t state listening"
> >
> > The backlog is the 2nd column (Send)
> >
> >
> >
^ permalink raw reply
* Re: XDP redirect measurements, gotchas and tracepoints
From: Alexander Duyck @ 2017-08-29 16:23 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Andy Gospodarek, Michael Chan, John Fastabend, Duyck, Alexander H,
pstaszewski@itcare.pl, netdev@vger.kernel.org,
xdp-newbies@vger.kernel.org, borkmann@iogearbox.net
In-Reply-To: <20170829152601.02fdb8a3@redhat.com>
On Tue, Aug 29, 2017 at 6:26 AM, Jesper Dangaard Brouer
<brouer@redhat.com> wrote:
>
> On Mon, 28 Aug 2017 09:11:25 -0700 Alexander Duyck <alexander.duyck@gmail.com> wrote:
>
>> My advice would be to not over complicate this. My big concern with
>> all this buffer recycling is what happens the first time somebody
>> introduces something like mirroring? Are you going to copy the data to
>> a new page which would be quite expensive or just have to introduce
>> reference counts? You are going to have to deal with stuff like
>> reference counts eventually so you might as well bite that bullet now.
>> My advice would be to not bother with optimizing for performance right
>> now and instead focus on just getting functionality. The approach we
>> took in ixgbe for the transmit path should work for almost any other
>> driver since all you are looking at is having to free the page
>> reference which takes care of reference counting already.
>
> This return API is not about optimizing performance right now. It is
> actually about allowing us to change the underlying memory model per RX
> queue for XDP.
I would disagree. To me this is a obvious case of premature optimization.
> If a RX-ring is use for both SKBs and XDP, then the refcnt model is
> still enforced. Although a driver using the 1-packet-per-page model,
> should be able to reuse refcnt==1 pages when returned from XDP.
Isn't this the case for all Rx on XDP enabled rings. Last I knew there
was an option to pass packets up via an SKB if XDP_PASS is returned.
Are you saying we need to do a special allocation path if an XDP
program doesn't make use of XDP_PASS?
> If a RX-ring is _ONLY_ used for XDP, then the driver have freedom to
> implement another memory model, with the return-API. We need to
> experiment with the most optimal memory model. The 1-packet-per-page
> model is actually not the fastest, because of PCI-e bottlenecks. With
> HW support for packing descriptors and packets over the PCI-e bus, much
> higher rates can be achieved. Mellanox mlx5-Lx already have the needed HW
> support. And companies like NetCope also have 100G HW that does
> similar tricks, and they even have a whitepaper[1][2] how they are
> faster than DPDK with their NDP (Netcope Data Plane) API.
>
> We do need the ability/flexibility to change the RX memory model, to
> take advantage of this new NIC hardware.
Looking over the white paper I see nothing that prevents us from using
the same memory model we do with the Intel NICs. If anything I think
the Intel drivers in "legacy-rx" mode could support something like
this now, even if the hardware doesn't simply because we can get away
with keeping the memory pseudo-pinned. My bigger concern is that we
keep coming back to this idea that we need to have the network stack
taking care of the 1 page per packet recycling when I really think it
has no business being there. We either need to look at implementing
this in the way we did in the Intel drivers where we use the reference
counts or implement our own memory handling API like SLUB or something
similar based on compound page destructors. I would much rather see us
focus on getting this going with an agnostic memory model where we
don't have to make the stack aware of where the memory came from or
where it has to be returned to.
> [1] https://www.netcope.com/en/resources/improving-dpdk-performance
> [2] https://www.netcope.com/en/company/press-center/press-releases/read-new-netcope-whitepaper-on-dpdk-acceleration
My only concern with something like this is the fact that it is
optimized for a setup where the data is left in place and nothing
extra is added. Trying to work with something like this gets more
expensive when you have to deal with the full stack as you have to
copy out the headers and still deal with all the skb metadata. I fully
agree with the basic premise that writing in large blocks provides
significant gains in throughput, specifically with small packets. The
only gotcha you would have to deal with is SKB allocation and data
copying overhead to make room and fill in metadata for the frame and
any extra headers needed.
- Alex
^ permalink raw reply
* Re: [PATCH net-next] bnxt_en: add a dummy definition for bnxt_vf_rep_get_fid()
From: David Miller @ 2017-08-29 16:28 UTC (permalink / raw)
To: sathya.perla; +Cc: netdev
In-Reply-To: <1503987303-12392-1-git-send-email-sathya.perla@broadcom.com>
From: Sathya Perla <sathya.perla@broadcom.com>
Date: Tue, 29 Aug 2017 11:45:03 +0530
> When bnxt VF-reps are not compiled in (CONFIG_BNXT_SRIOV is off)
> bnxt_tc.c needs a dummy definition of the routine bnxt_vf_rep_get_fid().
>
> Reported-by: kbuild test robot <fengguang.wu@intel.com>
> Fixes: 2ae7408fedfe ("bnxt_en: bnxt: add TC flower filter offload support")
> Signed-off-by: Sathya Perla <sathya.perla@broadcom.com>
Applied.
^ 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