From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id E11BBA09E4; Thu, 21 Jan 2021 16:16:03 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 67037140D02; Thu, 21 Jan 2021 16:16:03 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mails.dpdk.org (Postfix) with ESMTP id 6D596140D02 for ; Thu, 21 Jan 2021 16:16:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1611242161; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=7nKB50Jv7TxPY4P2kWErnp97BImlnfIlr6E8Z+gX68k=; b=HU6ALExVSAa9LtjHCFSnSH0U8fe4ec1LQmSBZ3raV59DdabZFcmXISBRrxAu4Cd7gnd0vx mxklgnrnz9aKYCWVP2fqIAIM/8skThfK/ZIgms2syuAFZIZbLVvTGCNpLcz4AYohBSG0kp oAAb2snmnslSpb47lyAZoTow9620x5Q= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-441-lMsZmCfgP4u1pVxBLH9wcQ-1; Thu, 21 Jan 2021 10:15:57 -0500 X-MC-Unique: lMsZmCfgP4u1pVxBLH9wcQ-1 Received: by mail-wr1-f69.google.com with SMTP id l13so1264093wrq.7 for ; Thu, 21 Jan 2021 07:15:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:organization:references:date :in-reply-to:message-id:user-agent:mime-version; bh=7nKB50Jv7TxPY4P2kWErnp97BImlnfIlr6E8Z+gX68k=; b=BsxHEQ20JFIKTOb066pkxY691rF5G7jVyGT+E3nPSnfRjR2BlgHA83MUhBXSueipVG sOLkU33QEPZspYoo2EMUVItps6zAS7S/1yKjLLjHDiCz87njrhE128S4nNVOLRfl18WX TrchI7qPTbnSGnPMK6GzVMxQ7DHXHu5DpcbMgIW7QrdP1m5qbg8AZ9x26biGMOEJkQ3E 0XYYY1M+rcnnoZb5NA7L3m9z+RkVz2AdHZbAaJwNWvCK6e9PkJiHIZDaoagHbmFERFN3 KPtE+T+HZx0hW+D7f3hMloe48VybGmjN7efd4T18dxLXmevt7n+C3X3X/Y3skeFjMSkB 7NrA== X-Gm-Message-State: AOAM530GhWOfetzhPfXBgmpOwenZjPsM3nh0/TWe2xM0hBKg/3YTgEvH WZ5+4XA7JB2ISpEjHqcn8/gb5iFjXkT9aUnRQEStviVR2AeffHJwNbWYJQA1ZyltKydG1AoQVxw lkXg= X-Received: by 2002:a1c:770d:: with SMTP id t13mr9447652wmi.35.1611242156752; Thu, 21 Jan 2021 07:15:56 -0800 (PST) X-Google-Smtp-Source: ABdhPJxnQGuI1UqCsrwHyw1PTkg9x5MbCPzdDwzW+rp+kG8KHUcdT8ZDd8H+5n1eTksTS6fscPAi6g== X-Received: by 2002:a1c:770d:: with SMTP id t13mr9447634wmi.35.1611242156545; Thu, 21 Jan 2021 07:15:56 -0800 (PST) Received: from localhost (91-166-131-65.subs.proxad.net. [91.166.131.65]) by smtp.gmail.com with ESMTPSA id h16sm9038484wrq.29.2021.01.21.07.15.51 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Jan 2021 07:15:51 -0800 (PST) Received: by localhost (Postfix, from userid 1001) id 3D22F1A0FA5; Thu, 21 Jan 2021 16:15:50 +0100 (CET) From: Dodji Seketeli To: Thomas Monjalon Cc: Ray Kinsella , Neil Horman , Akhil Goyal , Konstantin Ananyev , Abhinandan Gujjar , dev@dpdk.org, david.marchand@redhat.com Organization: Red Hat / France References: <20210120142558.4120552-1-mdr@ashroe.eu> <15493004.lGub55pDpk@thomas> X-Operating-System: Red Hat Enterprise Linux Server 7.8 X-URL: http://www.redhat.com Date: Thu, 21 Jan 2021 16:15:50 +0100 In-Reply-To: <15493004.lGub55pDpk@thomas> (Thomas Monjalon's message of "Wed, 20 Jan 2021 16:41:18 +0100") Message-ID: <86sg6uiamx.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dodji@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Subject: Re: [dpdk-dev] [PATCH v1] devtools: update abi ignore for cryptodev X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hello Thomas and others, Thomas Monjalon writes: > Question to an expert, Dodji, Thanks for the kind words, but I am not an expert in anything, sadly. I am just trying to keep learning about these things ;-) > We have this structure: > > struct rte_cryptodev { > lot of fields... > uint8_t attached : 1; > } __rte_cache_aligned; > > Because of the cache alignment, there is enough padding in the struct > (no matter the size of the cache line) for adding two more pointers: > > struct rte_cryptodev { > lot of fields... > uint8_t attached : 1; > struct rte_cryptodev_cb_rcu *enq_cbs; > struct rte_cryptodev_cb_rcu *deq_cbs; > } __rte_cache_aligned; > > We checked manually that the ABI is still compatible. Right. I am curious, but normally, libabigail should raise the addition of structures, but then it'll tell you that there was no size or offset change between the two structures. If it doesn't, then that's a bug. I hope it does :-) > Then I've added (quickly) a libabigail exception rule: > > [suppress_type] > name = rte_cryptodev > has_data_member_inserted_between = {0, 1023} > > Now we want to improve this rule to restrict the offsets > to the padding at the end of the struct only, > so we keep forbidding changes in existing fields, > and forbidding additions further the current struct size. > Is this new rule good? > > has_data_member_inserted_between = {offset_after(attached), end} Yes, this rule should do what you think it says. > Do you confirm that the keyword "end" means the old reference size? Yes I do. > What else do we need to check for adding a new field in a padding? Actually, that rule will work independantly of it there is enough padding or not. It'll shut down the change report, even if the added data exceeds the padding. You just made me think of an idea of a new feature there. Maybe we'd need a new property for the [suppress_type] directive that would suppress changes only if said changes don't modify the size of the type or any offset of any member of the type? Maybe something like: [suppress_type] ; lots of properties can go here. ; ... ; If the type has any size or offset change ; then this suppression directive will fail ; and the change report will be emitted has_no_size_or_offset_change Would that be useful to you in this case, Cheers, -- Dodji