> Maybe you can swap map_fd and flags? > This way, you won't have hole right after map_fd?
Makes sense. > > + attr->flags = 0; > Why do you want attr->flags? This is to modify anonumous struct used by > BPF_MAP_*_ELEM commands. Nice catch! This was a mistake I forgot to delete that line. > In bcc, we have use cases like this. At a certain time interval (e.g., > every 2 seconds), > we get all key/value pairs for a map, we format and print out map > key/values on the screen, > and then delete all key/value pairs we retrieved earlier. > > Currently, bpf_get_next_key() is used to get all key/value pairs, and > deletion also happened > at each key level. > > Your batch dump command should help retrieving map key/value pairs. > What do you think deletions of those just retrieved map entries? > With an additional flag and fold into BPF_MAP_DUMP? > or implement a new BPF_MAP_DUMP_AND_DELETE? > > I mentioned this so that we can start discussion now. > You do not need to implement batch deletion part, but let us > have a design extensible for that. > > Thanks. With a additional flag, code could be racy where you copy an old value and delete the newest one. So maybe we could implement BPF_MAP_DUMP_AND_DELETE as a wrapper of map_get_next_key + map_lookup_and_delete_elem. Last function already exists but it has not been implemented for maps other than stack and queue. Thanks for reviewing it!
