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 8B0E3A0A02; Wed, 24 Mar 2021 16:26:07 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 59DCF140F07; Wed, 24 Mar 2021 16:26:07 +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 B4A24140F03 for ; Wed, 24 Mar 2021 16:26:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1616599564; 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=6YsiX6cty3aWnnNFFbZghJ9OcNuaigD5RZ6a5N8O5Lk=; b=a/27H0mWSXytMiHP4tN1YBgxXfEMX+ajCeFMQZSqlia5jVFqwhZHr/gX8h4kEvTU4OeNAY dDMAgvpmfRW5iS4kkRJScdltnVA3pBdxBG+7SqGbc83Xqlo6G+baDX6em6PoXlAWLlt4SI Uzu98AwVBVgXSjE/RIKEYKT1bi+CFbM= Received: from mail-ua1-f70.google.com (mail-ua1-f70.google.com [209.85.222.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-561-pvbDIy0BO96TjdWoc0rpLw-1; Wed, 24 Mar 2021 11:26:03 -0400 X-MC-Unique: pvbDIy0BO96TjdWoc0rpLw-1 Received: by mail-ua1-f70.google.com with SMTP id u20so627681uaw.13 for ; Wed, 24 Mar 2021 08:26:02 -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=6YsiX6cty3aWnnNFFbZghJ9OcNuaigD5RZ6a5N8O5Lk=; b=II2ADJY4lcK9E6Buj3frSj1ZTJrdiwv4ty9Z0T8F98x/9syzdV+nW5g35PMRjWYOMw 5f9IprxGUF3Ynio7EswdV/RNdfPungC4hwJR4l7XP+L9k2WazLed83f4HYnqbZDuO1Sq fdKuHjeravkXfOZfRPAxcOJ5Fd/6oPkP7ZtDMN0z2q/llc13nIZQhJOeng+OZxhpjSo5 sgFnlqLQeXAV7m2OjV7G4JfSIgJKpyohsg8Mok/HaUndv3+pKdUkxPxCSlkXigmp8NbI nTJU5fYMRKOJ/w6THjVlSPPmHISpVVRZPOmY3oJiqPsj6eYZAZizYHYB6k3o2igXLUwe /nMA== X-Gm-Message-State: AOAM533Kdvn6PWyFjNhxX/LxKl+1Z89vmRn7apvbglEjgWblBSf42VII FWnjL0SH4siCDTYzhd4PdL3fB9g/GzhWrtpFiCwYUJ2UF1aEcnywi4iOcr/4qCHDJnEKA+5NAil 40WBcV+hZgzed8IM8VSk= X-Received: by 2002:a05:6102:ed4:: with SMTP id m20mr2072536vst.27.1616599562544; Wed, 24 Mar 2021 08:26:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz9L4CE+Fjp4686pSSfTfFqlfBF1CpMtRCT+Ui8/Oi25noPgDW09YZ78CjPNGWkxBv6ZhyfMINqQDzHqaY/vZI= X-Received: by 2002:a05:6102:ed4:: with SMTP id m20mr2072525vst.27.1616599562296; Wed, 24 Mar 2021 08:26:02 -0700 (PDT) MIME-Version: 1.0 References: <20210225190112.2073-1-pbhagavatula@marvell.com> In-Reply-To: From: David Marchand Date: Wed, 24 Mar 2021 16:25:51 +0100 Message-ID: To: Jerin Jacob Cc: Ray Kinsella , Pavan Nikhilesh , Harman Kalra , Thomas Monjalon , Jerin Jacob , Bruce Richardson , dpdk-dev 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 1/2] eal: make max interrupt vector id configurable 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 Wed, Mar 24, 2021 at 1:55 PM Jerin Jacob wrote: > > > IMO, We dont need to make it configurable and each platform sets its > > > value. That scheme won't work as generic distribution build will fail > > > to run. > > > Since PCIe specification defines this value and there is no > > > performance impact on increasing this, > > > IMO, We can change to 2048 as default. > > > > It probably breaks rte_intr_* ABI. > > Yes. Even though all APIs are used as a pointer (ie. "struct > rte_intr_handle *"), the definition > kept in the header file. > > > > struct rte_intr_handle { > > ... > > int efds[RTE_MAX_RXTX_INTR_VEC_ID]; /**< intr vectors/efds mapping */ > > struct rte_epoll_event elist[RTE_MAX_RXTX_INTR_VEC_ID]; > > /**< intr vector epoll event */ > > ... > > > > > > I see you need this for octeontx2, so wondering if you could handle > > this differently in octeontx2 drivers? > > This is an issue with any PCIe device that has more than 512 MSIX interrupts. > > The PCI spec the max is defined as 2K. > > CN10K drivers have 1K interrupt lines per PCIe device. > > I think, following are the options. > 1) To avoid ABI breakage in default configuration use the existing patch > 2) In 21.11 break ABI and Either change to > a) RTE_MAX_RXTX_INTR_VEC_ID as 1024 > or > b) Make it full dynamic allocation based on PCI device MSIX size on probe time. > That brings some kind of dependency rte_intr with PCI device. Need to > understand, > How it can clearly be abstracted out and Is it worth trouble for the > amount of memory. > Looks like the cost of one entry is 40B. So additional 512 is 40B * > 512 = 21KB virtual memory. Since you mentioned performance is not impacted, I guess this is control path only. And there is no need to expose this. So: c) Rework API so that we don't expose such details. -- David Marchand