On 3/25/23 1:27 PM, Cong Wang wrote:
On Mon, Mar 20, 2023 at 01:29:39PM -0700, Martin KaFai Lau wrote:
On 3/20/23 11:13 AM, Stanislav Fomichev wrote:
One thing I still don't understand here: what is missing from the
socket iterators to implement this? Is it all the sk_psock_get magic?
I remember you dismissed Yonghong's suggestion on v1, but have you
actually tried it?
would be useful to know what is missing to print the bpf map id without
adding kernel code. There is new bpf_rdonly_cast() which will be useful here
also.
So you don't consider eBPF code as kernel code, right? Interestingly
enough, eBPF code runs in kernel... and you still need to write eBPF
code. So what is the point of "without adding kernel code" here?
Interesting, how is it the same? if it needs to print something other than the
map id in the future, even putting aside further kernel maintenance and
additional review, does a new bpf prog need to upgrade and reboot the kernel?
Based on your idea, all possible sk_filter automatically qualify to be added to
the kernel source tree now because they also run in the kernel?
What is even more interesting is that even your own code does not agree
with you here, for example, you introduced INET_DIAG_SK_BPF_STORAGES, so
what was missing to print sk bpf storage without adding kernel code?
Yep, you are absolutely correct. Only if bpf-iter was available earlier. If
bpf-iter was available before INET_DIAG_SK_BPF_STORAGES was added, there was no
need to add INET_DIAG_SK_BPF_STORAGES and it would be no brainer to explore the
bpf-iter approach first. Things have been improving.
The question (from a few people) was to figure out what was missing in the
bpf-iter approach to print this bpf bits and trying to help. It is the only
reason I replied. Apparently, you have not even tried and not interested.
