On 12/19/2018 05:40 PM, Jesper Dangaard Brouer wrote:
> On Wed, 19 Dec 2018 16:46:05 +0100
> Daniel Borkmann wrote:
>
>> Hmm, why not just doing something as in your example below with napi_poll()
>> where you pass in the napi pointer, and then use bpf_probe_read_str() on
>> ctx->dev for fetching
On Wed, 19 Dec 2018 17:40:49 +0100
Jesper Dangaard Brouer wrote:
> My napi_monitor use-case is not a slow-path event, even-though in
> optimal cases we should handle 64 packets per tracepoint invocation,
> but I'm using this for 100G NICs with >20Mpps. And I mostly use the
> tool when something l
On 12/19/18 12:36 AM, Jesper Dangaard Brouer wrote:
> Today, the existing network tracepoints using dev->name is not that
> usable by BPF, as BPF cannot identify the interface. Thus IMHO it would
> make sense to convert the existing network tracepoints dev->name into
> dev->ifindex, and then let p
On Wed, 19 Dec 2018 16:46:05 +0100
Daniel Borkmann wrote:
> Hmm, why not just doing something as in your example below with napi_poll()
> where you pass in the napi pointer, and then use bpf_probe_read_str() on
> ctx->dev for fetching the name? At least there this should work and should
> be okay
On Wed, 19 Dec 2018 08:36:43 +0100
Jesper Dangaard Brouer wrote:
> > +TRACE_EVENT(net_dev_notifier_entry,
> > +
> > + TP_PROTO(const struct netdev_notifier_info *info, unsigned long val),
> > +
> > + TP_ARGS(info, val),
> > +
> > + TP_STRUCT__entry(
> > + __string( name,
On 12/19/2018 08:36 AM, Jesper Dangaard Brouer wrote:
> On Tue, 18 Dec 2018 18:27:06 -0800
> Stephen Hemminger wrote:
>
>> This is the result of a conversation about monitoring of link
>> state changes with BPF.
>
> If you want to use this from BPF then you are in for a surprise. As
> tracepoin
On Wed, 19 Dec 2018 08:36:43 +0100
Jesper Dangaard Brouer wrote:
> On Tue, 18 Dec 2018 18:27:06 -0800
> Stephen Hemminger wrote:
>
> > This is the result of a conversation about monitoring of link
> > state changes with BPF.
>
> If you want to use this from BPF then you are in for a surprise
On Tue, 18 Dec 2018 18:27:06 -0800
Stephen Hemminger wrote:
> This is the result of a conversation about monitoring of link
> state changes with BPF.
If you want to use this from BPF then you are in for a surprise. As
tracepoints BPF cannot read these "__string" constructs, here the netdev
name
On 12/18/18 7:27 PM, Stephen Hemminger wrote:
> There already are network trace points for transmit and receive but
> nothing for state changes. Add network tracepoints for before and
> after netlink callback is done. This is simple (without extack or
> other info) but that could be added if usefu
There already are network trace points for transmit and receive but
nothing for state changes. Add network tracepoints for before and
after netlink callback is done. This is simple (without extack or
other info) but that could be added if useful. Network namespace id
would also be helpful but hard
10 matches
Mail list logo
