Difference between BPF_PROG_TYPE_SOCK_OPS and BPF_PROG_TYPE_CGROUP_SOCK

The BPF_PROG_TYPE_SOCK_OPS and BPF_PROG_TYPE_CGROUP_SOCK programs seen to be very similar. According to the kernel source, the following are the definitions of the two program types:

BPF_PROG_TYPE(BPF_PROG_TYPE_CGROUP_SOCK, cg_sock,
	      struct bpf_sock, struct sock)

BPF_PROG_TYPE(BPF_PROG_TYPE_SOCK_OPS, sock_ops,
	      struct bpf_sock_ops, struct bpf_sock_ops_kern)

Is the CGROUP_SOCK a subset of the SOCK_OPS program type? Because its associated bpf_sock seems to have common fields as bpf_sock_ops.

Edit: While testing, I also realized that the bpf_sock struct only allows restricted access to the source and destination IPs. Does this reinforce that CGROUP_SOCK is a subset of the SOCK_OPS program type?

This is the commit that introduced the BPF_PROG_TYPE_SOCK_OPS program type: https://github.com/torvalds/linux/commit/40304b2a1567fecc321f640ee4239556dd0f3ee0

The following is from the commit message which outlines the differences quite nicely:

> Created a new BPF program type, BPF_PROG_TYPE_SOCK_OPS, and a corresponding
struct that allows BPF programs of this type to access some of the
socket's fields (such as IP addresses, ports, etc.). It uses the
existing bpf cgroups infrastructure so the programs can be attached per
cgroup with full inheritance support. The program will be called at
appropriate times to set relevant connections parameters such as buffer
sizes, SYN and SYN-ACK RTOs, etc., based on connection information such
as IP addresses, port numbers, etc.
>
> Although there are already 3 mechanisms to set parameters (sysctls,
route metrics and setsockopts), this new mechanism provides some
distinct advantages. Unlike sysctls, it can set parameters per
connection. In contrast to route metrics, it can also use port numbers
and information provided by a user level program. In addition, it could
set parameters probabilistically for evaluation purposes (i.e. do
something different on 10% of the flows and compare results with the
other 90% of the flows). Also, in cases where IPv6 addresses contain
geographic information, the rules to make changes based on the distance
(or RTT) between the hosts are much easier than route metric rules and
can be global. Finally, unlike setsockopt, it oes not require
application changes and it can be updated easily at any time.
>
> Although the bpf cgroup framework already contains a sock related
program type (BPF_PROG_TYPE_CGROUP_SOCK), I created the new type
(BPF_PROG_TYPE_SOCK_OPS) because the existing type expects to be called
only once during the connections's lifetime. In contrast, the new
program type will be called multiple times from different places in the
network stack code. For example, before sending SYN and SYN-ACKs to set
an appropriate timeout, when the connection is established to set
congestion control, etc. As a result it has "op" field to specify the
type of operation requested.
>
> The purpose of this new program type is to simplify setting connection
parameters, such as buffer sizes, TCP's SYN RTO, etc. For example, it is
easy to use facebook's internal IPv6 addresses to determine if both hosts
of a connection are in the same datacenter. Therefore, it is easy to
write a BPF program to choose a small SYN RTO value when both hosts are
in the same datacenter.

> While testing, I also realized that the bpf_sock struct only allows restricted access to the source and destination IPs. Does this reinforce that CGROUP_SOCK is a subset of the SOCK_OPS program type?

No, one is not the subset of the other, they are simply different program types intended for different use-cases. They have different contexts and each program type can have very specific rules around which fields are read-only and write-only.