[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87zhdzbfa3.fsf@toke.dk>
Date: Mon, 03 Feb 2020 21:13:24 +0100
From: Toke Høiland-Jørgensen <toke@...hat.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: David Ahern <dsahern@...il.com>, David Ahern <dsahern@...nel.org>,
netdev@...r.kernel.org, prashantbhole.linux@...il.com,
jasowang@...hat.com, davem@...emloft.net, brouer@...hat.com,
mst@...hat.com, toshiaki.makita1@...il.com, daniel@...earbox.net,
john.fastabend@...il.com, ast@...nel.org, kafai@...com,
songliubraving@...com, yhs@...com, andriin@...com,
David Ahern <dahern@...italocean.com>
Subject: Re: [PATCH bpf-next 03/12] net: Add IFLA_XDP_EGRESS for XDP programs in the egress path
Oops, I see I forgot to reply to this bit:
>> Yeah, but having the low-level details available to the XDP program
>> (such as HW queue occupancy for the egress hook) is one of the benefits
>> of XDP, isn't it?
>
> I think I glossed over the hope for having access to HW queue occupancy
> - what exactly are you after?
>
> I don't think one can get anything beyond a BQL type granularity.
> Reading over PCIe is out of question, device write back on high
> granularity would burn through way too much bus throughput.
This was Jesper's idea originally, so maybe he can explain better; but
as I understood it, he basically wanted to expose the same information
that BQL has to eBPF. Making it possible for an eBPF program to either
(re-)implement BQL with its own custom policy, or react to HWQ pressure
in some other way, such as by load balancing to another interface.
-Toke
Powered by blists - more mailing lists