[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZB9ZIG9fgWKKHL17@pop-os.localdomain>
Date: Sat, 25 Mar 2023 13:27:12 -0700
From: Cong Wang <xiyou.wangcong@...il.com>
To: Martin KaFai Lau <martin.lau@...ux.dev>
Cc: Stanislav Fomichev <sdf@...gle.com>, netdev@...r.kernel.org,
bpf@...r.kernel.org, Cong Wang <cong.wang@...edance.com>,
John Fastabend <john.fastabend@...il.com>,
Jakub Sitnicki <jakub@...udflare.com>
Subject: Re: [Patch net-next v3] sock_map: dump socket map id via diag
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?
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?
Thanks.
Powered by blists - more mailing lists