From: Jerin Jacob <jerinjacobk@gmail.com>
To: David Marchand <david.marchand@redhat.com>
Cc: Ray Kinsella <mdr@ashroe.eu>,
Pavan Nikhilesh <pbhagavatula@marvell.com>,
Harman Kalra <hkalra@marvell.com>,
Thomas Monjalon <thomas@monjalon.net>,
Jerin Jacob <jerinj@marvell.com>,
Bruce Richardson <bruce.richardson@intel.com>,
dpdk-dev <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH 1/2] eal: make max interrupt vector id configurable
Date: Wed, 24 Mar 2021 21:50:00 +0530 [thread overview]
Message-ID: <CALBAE1O+ZB07YAtWA_C=AY-RZZTSaJeRZm1-+Yk6=yMFgCM2dQ@mail.gmail.com> (raw)
In-Reply-To: <CAJFAV8zTP=rFveAvx6oFJT-VoGbqA3-8X8=h3Rmbd3tRQkLKJg@mail.gmail.com>
On Wed, Mar 24, 2021 at 8:56 PM David Marchand
<david.marchand@redhat.com> wrote:
>
> On Wed, Mar 24, 2021 at 1:55 PM Jerin Jacob <jerinjacobk@gmail.com> 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.
Yes.
> And there is no need to expose this.
> So:
>
> c) Rework API so that we don't expose such details.
Yes. That's what I meant by option (b).("Make it fully dynamic
allocation based on PCI device MSIX size on probe time.")
>
>
> --
> David Marchand
>
prev parent reply other threads:[~2021-03-24 16:20 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-25 19:01 pbhagavatula
2021-02-25 19:01 ` [dpdk-dev] [PATCH 2/2] config: increase interrupt vectors for octeontx2 pbhagavatula
2021-03-24 11:01 ` [dpdk-dev] [PATCH 1/2] eal: make max interrupt vector id configurable Jerin Jacob
2021-03-24 11:14 ` David Marchand
2021-03-24 12:54 ` Jerin Jacob
2021-03-24 15:25 ` David Marchand
2021-03-24 16:20 ` Jerin Jacob [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CALBAE1O+ZB07YAtWA_C=AY-RZZTSaJeRZm1-+Yk6=yMFgCM2dQ@mail.gmail.com' \
--to=jerinjacobk@gmail.com \
--cc=bruce.richardson@intel.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=hkalra@marvell.com \
--cc=jerinj@marvell.com \
--cc=mdr@ashroe.eu \
--cc=pbhagavatula@marvell.com \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).