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 0FE15A0547; Fri, 12 Mar 2021 15:28:47 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B266416088A; Fri, 12 Mar 2021 15:28:46 +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 D0850406FF for ; Fri, 12 Mar 2021 15:28:45 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1615559325; 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=Y47g7uz5kTSsaJrqfPvl8E218eGgURI47BG/y2txKq8=; b=jWnN/V5Amcnnl3corupa2TbQYdejAh+1MhDDNeR96MwezWQJEehD3RpP/3OC8+9/wsonjh CiQVahxfpbLzmkojwYkC8oluqR0d2yD8LDaZuJjUIZ5J+a3DkeKifjDmFywBx3zt2dCGfb WebLtP3FNeRUiCiAyEMgQgVLYw6x5CM= Received: from mail-vs1-f69.google.com (mail-vs1-f69.google.com [209.85.217.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-23-zM3FTCYBMQKIGEGuQyDSIA-1; Fri, 12 Mar 2021 09:28:43 -0500 X-MC-Unique: zM3FTCYBMQKIGEGuQyDSIA-1 Received: by mail-vs1-f69.google.com with SMTP id s63so6799174vss.18 for ; Fri, 12 Mar 2021 06:28:43 -0800 (PST) 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=Y47g7uz5kTSsaJrqfPvl8E218eGgURI47BG/y2txKq8=; b=coa/S8rBR+rq9F0ofrMSplTrgL8DMbIgRIj42nUszRAwEN08i4Yz4IMuSvYGq6ruu5 4F1J70eKBg6/Y+TaAhgL+dKgbSBqNLZ7OB2ASOkpCjBT5b1S9ygBZVvXnP4n3Rap+hoE NsyzhA3a2bMBHxDOVeS99e8Sj6LXfbvt0EfwFPy5c/1cAmN1uhcPoH1RhACTJGj9dByw xyH6unatEQS8n7MPobMw4vuSPfXuH2N0eyajC/V/f2L7hVk8U8DYKtIgbwdQvcb+/H/5 bDL37nvtPUlBExMcACb0hVvloeaSrO+7ENkro502jHfwFj1ZFfgynyQIoIIUDtktaRYB Grdw== X-Gm-Message-State: AOAM5335H53Qprfhhj08GV0yAkufqDxEuoozMb9KaDw3JRWr6X2nTgf/ 4djJAGfNGMepk7Yc7iHLszeMdZutk+vyuRPvzHchgPhM3pvQlDYBeKezj2cXdlUMW+dFyboHNP+ mcB8nXb/YiNjhrPs0LU4= X-Received: by 2002:a9f:2722:: with SMTP id a31mr8443337uaa.86.1615559323029; Fri, 12 Mar 2021 06:28:43 -0800 (PST) X-Google-Smtp-Source: ABdhPJygajY/TDTARf8biDIcuYant7/xZbmVxxPxTf04vUk/yJEPPWtRz71qbeoWmsccSFy7AAwLhTBO6py9wOJYi+E= X-Received: by 2002:a9f:2722:: with SMTP id a31mr8443320uaa.86.1615559322707; Fri, 12 Mar 2021 06:28:42 -0800 (PST) MIME-Version: 1.0 References: <20210220220957.4583-1-pbhagavatula@marvell.com> <20210220220957.4583-8-pbhagavatula@marvell.com> In-Reply-To: From: David Marchand Date: Fri, 12 Mar 2021 15:28:31 +0100 Message-ID: To: Jerin Jacob Cc: Pavan Nikhilesh , Jerin Jacob , "Jayatheerthan, Jay" , Erik Gabriel Carrillo , "Gujjar, Abhinandan S" , "McDaniel, Timothy" , Hemant Agrawal , "Van Haaren, Harry" , =?UTF-8?Q?Mattias_R=C3=B6nnblom?= , Liang Ma , Ray Kinsella , Neil Horman , dpdk-dev , Thomas Monjalon 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 7/7] eventdev: fix ABI breakage due to event vector 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 Mon, Mar 8, 2021 at 7:44 PM Jerin Jacob wrote: > Summary: > 1) Ideal way of adding this feature is to add elements in the > existing structure as mentioned > in ("eventdev: introduce event vector Rx capability") in this series. > 2) Since this breaking ABI, Introducing a new structure to fix this. I > think, we can remove this > limitation in 21.11 as that time we can change ABI as required. > > So, Is this patch needs to be squashed to ("eventdev: introduce event > vector Rx capability") to avoid > ABI compatibility between patches? Or Is it OK to break the ABI > compatibility in a patch in the series > and later fix it in the same series?(This is for more readability as > we can revert this patch in 21.11). What matters is not to break compilation between patches, so that bisecting is always possible. For ABI checks... I don't see the need to enforce such a requirement. Yet, it is more straightforward to not break the 20.11 ABI at all. You can announce the intended ABI change in the release notes / deprecation notices, not sure I saw it in this series. If you still want to share the final state intended for v21.11, you can send the patch at the end of the series with something in the title like "for v21.11" and mark it deferred in patchwork. -- David Marchand