From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Graf Subject: Re: [PATCH v8 04/11] net/mlx4_en: add support for fast rx drop bpf program Date: Mon, 18 Jul 2016 14:48:11 +0200 Message-ID: <20160718124811.GB2979@pox.localdomain> References: <1468309894-26258-1-git-send-email-bblanco@plumgrid.com> <1468309894-26258-5-git-send-email-bblanco@plumgrid.com> <20160714092543.776f8d8c@redhat.com> <20160715033057.GA98180@ast-mbp.thefacebook.com> <20160715164744.GA3693@ast-mbp.thefacebook.com> <20160718091023.GA29198@pox.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Alexei Starovoitov , Jesper Dangaard Brouer , Brenden Blanco , "David S. Miller" , Linux Kernel Network Developers , Jamal Hadi Salim , Saeed Mahameed , Martin KaFai Lau , Ari Saha , Or Gerlitz , john fastabend , Hannes Frederic Sowa , Daniel Borkmann To: Tom Herbert Return-path: Received: from mail-wm0-f52.google.com ([74.125.82.52]:37849 "EHLO mail-wm0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751530AbcGRMsO (ORCPT ); Mon, 18 Jul 2016 08:48:14 -0400 Received: by mail-wm0-f52.google.com with SMTP id i5so115128070wmg.0 for ; Mon, 18 Jul 2016 05:48:13 -0700 (PDT) Content-Disposition: inline In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: On 07/18/16 at 01:39pm, Tom Herbert wrote: > On Mon, Jul 18, 2016 at 11:10 AM, Thomas Graf wrote: > > I agree with that but I would like to keep the current per net_device > > atomic properties. > > I don't see that see that there is any synchronization guarantees > using xchg. For instance, if the pointer is set right after being read > by a thread for one queue and right before being read by a thread for > another queue, this could result in the old and new program running > concurrently or old one running after new. If we need to synchronize > the operation across all queues then sequence > ifdown,modify-config,ifup will work. Right, there are no synchronization guarantees between threads and I don't think that's needed. The guarantee that is provided is that if I replace a BPF program, the replace either succeeds in which case all packets have been either processed by the old or new program. Or the replace failed in which case the old program was left intact and all packets are still going through the old program. This is a nice atomic replacement principle which would be nice to preserve.