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 AB8D5A0C48; Wed, 7 Jul 2021 09:39:54 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2F16E4130B; Wed, 7 Jul 2021 09:39:54 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id F2495406FF for ; Wed, 7 Jul 2021 09:39:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1625643592; 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=3rs2N7kMxW7T7kceT9XuDABF01tKK9+n85w0l9XcnQE=; b=X4BiT+ZOkWFMeVuMe90h6lNQcp4AUJXGHMVEzW/9UOKXsE+QvAAEl9jU4SbN4DsCIAoVf9 XeVIBegOo2Kl7Srqs8FM5/dxuYq/lt/rcCWfRFcujAQ56fLXMbWMtBeV/qNu6zw+sjcvUL 0kogX+BDzeySqAltP21cw/z/cw4lSQk= Received: from mail-ua1-f69.google.com (mail-ua1-f69.google.com [209.85.222.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-266-qr7XIRBMPLeOXtqow3Oa_w-1; Wed, 07 Jul 2021 03:39:49 -0400 X-MC-Unique: qr7XIRBMPLeOXtqow3Oa_w-1 Received: by mail-ua1-f69.google.com with SMTP id d6-20020ab021060000b029029da61c35dbso494647ual.11 for ; Wed, 07 Jul 2021 00:39:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3rs2N7kMxW7T7kceT9XuDABF01tKK9+n85w0l9XcnQE=; b=TwwOkNCjwitegZyVCrI293e0ZJdsze8XvPBxQFj3bFSikEID71sCGU4bmjdkkwXjIj tCjWYnetlWBhVzozBbbdQHYhgT8a5d/KiA4zvzIZiA2OrCjohIv2u4m1IR7CvU7A311V 5mHNSpea1mu7r2Fd8vhXf3VBsXGyCDZeLjsy81dPaflMYfY0f8vocMVZA1c6qcYRoqls 0WGvWzSinMgycYYlInfYJRwwrc6HGYw6UaWfesJ4cZ6EY1tZPdwPbrBqijtbjD0Sp3rI /q0STrBiCoSTP3WRx5hGGLEOVURetfkmL29Sv4cTTtHfzurmUzEfRDkc8mPZ/sfxDSzJ +24w== X-Gm-Message-State: AOAM5338wiUakDPxnXJFiQDV0Q1stFtY5bxrag9JWe1f8OLpU0f3uRe9 ljZQliEEDBgewJNnoIf230NlnN35DqevG0GA0Jv6QNFMMzf1IFmGrc0zt9uDD+VTyP4zuh0sQZG nRz7elKQceRQESoTYBpU= X-Received: by 2002:a1f:a655:: with SMTP id p82mr9716098vke.20.1625643588657; Wed, 07 Jul 2021 00:39:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwtnUN/Zblp8SXy1ll6ZIzgRCiQjlZdnZdlYzNhnRkLST4TNiV4JjsKZ5duWd2pFURodCV+vNv1hkBLZYyfznw= X-Received: by 2002:a1f:a655:: with SMTP id p82mr9716074vke.20.1625643588335; Wed, 07 Jul 2021 00:39:48 -0700 (PDT) MIME-Version: 1.0 References: <1620460836-38506-1-git-send-email-lihuisong@huawei.com> <1625544608-30590-1-git-send-email-lihuisong@huawei.com> <966ec9cd-9142-b40d-b059-b63c8ece66bf@oktetlabs.ru> In-Reply-To: <966ec9cd-9142-b40d-b059-b63c8ece66bf@oktetlabs.ru> From: David Marchand Date: Wed, 7 Jul 2021 09:39:37 +0200 Message-ID: To: Andrew Rybchenko , Dodji Seketeli Cc: Huisong Li , dev , Thomas Monjalon , "Yigit, Ferruh" , "Ananyev, Konstantin" , Ray Kinsella Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH V2] ethdev: add dev configured flag 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" On Tue, Jul 6, 2021 at 10:36 AM Andrew Rybchenko wrote: > > @David, could you take a look at the ABI breakage warnings for > the patch. May we ignore it since ABI looks backward > compatible? Or should be marked as a minor change ABI > which is backward compatible with DPDK_21? The whole eth_dev_shared_data area has always been reset to 0 at the first port allocation in a dpdk application life. Subsequent calls to rte_eth_dev_release_port() reset every port eth_dev->data to 0. This bit flag is added in a hole of the structure, and it is set/manipulated internally of ethdev. So unless the application was doing something nasty like highjacking this empty hole in the structure, I see no problem with the change wrt ABI. I wonder if libabigail is too strict on this report. Or maybe there is some extreme consideration on what a compiler could do about this hole... Dodji? For now, we can waive the warning. I'll look into the exception rule to add. -- David Marchand