Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp1359754pxf; Fri, 9 Apr 2021 06:37:16 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxkT5Lvjt3q5ax8Y1XZa+K/zY8Ubjp3rpQyljfq+KwtClUhkPHVDN/4Ug+ccjE9EpsTn1hV X-Received: by 2002:a17:906:5203:: with SMTP id g3mr15821017ejm.95.1617975436264; Fri, 09 Apr 2021 06:37:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617975436; cv=none; d=google.com; s=arc-20160816; b=wgJLd9X0EpXD45E0Au7FjFhuKNNkQOlqkFR2MgUrGHmZGXgQ1TIBfWJLCVlHMYVpXY DVp96cMYWgjXDThT/gbZwcaL6ca76IJPwCVjyltG4FDbjSpbV1eSOKAPMeTNsEvDhjiW ZablYqoL2spRFOJOej9V90Ob/+OLn84KhNA1hcJzDR8F0mdp0iM1fEPIC3iIxu6A35V5 ulaXnchESekJFMFC1plAACq388NjwCErtg/0swMOUcrQKyzbYCzXtWNHuIWWqU4uqplo kyfBrtAjoXU+/MLZUNMrxr46UOmk0lyyh3cYxcGc0KJfNDBreslAhoPBEKh8KRbqflr1 SZvw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=zfd6WwcTcg+1Dt25aPD8eozmuw8Hhoe8fhqddcpjk0o=; b=LQ7BDGQrDajiyNNvQ0Q1s5Y+/Kk1F/jD8bja0NDtvZ2MsRAdayXM0E6SBO2TnuCzv3 xBzRPWYlJbsHlmEeaOWrcphstkBaqpGbrx1dhERahQnOT55HUNBCL416T9GX3IiJ8nW3 56btO1fsxgTo+mVUsX/AdDTpXgPwJau7dnHUOCrmRe/wx5D3bImrUK0aGBeUxJLEMiEv qZeuTDKJBv548+kB74WkYOnLE7Bj0St/nxr6dtnQUTjCh6FW0TiMF/DbIx+2ZfiN9Q7P v1mcd5IZ6EBw8M5BLBCZSkqE+HROW+NpOUHYq7cosMiYqbu7HqLhZTb781pwkr+qKxaz /iow== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id yk12si2020697ejb.435.2021.04.09.06.36.53; Fri, 09 Apr 2021 06:37:16 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233654AbhDINgC (ORCPT + 99 others); Fri, 9 Apr 2021 09:36:02 -0400 Received: from vps0.lunn.ch ([185.16.172.187]:42640 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231127AbhDINgB (ORCPT ); Fri, 9 Apr 2021 09:36:01 -0400 Received: from andrew by vps0.lunn.ch with local (Exim 4.94) (envelope-from ) id 1lUrIO-00FmRk-5c; Fri, 09 Apr 2021 15:35:36 +0200 Date: Fri, 9 Apr 2021 15:35:36 +0200 From: Andrew Lunn To: Haiyang Zhang Cc: David Miller , Dexuan Cui , "kuba@kernel.org" , KY Srinivasan , Stephen Hemminger , "wei.liu@kernel.org" , Wei Liu , "netdev@vger.kernel.org" , "leon@kernel.org" , "bernd@petrovitsch.priv.at" , "rdunlap@infradead.org" , "linux-kernel@vger.kernel.org" , "linux-hyperv@vger.kernel.org" Subject: Re: [PATCH v3 net-next] net: mana: Add a driver for Microsoft Azure Network Adapter (MANA) Message-ID: References: <20210408225840.26304-1-decui@microsoft.com> <20210408.164618.597563844564989065.davem@davemloft.net> <20210408.174122.1793350393067698495.davem@davemloft.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org For the structs containing variables with the same sizes, or already size aligned > variables, we knew the __packed has no effect. And for these structs, it doesn't > cause performance impact either, correct? > > But in the future, if different sized variables are added, the __packed may > become necessary again. To prevent anyone accidently forget to add __packed > when adding new variables to these structs, can we keep the __packed for all > messages going through the "wire"? It should not be a problem because anybody adding new variables should know packed is not liked in the kernel and will take care. If you want to be paranoid add a BUILD_BUG_ON(size(struct foo) != 42); Andrew