On 11/13/16 7:51 PM, David Ahern wrote:
On 10/31/16 11:49 AM, Thomas Graf wrote:
On 10/31/16 at 06:16pm, Daniel Mack wrote:
On 10/31/2016 06:05 PM, David Ahern wrote:
On 10/31/16 11:00 AM, Daniel Mack wrote:
Yeah, I'm confused too. I changed that name in my v7 from
BPF_PROG_TYPE_CGROUP_SOCK to BPF_PROG_TYPE_CGROUP_SKB on David's
(Ahern) request. Why is it now renamed again?

Thomas pushed back on adding another program type in favor of using
subtypes. So this makes the program type generic to CGROUP and patch
2 in this v2 set added Mickaƫl's subtype patch with the socket
mangling done that way in patch 3.


Fine for me. I can change it around again.

I would like to hear from Daniel B and Alexei as well. We need to
decide whether to use subtypes consistently and treat prog types as
something more high level or whether to bluntly introduce a new prog
type for every distinct set of verifier limits. I will change lwt_bpf
as well accordingly.


Alexei / Daniel - any comments/preferences on subtypes vs program types?

looks like in this particular case it's better to use different program
types, since they all serve different purpose and context is different.
Daniel Mack's programs can stay BPF_PROG_TYPE_CGROUP_SKB and operate on skb, whereas your ifindex changing programs can be BPF_PROG_TYPE_CGROUP_SOCK.

regarding DanielM's patches.. Dave's comment regarding skb->sk vs sk
made us think hard about it. We looked into tunnels and at the end
realized that skb->sk won't fly, since the program will be called
multiple times on tx for every ip_output. And since we were not sure
that using 'sk' will fix it, we had to do a bunch of tests with
different tunnels and analyze the code to make sure it's all good.
We'll repost soon.

Reply via email to