If there is multiple network config (one or more CNI is configured in container runtime or by multus), then one plugin may receives multiple GC calls for each network config. (e.g. pluginA GC for config1 and pluignA GC for config2). GC takes a bit huge computation cost, so we should optimize it as much as we can.
Hence we could improve GC calls by
Add new GC API (or we just change current GC API because currently none uses it yet)
GCNetworkLists(ctx context.Context, net []*NetworkConfigList, args *GCArgs) error
In new API, we optimize (sort and dedup) for each plugin, invoke GC with valid arguments.
maiqueb
commented
5 months ago
Currently GC calls with
cni.dev/valid-attachmentsarguments, to specify current valid attachments based on network config.https://github.com/containernetworking/cni/blob/c04330ee9e0bb932e1e3eda757813e2f212e746b/libcni/api.go#L113
If there is multiple network config (one or more CNI is configured in container runtime or by multus), then one plugin may receives multiple GC calls for each network config. (e.g. pluginA GC for config1 and pluignA GC for config2). GC takes a bit huge computation cost, so we should optimize it as much as we can.
Hence we could improve GC calls by