Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752838AbaKDJZr (ORCPT ); Tue, 4 Nov 2014 04:25:47 -0500 Received: from mx1.redhat.com ([209.132.183.28]:34627 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751160AbaKDJZn (ORCPT ); Tue, 4 Nov 2014 04:25:43 -0500 Message-ID: <54589B89.5000309@redhat.com> Date: Tue, 04 Nov 2014 10:25:29 +0100 From: Daniel Borkmann User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Alexei Starovoitov CC: "David S. Miller" , Ingo Molnar , Andy Lutomirski , Hannes Frederic Sowa , Eric Dumazet , linux-api@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net-next 1/7] bpf: add 'flags' attribute to BPF_MAP_UPDATE_ELEM command References: <1415069656-14138-1-git-send-email-ast@plumgrid.com> <1415069656-14138-2-git-send-email-ast@plumgrid.com> In-Reply-To: <1415069656-14138-2-git-send-email-ast@plumgrid.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/04/2014 03:54 AM, Alexei Starovoitov wrote: > the current meaning of BPF_MAP_UPDATE_ELEM syscall command is: > either update existing map element or create a new one. > Initially the plan was to add a new command to handle the case of > 'create new element if it didn't exist', but 'flags' style looks > cleaner and overall diff is much smaller (more code reused), so add 'flags' > attribute to BPF_MAP_UPDATE_ELEM command with the following meaning: > enum { > BPF_MAP_UPDATE_OR_CREATE = 0, /* add new element or update existing */ > BPF_MAP_CREATE_ONLY, /* add new element if it didn't exist */ > BPF_MAP_UPDATE_ONLY /* update existing element */ > }; From you commit message/code I currently don't see an explanation why it cannot be done in typical ``flags style'' as various syscalls do, i.e. BPF_MAP_UPDATE_OR_CREATE rather represented as ... BPF_MAP_CREATE | BPF_MAP_UPDATE Do you expect more than 64 different flags to be passed from user space for BPF_MAP? > BPF_MAP_CREATE_ONLY can fail with EEXIST if element already exists. > BPF_MAP_UPDATE_ONLY can fail with ENOENT if element doesn't exist. > > Userspace will call it as: > int bpf_update_elem(int fd, void *key, void *value, __u64 flags) > { > union bpf_attr attr = { > .map_fd = fd, > .key = ptr_to_u64(key), > .value = ptr_to_u64(value), > .flags = flags; > }; > > return bpf(BPF_MAP_UPDATE_ELEM, &attr, sizeof(attr)); > } > > Signed-off-by: Alexei Starovoitov -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/