* Adding API to force freeing consumed buffers in TX ring
From: Damjan Marion (damarion) @ 2016-11-21 10:48 UTC (permalink / raw)
To: dev@dpdk.org
Hi,
Currently in VPP we do memcpy of whole packet when we need to do
replication as we cannot know if specific buffer is transmitted
from tx ring before we update it again (i.e. l2 header rewrite).
Unless there is already a way to address this issue in DPDK which I’m not aware
of my proposal is that we provide mechanism for polling TX ring
for consumed buffers. This can be either completely new API or
extension of rte_etx_tx_burst (i.e. special case when nb_pkts=0).
This will allows us to start polling tx ring when we expect some
mbuf back, instead of waiting for next tx burst (which we don’t know
when it will happen) and hoping that we will reach free_threshold soon.
Any thoughts?
Thanks,
Damjan
^ permalink raw reply
* Re: [RFC PATCH 0/6] Restructure EAL device model for bus support
From: Jan Blunck @ 2016-11-21 10:47 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, David Marchand, Shreyansh Jain
In-Reply-To: <29033576.pHDTdAbKFW@xps13>
On Mon, Nov 21, 2016 at 10:08 AM, Thomas Monjalon
<thomas.monjalon@6wind.com> wrote:
> 2016-11-20 16:30, David Marchand:
>> For a first patchset, I would see:
>> - introduce the rte_bus object. In rte_eal_init, for each bus, we call
>> the scan method. Then, for each bus, we find the appropriate
>> rte_driver using the bus match method then call the probe method. If
>> the probe succeeds, the rte_device points to the associated
>> rte_driver,
>> - migrate the pci scan code to a pci bus (scan looks at sysfs for
>> linux / ioctl for bsd + devargs for blacklist / whitelist ?), match is
>> the same at what is done in rte_eal_pci_probe_one_driver() at the
>> moment,
>> - migrate the vdev init code to a vdev bus (scan looks at devargs):
>> this is new, we must create rte_device objects for vdev drivers to use
>> later
>
> I think it can be 3 patchsets.
> Who can work on the vdev part please?
I'll take a look.
^ permalink raw reply
* Re: Solarflare PMD submission question
From: Ferruh Yigit @ 2016-11-21 10:30 UTC (permalink / raw)
To: Thomas Monjalon, Andrew Rybchenko; +Cc: dev
In-Reply-To: <2553236.UbBGAtvXhx@xps13>
On 11/21/2016 8:59 AM, Thomas Monjalon wrote:
> 2016-11-21 11:46, Andrew Rybchenko:
>> On 11/21/2016 11:19 AM, Thomas Monjalon wrote:
>>>> Before submitting 56 patches I'd like to double-check that checkpatch.pl
>>>> errors (for example, because of assignments in the 'if' condition,
>>>> parenthesis around return value) is not a show-stopper for base driver
>>>> import.
>>> You can run checkpatches.sh or send the patches to checkpatch@dpdk.org.
>>> The script check-git-log.sh can also guide you for the expected formatting.
>>
>> Yes, I did it and it helped me to find and fix some coding standard
>> violations.
>>
>> The problem with libefx (base driver) is that it is existing code which
>> follows FreeBSD and illumos coding conventions which contradict to
>> checkpatches.sh sometimes (e.g. require parenthesis around return
>> value). Other example of error produced by checkpatches.sh is assign in
>> if. It is widely used in the code to assign return code value and
>> compare it vs 0 in one line. It is not a coding standard conflict, but
>> it is very wide-spread in the code (so changing it will produce too many
>> changes not strictly required/useful).
>>
>> So, may I repeat my question if it is a show-stopper for base driver or
>> acceptable.
>
> I would vote to accept these minor style warnings for the base driver.
> Ferruh, any comment?
>
For _base driver_, I am also OK for having checkpatch warnings.
^ permalink raw reply
* Re: [PATCH] pmdinfogen: Fix pmdinfogen to select proper endianess on cross-compile
From: Bruce Richardson @ 2016-11-21 10:11 UTC (permalink / raw)
To: Neil Horman; +Cc: dev, Hemant Agrawal, Jerin Jacob, Thomas Monjalon
In-Reply-To: <1479494872-9302-1-git-send-email-nhorman@tuxdriver.com>
On Fri, Nov 18, 2016 at 01:47:52PM -0500, Neil Horman wrote:
> pmdinfogen has a bug in which, during build, it pulls in rte_byteorder.h to
> obtain the rte macros for byteswapping between the cpu byte order and big or
> little endian. Unfortunately, pmdinfogen is a tool that is only meant to be run
> during the build of dpdk components, and so, it runs on the host. In cross
> compile environments however, the rte_byteorder.h is configured using a target
> cpu, who's endianess may differ from that of the host, leading to improper
> swapping.
>
> The fix is to use host system defined byte swapping routines rather than the
> dpdk provided routines. Note that we are using non posix compliant routines, as
> the posix compliant api only addresses 16 and 32 bit swaps, and we also need 64
> bit swaps. Those macros exist (via endian.h), but BSD and Linux put that header
> in different locations so some ifdeffery is required.
>
> Tested successfully by myself on Linux and BSD systems.
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> CC: Hemant Agrawal <hemant.agrawal@nxp.com>
> CC: Jerin Jacob <Jerin.Jacob@cavium.com>
> CC: Bruce Richardson <bruce.richardson@intel.com>
> CC: Thomas Monjalon <thomas.monjalon@6wind.com>
> ---
> buildtools/pmdinfogen/pmdinfogen.h | 10 +++++++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
Compiles fine on FreeBSD with clang.
Tested-by: Bruce Richardson <bruce.richardson@intel.com>
^ permalink raw reply
* [PATCH v2] ethdev: check number of queues less than RTE_ETHDEV_QUEUE_STAT_CNTRS
From: Alejandro Lucero @ 2016-11-21 9:59 UTC (permalink / raw)
To: dev; +Cc: Bert van Leeuwen
From: Bert van Leeuwen <bert.vanleeuwen@netronome.com>
Arrays inside rte_eth_stats have size=RTE_ETHDEV_QUEUE_STAT_CNTRS.
Some devices report more queues than that and this code blindly uses
the reported number of queues by the device to fill those arrays up.
This patch fixes the problem using MIN between the reported number of
queues and RTE_ETHDEV_QUEUE_STAT_CNTRS.
Signed-off-by: Alejandro Lucero <alejandro.lucero@netronome.com>
---
lib/librte_ether/rte_ethdev.c | 25 +++++++++++++++++--------
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index fde8112..4209ad0 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -1343,8 +1343,10 @@ get_xstats_count(uint8_t port_id)
} else
count = 0;
count += RTE_NB_STATS;
- count += dev->data->nb_rx_queues * RTE_NB_RXQ_STATS;
- count += dev->data->nb_tx_queues * RTE_NB_TXQ_STATS;
+ count += RTE_MIN(dev->data->nb_rx_queues, RTE_ETHDEV_QUEUE_STAT_CNTRS) *
+ RTE_NB_RXQ_STATS;
+ count += RTE_MIN(dev->data->nb_tx_queues, RTE_ETHDEV_QUEUE_STAT_CNTRS) *
+ RTE_NB_TXQ_STATS;
return count;
}
@@ -1358,6 +1360,7 @@ rte_eth_xstats_get_names(uint8_t port_id,
int cnt_expected_entries;
int cnt_driver_entries;
uint32_t idx, id_queue;
+ uint16_t num_q;
cnt_expected_entries = get_xstats_count(port_id);
if (xstats_names == NULL || cnt_expected_entries < 0 ||
@@ -1374,7 +1377,8 @@ rte_eth_xstats_get_names(uint8_t port_id,
"%s", rte_stats_strings[idx].name);
cnt_used_entries++;
}
- for (id_queue = 0; id_queue < dev->data->nb_rx_queues; id_queue++) {
+ num_q = RTE_MIN(dev->data->nb_rx_queues, RTE_ETHDEV_QUEUE_STAT_CNTRS);
+ for (id_queue = 0; id_queue < num_q; id_queue++) {
for (idx = 0; idx < RTE_NB_RXQ_STATS; idx++) {
snprintf(xstats_names[cnt_used_entries].name,
sizeof(xstats_names[0].name),
@@ -1384,7 +1388,8 @@ rte_eth_xstats_get_names(uint8_t port_id,
}
}
- for (id_queue = 0; id_queue < dev->data->nb_tx_queues; id_queue++) {
+ num_q = RTE_MIN(dev->data->nb_tx_queues, RTE_ETHDEV_QUEUE_STAT_CNTRS);
+ for (id_queue = 0; id_queue < num_q; id_queue++) {
for (idx = 0; idx < RTE_NB_TXQ_STATS; idx++) {
snprintf(xstats_names[cnt_used_entries].name,
sizeof(xstats_names[0].name),
@@ -1420,14 +1425,18 @@ rte_eth_xstats_get(uint8_t port_id, struct rte_eth_xstat *xstats,
unsigned count = 0, i, q;
signed xcount = 0;
uint64_t val, *stats_ptr;
+ uint16_t nb_rxqs, nb_txqs;
RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -EINVAL);
dev = &rte_eth_devices[port_id];
+ nb_rxqs = RTE_MIN(dev->data->nb_rx_queues, RTE_ETHDEV_QUEUE_STAT_CNTRS);
+ nb_txqs = RTE_MIN(dev->data->nb_tx_queues, RTE_ETHDEV_QUEUE_STAT_CNTRS);
+
/* Return generic statistics */
- count = RTE_NB_STATS + (dev->data->nb_rx_queues * RTE_NB_RXQ_STATS) +
- (dev->data->nb_tx_queues * RTE_NB_TXQ_STATS);
+ count = RTE_NB_STATS + (nb_rxqs * RTE_NB_RXQ_STATS) +
+ (nb_txqs * RTE_NB_TXQ_STATS);
/* implemented by the driver */
if (dev->dev_ops->xstats_get != NULL) {
@@ -1458,7 +1467,7 @@ rte_eth_xstats_get(uint8_t port_id, struct rte_eth_xstat *xstats,
}
/* per-rxq stats */
- for (q = 0; q < dev->data->nb_rx_queues; q++) {
+ for (q = 0; q < nb_rxqs; q++) {
for (i = 0; i < RTE_NB_RXQ_STATS; i++) {
stats_ptr = RTE_PTR_ADD(ð_stats,
rte_rxq_stats_strings[i].offset +
@@ -1469,7 +1478,7 @@ rte_eth_xstats_get(uint8_t port_id, struct rte_eth_xstat *xstats,
}
/* per-txq stats */
- for (q = 0; q < dev->data->nb_tx_queues; q++) {
+ for (q = 0; q < nb_txqs; q++) {
for (i = 0; i < RTE_NB_TXQ_STATS; i++) {
stats_ptr = RTE_PTR_ADD(ð_stats,
rte_txq_stats_strings[i].offset +
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 0/4] libeventdev API and northbound implementation
From: Bruce Richardson @ 2016-11-21 9:57 UTC (permalink / raw)
To: Thomas Monjalon
Cc: Jerin Jacob, dev, harry.van.haaren, hemant.agrawal, gage.eads
In-Reply-To: <16834486.NTSXs6S7QZ@xps13>
On Mon, Nov 21, 2016 at 10:40:50AM +0100, Thomas Monjalon wrote:
> 2016-11-19 00:57, Jerin Jacob:
> > On Fri, Nov 18, 2016 at 04:04:29PM +0000, Bruce Richardson wrote:
> > > On Fri, Nov 18, 2016 at 03:25:18PM +0000, Bruce Richardson wrote:
> > > > On Fri, Nov 18, 2016 at 11:14:58AM +0530, Jerin Jacob wrote:
> > > > > Possible next steps:
> > > > > 1) Review this patch set
> > > > > 2) Integrate Intel's SW driver[http://dpdk.org/dev/patchwork/patch/17049/]
> > > > > 3) Review proposed examples/eventdev_pipeline application[http://dpdk.org/dev/patchwork/patch/17053/]
> > > > > 4) Review proposed functional tests[http://dpdk.org/dev/patchwork/patch/17051/]
> > > > > 5) Cavium's HW based eventdev driver
> > > > >
> > > > > I am planning to work on (3),(4) and (5)
> > > > >
> > > > Thanks Jerin,
> > > >
> > > > we'll review and get back to you with any comments or feedback (1), and
> > > > obviously start working on item (2) also! :-)
> > > >
> > > > I'm also wonder whether we should have a staging tree for this work to
> > > > make interaction between us easier. Although this may not be
> > > > finalised enough for 17.02 release, do you think having an
> > > > dpdk-eventdev-next tree would be a help? My thinking is that once we get
> > > > the eventdev library itself in reasonable shape following our review, we
> > > > could commit that and make any changes thereafter as new patches, rather
> > > > than constantly respinning the same set. It also gives us a clean git
> > > > tree to base the respective driver implementations on from our two sides.
> > > >
> > > > Thomas, any thoughts here on your end - or from anyone else?
> >
> > I was thinking more or less along the same lines. To avoid re-spinning the
> > same set, it is better to have libeventdev library mark as EXPERIMENTAL
> > and commit it somewhere on dpdk-eventdev-next or main tree
> >
> > I think, EXPERIMENTAL status can be changed only when
> > - At least two event drivers available
> > - Functional test applications fine with at least two drivers
> > - Portable example application to showcase the features of the library
> > - eventdev integration with another dpdk subsystem such as ethdev
>
> Are you asking for a temporary tree?
> If yes, please tell its name and its committers, it will be done.
Yes, we are asking for a new tree, but I would not assume it is
temporary - it might be, but it also might not be, given how other
threads are discussing having an increasing number of subtrees giving
pull requests. :-)
Name: dpdk-eventdev-next
Committers: Bruce Richardson & Jerin Jacob
Thanks,
/Bruce.
^ permalink raw reply
* Re: [PATCH] eal: postpone vdev initialization
From: Ferruh Yigit @ 2016-11-21 9:54 UTC (permalink / raw)
To: Jerin Jacob, dev; +Cc: declan.doherty, david.marchand, thomas.monjalon
In-Reply-To: <1479628850-27202-1-git-send-email-jerin.jacob@caviumnetworks.com>
On 11/20/2016 8:00 AM, Jerin Jacob wrote:
> Some platform like octeontx may use pci and
> vdev based combined device to represent a logical
> dpdk functional device.In such case, postponing the
> vdev initialization after pci device
> initialization will provide the better view of
> the pci device resources in the system in
> vdev's probe function, and it allows better
> functional subsystem registration in vdev probe
> function.
>
> As a bonus, This patch fixes a bond device
> initialization use case.
>
> example command to reproduce the issue:
> ./testpmd -c 0x2 --vdev 'eth_bond0,mode=0,
> slave=0000:02:00.0,slave=0000:03:00.0' --
> --port-topology=chained
>
> root cause:
> In existing case(vdev initialization and then pci
> initialization), creates three Ethernet ports with
> following port ids
> 0 - Bond device
> 1 - PCI device 0
> 2 - PCI devive 1
>
> Since testpmd, calls the configure/start on all the ports on
> start up,it will translate to following illegal setup sequence
>
> 1)bond device configure/start
> 1.1) pci device0 stop/configure/start
> 1.2) pci device1 stop/configure/start
> 2)pci device 0 configure(illegal setup case,
> as device in start state)
>
> The fix changes the initialization sequence and
> allow initialization in following valid setup order
> 1) pcie device 0 configure/start
> 2) pcie device 1 configure/start
> 3) bond device 2 configure/start
> 3.1) pcie device 0/stop/configure/start
> 3.2) pcie device 1/stop/configure/start
>
> Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> ---
This changes the port id assignments to the devices, right?
Previously virtual devices get first available port ids (0..N1), later
physical devices (N1..N2). Now this becomes reverse.
Can this change break some existing user applications?
Thanks,
ferruh
^ permalink raw reply
* Re: [RFC PATCH 0/7] RFC: EventDev Software PMD
From: Bruce Richardson @ 2016-11-21 9:48 UTC (permalink / raw)
To: Jerin Jacob; +Cc: Harry van Haaren, dev
In-Reply-To: <20161118222325.GA13345@localhost.localdomain>
On Sat, Nov 19, 2016 at 03:53:25AM +0530, Jerin Jacob wrote:
> On Thu, Nov 17, 2016 at 10:05:07AM +0000, Bruce Richardson wrote:
> > > 2) device stats API can be based on capability, HW implementations may not
> > > support all the stats
> >
> > Yes, this is something we were thinking about. It would be nice if we
> > could at least come up with a common set of stats - maybe even ones
> > tracked at an eventdev API level, e.g. nb enqueues/dequeues. As well as
> > that, we think the idea of an xstats API, like in ethdev, might work
> > well. For our software implementation, having visibility into the
> > scheduler behaviour can be important, so we'd like a way to report out
> > things like internal queue depths etc.
> >
>
> Since these are not very generic hardware, I am not sure how much sense
> to have generic stats API. But, Something similar to ethdev's xstat(any capability based)
> the scheme works well. Look forward to seeing API proposal with common code.
>
> Jerin
>
Well, to start off with, some stats that could be tracked at the API
level could be common. What about counts of number of enqueues and
dequeues?
I suppose the other way we can look at this is: once we get a few
implementations of the interface, we can look at the provided xstats
values from each one, and see if there is anything common between them.
/Bruce
^ permalink raw reply
* Re: [PATCH 0/4] libeventdev API and northbound implementation
From: Thomas Monjalon @ 2016-11-21 9:40 UTC (permalink / raw)
To: Jerin Jacob, Bruce Richardson
Cc: dev, harry.van.haaren, hemant.agrawal, gage.eads
In-Reply-To: <20161118192715.GA8674@localhost.localdomain>
2016-11-19 00:57, Jerin Jacob:
> On Fri, Nov 18, 2016 at 04:04:29PM +0000, Bruce Richardson wrote:
> > On Fri, Nov 18, 2016 at 03:25:18PM +0000, Bruce Richardson wrote:
> > > On Fri, Nov 18, 2016 at 11:14:58AM +0530, Jerin Jacob wrote:
> > > > Possible next steps:
> > > > 1) Review this patch set
> > > > 2) Integrate Intel's SW driver[http://dpdk.org/dev/patchwork/patch/17049/]
> > > > 3) Review proposed examples/eventdev_pipeline application[http://dpdk.org/dev/patchwork/patch/17053/]
> > > > 4) Review proposed functional tests[http://dpdk.org/dev/patchwork/patch/17051/]
> > > > 5) Cavium's HW based eventdev driver
> > > >
> > > > I am planning to work on (3),(4) and (5)
> > > >
> > > Thanks Jerin,
> > >
> > > we'll review and get back to you with any comments or feedback (1), and
> > > obviously start working on item (2) also! :-)
> > >
> > > I'm also wonder whether we should have a staging tree for this work to
> > > make interaction between us easier. Although this may not be
> > > finalised enough for 17.02 release, do you think having an
> > > dpdk-eventdev-next tree would be a help? My thinking is that once we get
> > > the eventdev library itself in reasonable shape following our review, we
> > > could commit that and make any changes thereafter as new patches, rather
> > > than constantly respinning the same set. It also gives us a clean git
> > > tree to base the respective driver implementations on from our two sides.
> > >
> > > Thomas, any thoughts here on your end - or from anyone else?
>
> I was thinking more or less along the same lines. To avoid re-spinning the
> same set, it is better to have libeventdev library mark as EXPERIMENTAL
> and commit it somewhere on dpdk-eventdev-next or main tree
>
> I think, EXPERIMENTAL status can be changed only when
> - At least two event drivers available
> - Functional test applications fine with at least two drivers
> - Portable example application to showcase the features of the library
> - eventdev integration with another dpdk subsystem such as ethdev
Are you asking for a temporary tree?
If yes, please tell its name and its committers, it will be done.
^ permalink raw reply
* Re: [PATCH 00/22] Generic flow API (rte_flow)
From: Nélio Laranjeiro @ 2016-11-21 9:23 UTC (permalink / raw)
To: Adrien Mazarguil; +Cc: dev, Thomas Monjalon, Pablo de Lara, Olivier Matz
In-Reply-To: <cover.1479309719.git.adrien.mazarguil@6wind.com>
Hi,
I found some small issues:
- In rte_flow_error_set(), *cause argument should be const to avoid a
compilation error when we implement it.
- In port_flow_create(), the flow is not stored in the pf structure
which ends by providing a null pointer to port_flow_destroy()
function.
Regards,
--
Nélio Laranjeiro
6WIND
^ permalink raw reply
* Re: [RFC PATCH 0/6] Restructure EAL device model for bus support
From: Thomas Monjalon @ 2016-11-21 9:08 UTC (permalink / raw)
To: dev; +Cc: David Marchand, Shreyansh Jain, Jan Blunck
In-Reply-To: <CALwxeUuDNdS67YJm3=Ga6vikh=0T8eyou+_jBNO3_HxtanTJxg@mail.gmail.com>
2016-11-20 16:30, David Marchand:
> For a first patchset, I would see:
> - introduce the rte_bus object. In rte_eal_init, for each bus, we call
> the scan method. Then, for each bus, we find the appropriate
> rte_driver using the bus match method then call the probe method. If
> the probe succeeds, the rte_device points to the associated
> rte_driver,
> - migrate the pci scan code to a pci bus (scan looks at sysfs for
> linux / ioctl for bsd + devargs for blacklist / whitelist ?), match is
> the same at what is done in rte_eal_pci_probe_one_driver() at the
> moment,
> - migrate the vdev init code to a vdev bus (scan looks at devargs):
> this is new, we must create rte_device objects for vdev drivers to use
> later
I think it can be 3 patchsets.
Who can work on the vdev part please?
> Then we can talk about the next steps once the bus is in place.
Yes
^ permalink raw reply
* Re: Solarflare PMD submission question
From: Thomas Monjalon @ 2016-11-21 8:59 UTC (permalink / raw)
To: Andrew Rybchenko; +Cc: dev, ferruh.yigit
In-Reply-To: <2e666e61-bc4e-1a37-f26a-a0fc18a4d988@solarflare.com>
2016-11-21 11:46, Andrew Rybchenko:
> On 11/21/2016 11:19 AM, Thomas Monjalon wrote:
> >> Before submitting 56 patches I'd like to double-check that checkpatch.pl
> >> errors (for example, because of assignments in the 'if' condition,
> >> parenthesis around return value) is not a show-stopper for base driver
> >> import.
> > You can run checkpatches.sh or send the patches to checkpatch@dpdk.org.
> > The script check-git-log.sh can also guide you for the expected formatting.
>
> Yes, I did it and it helped me to find and fix some coding standard
> violations.
>
> The problem with libefx (base driver) is that it is existing code which
> follows FreeBSD and illumos coding conventions which contradict to
> checkpatches.sh sometimes (e.g. require parenthesis around return
> value). Other example of error produced by checkpatches.sh is assign in
> if. It is widely used in the code to assign return code value and
> compare it vs 0 in one line. It is not a coding standard conflict, but
> it is very wide-spread in the code (so changing it will produce too many
> changes not strictly required/useful).
>
> So, may I repeat my question if it is a show-stopper for base driver or
> acceptable.
I would vote to accept these minor style warnings for the base driver.
Ferruh, any comment?
^ permalink raw reply
* Re: Proposal for a new Committer model
From: Thomas Monjalon @ 2016-11-21 8:52 UTC (permalink / raw)
To: Neil Horman; +Cc: dev, Mcnamara, John
In-Reply-To: <20161118161025.GC29049@hmsreliant.think-freely.org>
2016-11-18 13:09, Neil Horman:
> A) Further promote subtree maintainership. This was a conversation that I
> proposed some time ago, but my proposed granularity was discarded in favor
> of something that hasn't worked as well (in my opinion). That is to say a
> few driver pmds (i40e and fm10k come to mind) have their own tree that
> send pull requests to Thomas.
Yes we tried this fine granularity and stated that it was not working well.
We are now using the bigger granularity that you describe below.
> We should be sharding that at a much higher
> granularity and using it much more consistently. That is to say, that we
> should have a maintainer for all the ethernet pmds, and another for the
> crypto pmds, another for the core eal layer, another for misc libraries
> that have low patch volumes, etc.
Yes we could open a tree for EAL and another one for the core libraries.
> Each of those subdivisions should have
> their own list to communicate on, and each should have a tree that
> integrates patches for their own subsystem, and they should on a regular
> cycle send pull requests to Thomas.
Yes I think it is now a good idea to split the mailing list traffic,
at least for netdev and cryptodev.
> Thomas in turn should by and large,
> only be integrating pull requests. This should address our high-
> throughput issue, in that it will allow multiple maintainers to share the
> workload, and integration should be relatively easy.
Yes in an ideal organization, the last committer does only a last check
that technical plan and fairness are respected.
So it gives more time to coordinate the plans :)
> B) Designate alternates to serve as backups for the maintainer when they
> are unavailable. This provides high-availablility, and sounds very much
> like your proposal, but in the interests of clarity, there is still a
> single maintainer at any one time, it just may change to ensure the
> continued merging of patches, if the primary maintainer isn't available.
> Ideally however, those backup alternates arent needed, because most of the
> primary maintainers work in merging pull requests, which are done based on
> the trust of the submaintainer, and done during a very limited window of
> time. This also partially addreses multi-vendor fairness if your subtree
> maintainers come from multiple participating companies.
About the merge window, I do not have a strong opinion about how it can be
improved. However, I know that closing the window too early makes developer
unhappy because it makes wait - between development start and its release -
longer.
^ permalink raw reply
* Re: Solarflare PMD submission question
From: Andrew Rybchenko @ 2016-11-21 8:46 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev
In-Reply-To: <1695254.J03lBVJQtY@xps13>
On 11/21/2016 11:19 AM, Thomas Monjalon wrote:
>> Before submitting 56 patches I'd like to double-check that checkpatch.pl
>> errors (for example, because of assignments in the 'if' condition,
>> parenthesis around return value) is not a show-stopper for base driver
>> import.
> You can run checkpatches.sh or send the patches to checkpatch@dpdk.org.
> The script check-git-log.sh can also guide you for the expected formatting.
Yes, I did it and it helped me to find and fix some coding standard
violations.
The problem with libefx (base driver) is that it is existing code which
follows FreeBSD and illumos coding conventions which contradict to
checkpatches.sh sometimes (e.g. require parenthesis around return
value). Other example of error produced by checkpatches.sh is assign in
if. It is widely used in the code to assign return code value and
compare it vs 0 in one line. It is not a coding standard conflict, but
it is very wide-spread in the code (so changing it will produce too many
changes not strictly required/useful).
So, may I repeat my question if it is a show-stopper for base driver or
acceptable.
Thanks,
Andrew.
^ permalink raw reply
* Re: Solarflare PMD submission question
From: Thomas Monjalon @ 2016-11-21 8:19 UTC (permalink / raw)
To: Andrew Rybchenko; +Cc: dev
In-Reply-To: <048eabcf-7175-7500-88c4-ffeaa813c4a3@solarflare.com>
2016-11-18 19:50, Andrew Rybchenko:
> Now we have a split of the base driver import in big feature steps. The
> base driver is split into 28 patches. Just only 1 patch exceeds 300K
> boundary (which add MCDI definitions header).
Good
> Before submitting 56 patches I'd like to double-check that checkpatch.pl
> errors (for example, because of assignments in the 'if' condition,
> parenthesis around return value) is not a show-stopper for base driver
> import.
You can run checkpatches.sh or send the patches to checkpatch@dpdk.org.
The script check-git-log.sh can also guide you for the expected formatting.
^ permalink raw reply
* Re: [PATCH] eal: postpone vdev initialization
From: Shreyansh Jain @ 2016-11-21 5:09 UTC (permalink / raw)
To: Jerin Jacob; +Cc: dev, declan.doherty, david.marchand, thomas.monjalon
In-Reply-To: <1479628850-27202-1-git-send-email-jerin.jacob@caviumnetworks.com>
On Sunday 20 November 2016 01:30 PM, Jerin Jacob wrote:
> Some platform like octeontx may use pci and
> vdev based combined device to represent a logical
> dpdk functional device.In such case, postponing the
> vdev initialization after pci device
> initialization will provide the better view of
> the pci device resources in the system in
> vdev's probe function, and it allows better
> functional subsystem registration in vdev probe
> function.
>
> As a bonus, This patch fixes a bond device
> initialization use case.
>
> example command to reproduce the issue:
> ../testpmd -c 0x2 --vdev 'eth_bond0,mode=0,
> slave=0000:02:00.0,slave=0000:03:00.0' --
> --port-topology=chained
>
> root cause:
> In existing case(vdev initialization and then pci
> initialization), creates three Ethernet ports with
> following port ids
> 0 - Bond device
> 1 - PCI device 0
> 2 - PCI devive 1
>
> Since testpmd, calls the configure/start on all the ports on
> start up,it will translate to following illegal setup sequence
>
> 1)bond device configure/start
> 1.1) pci device0 stop/configure/start
> 1.2) pci device1 stop/configure/start
> 2)pci device 0 configure(illegal setup case,
> as device in start state)
>
> The fix changes the initialization sequence and
> allow initialization in following valid setup order
> 1) pcie device 0 configure/start
> 2) pcie device 1 configure/start
> 3) bond device 2 configure/start
> 3.1) pcie device 0/stop/configure/start
> 3.2) pcie device 1/stop/configure/start
>
> Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> ---
> lib/librte_eal/bsdapp/eal/eal.c | 6 +++---
> lib/librte_eal/linuxapp/eal/eal.c | 6 +++---
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/lib/librte_eal/bsdapp/eal/eal.c b/lib/librte_eal/bsdapp/eal/eal.c
> index 35e3117..2206277 100644
> --- a/lib/librte_eal/bsdapp/eal/eal.c
> +++ b/lib/librte_eal/bsdapp/eal/eal.c
> @@ -577,9 +577,6 @@ rte_eal_init(int argc, char **argv)
> rte_config.master_lcore, thread_id, cpuset,
> ret == 0 ? "" : "...");
>
> - if (rte_eal_dev_init() < 0)
> - rte_panic("Cannot init pmd devices\n");
> -
> RTE_LCORE_FOREACH_SLAVE(i) {
>
> /*
> @@ -616,6 +613,9 @@ rte_eal_init(int argc, char **argv)
> if (rte_eal_pci_probe())
> rte_panic("Cannot probe PCI\n");
>
> + if (rte_eal_dev_init() < 0)
> + rte_panic("Cannot init pmd devices\n");
> +
> rte_eal_mcfg_complete();
>
> return fctret;
> diff --git a/lib/librte_eal/linuxapp/eal/eal.c b/lib/librte_eal/linuxapp/eal/eal.c
> index 2075282..16dd5b9 100644
> --- a/lib/librte_eal/linuxapp/eal/eal.c
> +++ b/lib/librte_eal/linuxapp/eal/eal.c
> @@ -841,9 +841,6 @@ rte_eal_init(int argc, char **argv)
> rte_config.master_lcore, (int)thread_id, cpuset,
> ret == 0 ? "" : "...");
>
> - if (rte_eal_dev_init() < 0)
> - rte_panic("Cannot init pmd devices\n");
> -
> if (rte_eal_intr_init() < 0)
> rte_panic("Cannot init interrupt-handling thread\n");
>
> @@ -887,6 +884,9 @@ rte_eal_init(int argc, char **argv)
> if (rte_eal_pci_probe())
> rte_panic("Cannot probe PCI\n");
>
> + if (rte_eal_dev_init() < 0)
> + rte_panic("Cannot init pmd devices\n");
> +
> rte_eal_mcfg_complete();
>
> return fctret;
>
Movement looks fine to me.
IMO, rte_eal_dev_init() is a misleading name. It actually performs a
driver->probe for vdev - which is parallel to rte_eal_pci_probe.
-
Shreyansh
^ permalink raw reply
* Re: [PATCH v2] i40e: Fix eth_i40e_dev_init sequence on ThunderX
From: Ananyev, Konstantin @ 2016-11-20 23:21 UTC (permalink / raw)
To: Satha Rao, Zhang, Helin
Cc: Wu, Jingjing, jerin.jacob@caviumnetworks.com,
jianbo.liu@linaro.org, dev@dpdk.org
In-Reply-To: <1479473533-9393-1-git-send-email-skoteshwar@caviumnetworks.com>
Hi
>
> i40e_asq_send_command: rd32 & wr32 under ThunderX gives unpredictable
> results. To solve this include rte memory barriers
>
> Signed-off-by: Satha Rao <skoteshwar@caviumnetworks.com>
> ---
> drivers/net/i40e/base/i40e_osdep.h | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/net/i40e/base/i40e_osdep.h b/drivers/net/i40e/base/i40e_osdep.h
> index 38e7ba5..ffa3160 100644
> --- a/drivers/net/i40e/base/i40e_osdep.h
> +++ b/drivers/net/i40e/base/i40e_osdep.h
> @@ -158,7 +158,13 @@ do { \
> ((volatile uint32_t *)((char *)(a)->hw_addr + (reg)))
> static inline uint32_t i40e_read_addr(volatile void *addr)
> {
> +#if defined(RTE_ARCH_ARM64)
> + uint32_t val = rte_le_to_cpu_32(I40E_PCI_REG(addr));
> + rte_rmb();
> + return val;
If you really need an rmb/wmb with MMIO read/writes on ARM,
I think you can avoid #ifdefs here and use rte_smp_rmb/rte_smp_wmb.
BTW, I suppose if you need it for i40e, you would need it for other devices too.
Konstantin
> +#else
> return rte_le_to_cpu_32(I40E_PCI_REG(addr));
> +#endif
> }
> #define I40E_PCI_REG_WRITE(reg, value) \
> do { I40E_PCI_REG((reg)) = rte_cpu_to_le_32(value); } while (0)
> @@ -171,8 +177,16 @@ static inline uint32_t i40e_read_addr(volatile void *addr)
> I40E_PCI_REG_WRITE(I40E_PCI_REG_ADDR((hw), (reg)), (value))
>
> #define rd32(a, reg) i40e_read_addr(I40E_PCI_REG_ADDR((a), (reg)))
> +#if defined(RTE_ARCH_ARM64)
> +#define wr32(a, reg, value) \
> + do { \
> + I40E_PCI_REG_WRITE(I40E_PCI_REG_ADDR((a), (reg)), (value)); \
> + rte_wmb(); \
> + } while (0)
> +#else
> #define wr32(a, reg, value) \
> I40E_PCI_REG_WRITE(I40E_PCI_REG_ADDR((a), (reg)), (value))
> +#endif
> #define flush(a) i40e_read_addr(I40E_PCI_REG_ADDR((a), (I40E_GLGEN_STAT)))
>
> #define ARRAY_SIZE(arr) (sizeof(arr)/sizeof(arr[0]))
> --
> 2.7.4
^ permalink raw reply
* Re: [PATCH] eal: postpone vdev initialization
From: David Marchand @ 2016-11-20 16:05 UTC (permalink / raw)
To: Jerin Jacob; +Cc: dev@dpdk.org, Declan Doherty, Thomas Monjalon
In-Reply-To: <1479628850-27202-1-git-send-email-jerin.jacob@caviumnetworks.com>
On Sun, Nov 20, 2016 at 9:00 AM, Jerin Jacob
<jerin.jacob@caviumnetworks.com> wrote:
> Some platform like octeontx may use pci and
> vdev based combined device to represent a logical
> dpdk functional device.In such case, postponing the
> vdev initialization after pci device
> initialization will provide the better view of
> the pci device resources in the system in
> vdev's probe function, and it allows better
> functional subsystem registration in vdev probe
> function.
>
> As a bonus, This patch fixes a bond device
> initialization use case.
>
> example command to reproduce the issue:
> ./testpmd -c 0x2 --vdev 'eth_bond0,mode=0,
> slave=0000:02:00.0,slave=0000:03:00.0' --
> --port-topology=chained
>
> root cause:
> In existing case(vdev initialization and then pci
> initialization), creates three Ethernet ports with
> following port ids
> 0 - Bond device
> 1 - PCI device 0
> 2 - PCI devive 1
>
> Since testpmd, calls the configure/start on all the ports on
> start up,it will translate to following illegal setup sequence
>
> 1)bond device configure/start
> 1.1) pci device0 stop/configure/start
> 1.2) pci device1 stop/configure/start
> 2)pci device 0 configure(illegal setup case,
> as device in start state)
>
> The fix changes the initialization sequence and
> allow initialization in following valid setup order
> 1) pcie device 0 configure/start
> 2) pcie device 1 configure/start
> 3) bond device 2 configure/start
> 3.1) pcie device 0/stop/configure/start
> 3.2) pcie device 1/stop/configure/start
This patch is fine.
It's been a while since I looked at the bonding pmd.
I am just wondering if the bonding pmd should really start its slaves ports.
--
David Marchand
^ permalink raw reply
* Re: [RFC PATCH 0/6] Restructure EAL device model for bus support
From: David Marchand @ 2016-11-20 15:30 UTC (permalink / raw)
To: Shreyansh Jain; +Cc: dev@dpdk.org
In-Reply-To: <1479360605-20558-1-git-send-email-shreyansh.jain@nxp.com>
On Thu, Nov 17, 2016 at 6:29 AM, Shreyansh Jain <shreyansh.jain@nxp.com> wrote:
> DPDK has been inherently a PCI inclined framework. Because of this, the
> design of device tree (or list) within DPDK is also PCI inclined. A non-PCI
> device doesn't have a way of being expressed without using hooks started from
> EAL to PMD.
>
> With this cover letter, some patches are presented which try to break this
> strict linkage of EAL with PCI devices. Aim is to generalize the device
> hierarchy on the lines of how Linux handles it:
>
> device A1
> |
> +==.===='==============.============+ Bus A.
> | `--> driver A11 \
> device A2 `-> driver A12 \______
> |CPU |
> /`````
> device A1 /
> | /
> +==.===='==============.============+ Bus A`
> | `--> driver B11
> device A2 `-> driver B12
>
> Simply put:
> - a bus is connect to CPU (or core)
> - devices are conneted to Bus
> - drivers are running instances which manage one or more devices
> - bus is responsible for identifying devices (and interrupt propogation)
> - driver is responsible for initializing the device
>
> (*Reusing text from email [1])
> In context of DPDK EAL:
> - a generic bus (not a driver, not a device). I don't know how to categorize
> a bus. It is certainly not a device, and then handler for a bus (physical)
> can be considered a 'bus driver'. So, just 'rte_bus'.
> - there is a bus for each physical implementation (or virtual). So, a rte_bus
> Object for PCI, VDEV, ABC, DEF and so on.
> - Buses are registered just like a PMD - RTE_PMD_BUS_REGISTER()
> - Each registered bus is part of a doubly list.
> -- Each device inherits rte_bus
> -- Each driver inherits rte_bus
> -- Device and Drivers lists are part of rte_bus
> - eth_driver is no more required - it was just a holder for PMDs to register
> themselves. It can be replaced with rte_xxx_driver and corresponding init/
> uninit moved to rte_driver
> - rte_eth_dev modified to disassociate itself from rte_pci_device and connect
> to generic rte_device
>
> Once again, improvising from [1]:
>
> __ rte_bus_list
> /
> +----------'---+
> |rte_bus |
> | driver_list------> List of rte_bus specific
> | device_list---- devices
> | scan | `-> List of rte_bus associated
> | match | drivers
> | dump |
> | ..some refcnt| (#)
> +--|------|----+
> _________/ \_________
> +--------/----+ +-\---------------+
> |rte_device | |rte_driver |
> | rte_bus | | rte_bus |
> | rte_driver |(#) | init |
> | | | uninit |
> | devargs | | dev_private_size|
> +---||--------+ | drv_flags |(#)
> || | intr_handle(2*) |(#)
> | \ +----------\\\----+
> | \_____________ \\\
> | \ |||
> +------|---------+ +----|----------+ |||
> |rte_pci_device | |rte_xxx_device | (4*) |||
> | PCI specific | | xxx device | |||
> | info (mem,) | | specific fns | / | \
> +----------------+ +---------------+ / | \
> _____________________/ / \
> / ___/ \
> +-------------'--+ +------------'---+ +--'------------+
> |rte_pci_driver | |rte_vdev_driver | |rte_xxx_driver |
> | PCI id table, | | <probably, | | .... |
> | other driver | | nothing> | +---------------+
> | data | +----------------+
> +----------------+
>
> (1*) Problem is that probe functions have different arguments. So,
> generalizing them might be some rework in the respective device
> layers
> (2*) Interrupt handling for each driver type might be different. I am not
> sure how to generalize that either. This is grey area for me.
> (3*) Probably exposing a bitmask for device capabilities. Nothing similar
> exists now to relate it. Don't know if that is useful. Allowing
> applications to question a device about what it supports and what it
> doesn't - making it more flexible at application layer (but more code
> as well.)
> (4*) Even vdev would be an instantiated as a device. It is not being done
> currently.
> (#) Items which are still pending
>
> With this cover letter, some patches have been posted. These are _only_ for
> discussion purpose. They are not complete and neither compilable.
> All the patches, except 0001, have sufficient context about what the changes
> are and rationale for same. Obviously, code is best answer.
As said by Jan B., I too think that splitting the patches into smaller
patchsets is important.
Looking at your datamodel, some quick comments :
- Why init/uninit in rte_driver ? Why not probe/remove ?
- I don't think dev_private_size makes sense in rte_driver. The bus is
responsible for creating rte_device objects (embedded or not in
rte_$bus_device objects). If a driver needs to allocate some priv (for
whatever needs), the driver should do the allocation itself (or maybe
a helper for current eth_driver), then reference the original
rte_$bus_device object it got from the probe method.
For a first patchset, I would see:
- introduce the rte_bus object. In rte_eal_init, for each bus, we call
the scan method. Then, for each bus, we find the appropriate
rte_driver using the bus match method then call the probe method. If
the probe succeeds, the rte_device points to the associated
rte_driver,
- migrate the pci scan code to a pci bus (scan looks at sysfs for
linux / ioctl for bsd + devargs for blacklist / whitelist ?), match is
the same at what is done in rte_eal_pci_probe_one_driver() at the
moment,
- migrate the vdev init code to a vdev bus (scan looks at devargs):
this is new, we must create rte_device objects for vdev drivers to use
later
Then we can talk about the next steps once the bus is in place.
--
David Marchand
^ permalink raw reply
* Re: [PATCH 7/7] ethdev: Move filling of rte_eth_dev_info->pci_dev to dev_infos_get()
From: David Marchand @ 2016-11-20 15:23 UTC (permalink / raw)
To: Jan Blunck; +Cc: dev@dpdk.org, Shreyansh Jain
In-Reply-To: <1479636327-4166-7-git-send-email-jblunck@infradead.org>
On Sun, Nov 20, 2016 at 11:05 AM, Jan Blunck <jblunck@infradead.org> wrote:
> Only the device itself can decide its PCI or not.
>
> Signed-off-by: Jan Blunck <jblunck@infradead.org>
> ---
> drivers/net/bnx2x/bnx2x_ethdev.c | 1 +
> drivers/net/bnxt/bnxt_ethdev.c | 2 ++
> drivers/net/cxgbe/cxgbe_ethdev.c | 2 ++
> drivers/net/e1000/em_ethdev.c | 1 +
> drivers/net/e1000/igb_ethdev.c | 2 ++
> drivers/net/ena/ena_ethdev.c | 2 ++
> drivers/net/enic/enic_ethdev.c | 1 +
> drivers/net/fm10k/fm10k_ethdev.c | 1 +
> drivers/net/i40e/i40e_ethdev.c | 1 +
> drivers/net/i40e/i40e_ethdev_vf.c | 1 +
> drivers/net/ixgbe/ixgbe_ethdev.c | 2 ++
> drivers/net/mlx4/mlx4.c | 2 ++
> drivers/net/mlx5/mlx5_ethdev.c | 2 ++
> drivers/net/nfp/nfp_net.c | 1 +
> drivers/net/qede/qede_ethdev.c | 1 +
> drivers/net/szedata2/rte_eth_szedata2.c | 1 +
> drivers/net/thunderx/nicvf_ethdev.c | 2 ++
> drivers/net/virtio/virtio_ethdev.c | 1 +
> drivers/net/vmxnet3/vmxnet3_ethdev.c | 2 ++
> lib/librte_ether/rte_ethdev.c | 1 -
> 20 files changed, 28 insertions(+), 1 deletion(-)
Looks good to me.
--
David Marchand
^ permalink raw reply
* Re: [PATCH 4/7] virtio: Don't fill dev_info->driver_name
From: David Marchand @ 2016-11-20 15:22 UTC (permalink / raw)
To: Jan Blunck; +Cc: dev@dpdk.org, Shreyansh Jain
In-Reply-To: <1479636327-4166-4-git-send-email-jblunck@infradead.org>
On Sun, Nov 20, 2016 at 11:05 AM, Jan Blunck <jblunck@infradead.org> wrote:
> This is overwritten in rte_eth_dev_info_get().
>
> Signed-off-by: Jan Blunck <jblunck@infradead.org>
> ---
> drivers/net/virtio/virtio_ethdev.c | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/net/virtio/virtio_ethdev.c b/drivers/net/virtio/virtio_ethdev.c
> index 079fd6c..741688e 100644
> --- a/drivers/net/virtio/virtio_ethdev.c
> +++ b/drivers/net/virtio/virtio_ethdev.c
> @@ -1624,10 +1624,6 @@ virtio_dev_info_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
> uint64_t tso_mask;
> struct virtio_hw *hw = dev->data->dev_private;
>
> - if (dev->pci_dev)
> - dev_info->driver_name = dev->driver->pci_drv.driver.name;
> - else
> - dev_info->driver_name = "virtio_user PMD";
> dev_info->max_rx_queues =
> RTE_MIN(hw->max_queue_pairs, VIRTIO_MAX_RX_QUEUES);
> dev_info->max_tx_queues =
> --
> 2.7.4
>
I posted something similar [1], so looks good to me :-)
[1]: http://dpdk.org/dev/patchwork/patch/16991/
--
David Marchand
^ permalink raw reply
* Re: [PATCH 2/7] eal: Helper to convert to struct rte_pci_device
From: David Marchand @ 2016-11-20 15:20 UTC (permalink / raw)
To: Jan Blunck; +Cc: dev@dpdk.org, Shreyansh Jain
In-Reply-To: <1479636327-4166-2-git-send-email-jblunck@infradead.org>
Hello Jan,
On Sun, Nov 20, 2016 at 11:05 AM, Jan Blunck <jblunck@infradead.org> wrote:
> Signed-off-by: Jan Blunck <jblunck@infradead.org>
> ---
> lib/librte_eal/common/include/rte_pci.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/lib/librte_eal/common/include/rte_pci.h b/lib/librte_eal/common/include/rte_pci.h
> index 9ce8847..0376160 100644
> --- a/lib/librte_eal/common/include/rte_pci.h
> +++ b/lib/librte_eal/common/include/rte_pci.h
> @@ -160,6 +160,8 @@ struct rte_pci_device {
> enum rte_kernel_driver kdrv; /**< Kernel driver passthrough */
> };
>
> +#define ETH_DEV_PCI_DEV(ptr) ((ptr)->pci_dev)
> +
> /** Any PCI device identifier (vendor, device, ...) */
> #define PCI_ANY_ID (0xffff)
> #define RTE_CLASS_ANY_ID (0xffffff)
This should come from ethdev, not eal.
--
David Marchand
^ permalink raw reply
* [PATCH 7/7] ethdev: Move filling of rte_eth_dev_info->pci_dev to dev_infos_get()
From: Jan Blunck @ 2016-11-20 10:05 UTC (permalink / raw)
To: dev; +Cc: shreyansh.jain
In-Reply-To: <1479636327-4166-1-git-send-email-jblunck@infradead.org>
Only the device itself can decide its PCI or not.
Signed-off-by: Jan Blunck <jblunck@infradead.org>
---
drivers/net/bnx2x/bnx2x_ethdev.c | 1 +
drivers/net/bnxt/bnxt_ethdev.c | 2 ++
drivers/net/cxgbe/cxgbe_ethdev.c | 2 ++
drivers/net/e1000/em_ethdev.c | 1 +
drivers/net/e1000/igb_ethdev.c | 2 ++
drivers/net/ena/ena_ethdev.c | 2 ++
drivers/net/enic/enic_ethdev.c | 1 +
drivers/net/fm10k/fm10k_ethdev.c | 1 +
drivers/net/i40e/i40e_ethdev.c | 1 +
drivers/net/i40e/i40e_ethdev_vf.c | 1 +
drivers/net/ixgbe/ixgbe_ethdev.c | 2 ++
drivers/net/mlx4/mlx4.c | 2 ++
drivers/net/mlx5/mlx5_ethdev.c | 2 ++
drivers/net/nfp/nfp_net.c | 1 +
drivers/net/qede/qede_ethdev.c | 1 +
drivers/net/szedata2/rte_eth_szedata2.c | 1 +
drivers/net/thunderx/nicvf_ethdev.c | 2 ++
drivers/net/virtio/virtio_ethdev.c | 1 +
drivers/net/vmxnet3/vmxnet3_ethdev.c | 2 ++
lib/librte_ether/rte_ethdev.c | 1 -
20 files changed, 28 insertions(+), 1 deletion(-)
diff --git a/drivers/net/bnx2x/bnx2x_ethdev.c b/drivers/net/bnx2x/bnx2x_ethdev.c
index 0eae433..06453fe 100644
--- a/drivers/net/bnx2x/bnx2x_ethdev.c
+++ b/drivers/net/bnx2x/bnx2x_ethdev.c
@@ -431,6 +431,7 @@ static void
bnx2x_dev_infos_get(struct rte_eth_dev *dev, __rte_unused struct rte_eth_dev_info *dev_info)
{
struct bnx2x_softc *sc = dev->data->dev_private;
+ dev_info->pci_dev = ETH_DEV_PCI_DEV(dev);
dev_info->max_rx_queues = sc->max_rx_queues;
dev_info->max_tx_queues = sc->max_tx_queues;
dev_info->min_rx_bufsize = BNX2X_MIN_RX_BUF_SIZE;
diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
index cd50f11..bf39fbe 100644
--- a/drivers/net/bnxt/bnxt_ethdev.c
+++ b/drivers/net/bnxt/bnxt_ethdev.c
@@ -303,6 +303,8 @@ static void bnxt_dev_info_get_op(struct rte_eth_dev *eth_dev,
struct bnxt *bp = (struct bnxt *)eth_dev->data->dev_private;
uint16_t max_vnics, i, j, vpool, vrxq;
+ dev_info->pci_dev = ETH_DEV_PCI_DEV(eth_dev);
+
/* MAC Specifics */
dev_info->max_mac_addrs = MAX_NUM_MAC_ADDR;
dev_info->max_hash_mac_addrs = 0;
diff --git a/drivers/net/cxgbe/cxgbe_ethdev.c b/drivers/net/cxgbe/cxgbe_ethdev.c
index 8bfdda8..8938b08 100644
--- a/drivers/net/cxgbe/cxgbe_ethdev.c
+++ b/drivers/net/cxgbe/cxgbe_ethdev.c
@@ -147,6 +147,8 @@ static void cxgbe_dev_info_get(struct rte_eth_dev *eth_dev,
.nb_align = 1,
};
+ device_info->pci_dev = ETH_DEV_PCI_DEV(eth_dev);
+
device_info->min_rx_bufsize = CXGBE_MIN_RX_BUFSIZE;
device_info->max_rx_pktlen = CXGBE_MAX_RX_PKTLEN;
device_info->max_rx_queues = max_queues;
diff --git a/drivers/net/e1000/em_ethdev.c b/drivers/net/e1000/em_ethdev.c
index 7f2f521..3d34e5b 100644
--- a/drivers/net/e1000/em_ethdev.c
+++ b/drivers/net/e1000/em_ethdev.c
@@ -1048,6 +1048,7 @@ eth_em_infos_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
{
struct e1000_hw *hw = E1000_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+ dev_info->pci_dev = ETH_DEV_PCI_DEV(dev);
dev_info->min_rx_bufsize = 256; /* See BSIZE field of RCTL register. */
dev_info->max_rx_pktlen = em_get_max_pktlen(hw);
dev_info->max_mac_addrs = hw->mac.rar_entry_count;
diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index b25c66e..7d77561 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -1983,6 +1983,7 @@ eth_igb_infos_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
{
struct e1000_hw *hw = E1000_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+ dev_info->pci_dev = ETH_DEV_PCI_DEV(dev);
dev_info->min_rx_bufsize = 256; /* See BSIZE field of RCTL register. */
dev_info->max_rx_pktlen = 0x3FFF; /* See RLPML register. */
dev_info->max_mac_addrs = hw->mac.rar_entry_count;
@@ -2111,6 +2112,7 @@ eth_igbvf_infos_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
{
struct e1000_hw *hw = E1000_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+ dev_info->pci_dev = ETH_DEV_PCI_DEV(dev);
dev_info->min_rx_bufsize = 256; /* See BSIZE field of RCTL register. */
dev_info->max_rx_pktlen = 0x3FFF; /* See RLPML register. */
dev_info->max_mac_addrs = hw->mac.rar_entry_count;
diff --git a/drivers/net/ena/ena_ethdev.c b/drivers/net/ena/ena_ethdev.c
index c17d969..051275e 100644
--- a/drivers/net/ena/ena_ethdev.c
+++ b/drivers/net/ena/ena_ethdev.c
@@ -1436,6 +1436,8 @@ static void ena_infos_get(struct rte_eth_dev *dev,
ena_dev = &adapter->ena_dev;
ena_assert_msg(ena_dev != NULL, "Uninitialized device");
+ dev_info->pci_dev = ETH_DEV_PCI_DEV(dev);
+
dev_info->speed_capa =
ETH_LINK_SPEED_1G |
ETH_LINK_SPEED_2_5G |
diff --git a/drivers/net/enic/enic_ethdev.c b/drivers/net/enic/enic_ethdev.c
index 553a88e..bb5dfe6 100644
--- a/drivers/net/enic/enic_ethdev.c
+++ b/drivers/net/enic/enic_ethdev.c
@@ -459,6 +459,7 @@ static void enicpmd_dev_info_get(struct rte_eth_dev *eth_dev,
struct enic *enic = pmd_priv(eth_dev);
ENICPMD_FUNC_TRACE();
+ device_info->pci_dev = ETH_DEV_PCI_DEV(eth_dev);
/* Scattered Rx uses two receive queues per rx queue exposed to dpdk */
device_info->max_rx_queues = enic->conf_rq_count / 2;
device_info->max_tx_queues = enic->conf_wq_count;
diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
index e1250f6..5d0bce5 100644
--- a/drivers/net/fm10k/fm10k_ethdev.c
+++ b/drivers/net/fm10k/fm10k_ethdev.c
@@ -1392,6 +1392,7 @@ fm10k_dev_infos_get(struct rte_eth_dev *dev,
PMD_INIT_FUNC_TRACE();
+ dev_info->pci_dev = ETH_DEV_PCI_DEV(dev);
dev_info->min_rx_bufsize = FM10K_MIN_RX_BUF_SIZE;
dev_info->max_rx_pktlen = FM10K_MAX_PKT_SIZE;
dev_info->max_rx_queues = hw->mac.max_queues;
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 8a63a8c..29c0277 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -2583,6 +2583,7 @@ i40e_dev_info_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
struct i40e_hw *hw = I40E_DEV_PRIVATE_TO_HW(dev->data->dev_private);
struct i40e_vsi *vsi = pf->main_vsi;
+ dev_info->pci_dev = ETH_DEV_PCI_DEV(dev);
dev_info->max_rx_queues = vsi->nb_qps;
dev_info->max_tx_queues = vsi->nb_qps;
dev_info->min_rx_bufsize = I40E_BUF_SIZE_MIN;
diff --git a/drivers/net/i40e/i40e_ethdev_vf.c b/drivers/net/i40e/i40e_ethdev_vf.c
index 781e658..caef72c 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -2217,6 +2217,7 @@ i40evf_dev_info_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
struct i40e_vf *vf = I40EVF_DEV_PRIVATE_TO_VF(dev->data->dev_private);
memset(dev_info, 0, sizeof(*dev_info));
+ dev_info->pci_dev = ETH_DEV_PCI_DEV(dev);
dev_info->max_rx_queues = vf->vsi_res->num_queue_pairs;
dev_info->max_tx_queues = vf->vsi_res->num_queue_pairs;
dev_info->min_rx_bufsize = I40E_BUF_SIZE_MIN;
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index f17da46..c88b7bf 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -3043,6 +3043,7 @@ ixgbe_dev_info_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
struct rte_eth_conf *dev_conf = &dev->data->dev_conf;
struct rte_pci_device *pci_dev = ETH_DEV_PCI_DEV(dev);
+ dev_info->pci_dev = ETH_DEV_PCI_DEV(dev);
dev_info->max_rx_queues = (uint16_t)hw->mac.max_rx_queues;
dev_info->max_tx_queues = (uint16_t)hw->mac.max_tx_queues;
if (RTE_ETH_DEV_SRIOV(dev).active == 0) {
@@ -3175,6 +3176,7 @@ ixgbevf_dev_info_get(struct rte_eth_dev *dev,
struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
struct rte_pci_device *pci_dev = ETH_DEV_PCI_DEV(dev);
+ dev_info->pci_dev = ETH_DEV_PCI_DEV(dev);
dev_info->max_rx_queues = (uint16_t)hw->mac.max_rx_queues;
dev_info->max_tx_queues = (uint16_t)hw->mac.max_tx_queues;
dev_info->min_rx_bufsize = 1024; /* cf BSIZEPACKET in SRRCTL reg */
diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
index da61a85..5455fea 100644
--- a/drivers/net/mlx4/mlx4.c
+++ b/drivers/net/mlx4/mlx4.c
@@ -4421,6 +4421,8 @@ mlx4_dev_infos_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *info)
unsigned int max;
char ifname[IF_NAMESIZE];
+ info->pci_dev = ETH_DEV_PCI_DEV(dev);
+
if (priv == NULL)
return;
priv_lock(priv);
diff --git a/drivers/net/mlx5/mlx5_ethdev.c b/drivers/net/mlx5/mlx5_ethdev.c
index c0f73e9..489a4f6 100644
--- a/drivers/net/mlx5/mlx5_ethdev.c
+++ b/drivers/net/mlx5/mlx5_ethdev.c
@@ -562,6 +562,8 @@ mlx5_dev_infos_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *info)
unsigned int max;
char ifname[IF_NAMESIZE];
+ info->pci_dev = ETH_DEV_PCI_DEV(dev);
+
priv_lock(priv);
/* FIXME: we should ask the device for these values. */
info->min_rx_bufsize = 32;
diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c
index c6b1587..41eaf90 100644
--- a/drivers/net/nfp/nfp_net.c
+++ b/drivers/net/nfp/nfp_net.c
@@ -1006,6 +1006,7 @@ nfp_net_infos_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
hw = NFP_NET_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+ dev_info->pci_dev = ETH_DEV_PCI_DEV(dev);
dev_info->driver_name = dev->driver->pci_drv.driver.name;
dev_info->max_rx_queues = (uint16_t)hw->max_rx_queues;
dev_info->max_tx_queues = (uint16_t)hw->max_tx_queues;
diff --git a/drivers/net/qede/qede_ethdev.c b/drivers/net/qede/qede_ethdev.c
index 959ff0f..2c4de92 100644
--- a/drivers/net/qede/qede_ethdev.c
+++ b/drivers/net/qede/qede_ethdev.c
@@ -652,6 +652,7 @@ qede_dev_info_get(struct rte_eth_dev *eth_dev,
PMD_INIT_FUNC_TRACE(edev);
+ dev_info->pci_dev = ETH_DEV_PCI_DEV(eth_dev);
dev_info->min_rx_bufsize = (uint32_t)(ETHER_MIN_MTU +
QEDE_ETH_OVERHEAD);
dev_info->max_rx_pktlen = (uint32_t)ETH_TX_MAX_NON_LSO_PKT_LEN;
diff --git a/drivers/net/szedata2/rte_eth_szedata2.c b/drivers/net/szedata2/rte_eth_szedata2.c
index f3cd52d..585087a 100644
--- a/drivers/net/szedata2/rte_eth_szedata2.c
+++ b/drivers/net/szedata2/rte_eth_szedata2.c
@@ -1030,6 +1030,7 @@ eth_dev_info(struct rte_eth_dev *dev,
struct rte_eth_dev_info *dev_info)
{
struct pmd_internals *internals = dev->data->dev_private;
+ dev_info->pci_dev = ETH_DEV_PCI_DEV(dev);
dev_info->if_index = 0;
dev_info->max_mac_addrs = 1;
dev_info->max_rx_pktlen = (uint32_t)-1;
diff --git a/drivers/net/thunderx/nicvf_ethdev.c b/drivers/net/thunderx/nicvf_ethdev.c
index 466e49c..42ad340 100644
--- a/drivers/net/thunderx/nicvf_ethdev.c
+++ b/drivers/net/thunderx/nicvf_ethdev.c
@@ -1338,6 +1338,8 @@ nicvf_dev_info_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
PMD_INIT_FUNC_TRACE();
+ dev_info->pci_dev = ETH_DEV_PCI_DEV(dev);
+
dev_info->min_rx_bufsize = ETHER_MIN_MTU;
dev_info->max_rx_pktlen = NIC_HW_MAX_FRS;
dev_info->max_rx_queues =
diff --git a/drivers/net/virtio/virtio_ethdev.c b/drivers/net/virtio/virtio_ethdev.c
index 023101d..2eb6a06 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -1625,6 +1625,7 @@ virtio_dev_info_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
uint64_t tso_mask;
struct virtio_hw *hw = dev->data->dev_private;
+ dev_info->pci_dev = hw->dev;
dev_info->max_rx_queues =
RTE_MIN(hw->max_queue_pairs, VIRTIO_MAX_RX_QUEUES);
dev_info->max_tx_queues =
diff --git a/drivers/net/vmxnet3/vmxnet3_ethdev.c b/drivers/net/vmxnet3/vmxnet3_ethdev.c
index bcb3751..f7c0382 100644
--- a/drivers/net/vmxnet3/vmxnet3_ethdev.c
+++ b/drivers/net/vmxnet3/vmxnet3_ethdev.c
@@ -709,6 +709,8 @@ static void
vmxnet3_dev_info_get(__rte_unused struct rte_eth_dev *dev,
struct rte_eth_dev_info *dev_info)
{
+ dev_info->pci_dev = ETH_DEV_PCI_DEV(dev);
+
dev_info->max_rx_queues = VMXNET3_MAX_RX_QUEUES;
dev_info->max_tx_queues = VMXNET3_MAX_TX_QUEUES;
dev_info->min_rx_bufsize = 1518 + RTE_PKTMBUF_HEADROOM;
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index fde8112..4288577 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -1556,7 +1556,6 @@ rte_eth_dev_info_get(uint8_t port_id, struct rte_eth_dev_info *dev_info)
RTE_FUNC_PTR_OR_RET(*dev->dev_ops->dev_infos_get);
(*dev->dev_ops->dev_infos_get)(dev, dev_info);
- dev_info->pci_dev = dev->pci_dev;
dev_info->driver_name = dev->data->drv_name;
dev_info->nb_rx_queues = dev->data->nb_rx_queues;
dev_info->nb_tx_queues = dev->data->nb_tx_queues;
--
2.7.4
^ permalink raw reply related
* [PATCH 6/7] virtio: Don't depend on struct rte_eth_dev's pci_dev
From: Jan Blunck @ 2016-11-20 10:05 UTC (permalink / raw)
To: dev; +Cc: shreyansh.jain
In-Reply-To: <1479636327-4166-1-git-send-email-jblunck@infradead.org>
We don't need to depend on rte_eth_dev->pci_dev to differentiate between
the virtio_user and the virtio_pci case. Instead we can use the private
virtio_hw struct to get that information.
Signed-off-by: Jan Blunck <jblunck@infradead.org>
---
drivers/net/virtio/virtio_ethdev.c | 21 ++++++++++-----------
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/net/virtio/virtio_ethdev.c b/drivers/net/virtio/virtio_ethdev.c
index da9668e..023101d 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -483,11 +483,11 @@ virtio_init_queue(struct rte_eth_dev *dev, uint16_t vtpci_queue_idx)
hw->cvq = cvq;
}
- /* For virtio_user case (that is when dev->pci_dev is NULL), we use
+ /* For virtio_user case (that is when hw->dev is NULL), we use
* virtual address. And we need properly set _offset_, please see
* VIRTIO_MBUF_DATA_DMA_ADDR in virtqueue.h for more information.
*/
- if (dev->pci_dev)
+ if (hw->dev)
vq->offset = offsetof(struct rte_mbuf, buf_physaddr);
else {
vq->vq_ring_mem = (uintptr_t)mz->addr;
@@ -1190,7 +1190,7 @@ virtio_init_device(struct rte_eth_dev *eth_dev, uint64_t req_features)
struct virtio_hw *hw = eth_dev->data->dev_private;
struct virtio_net_config *config;
struct virtio_net_config local_config;
- struct rte_pci_device *pci_dev = eth_dev->pci_dev;
+ struct rte_pci_device *pci_dev = hw->dev;
int ret;
/* Reset the device although not necessary at startup */
@@ -1294,7 +1294,6 @@ int
eth_virtio_dev_init(struct rte_eth_dev *eth_dev)
{
struct virtio_hw *hw = eth_dev->data->dev_private;
- struct rte_pci_device *pci_dev;
uint32_t dev_flags = RTE_ETH_DEV_DETACHABLE;
int ret;
@@ -1317,10 +1316,11 @@ eth_virtio_dev_init(struct rte_eth_dev *eth_dev)
return -ENOMEM;
}
- pci_dev = eth_dev->pci_dev;
-
- if (pci_dev) {
- ret = vtpci_init(pci_dev, hw, &dev_flags);
+ /* For virtio_user case the hw->virtio_user_dev is populated by
+ * virtio_user_eth_dev_alloc() before eth_virtio_dev_init() is called.
+ */
+ if (!hw->virtio_user_dev) {
+ ret = vtpci_init(ETH_DEV_PCI_DEV(eth_dev), hw, &dev_flags);
if (ret)
return ret;
}
@@ -1343,7 +1343,6 @@ eth_virtio_dev_init(struct rte_eth_dev *eth_dev)
static int
eth_virtio_dev_uninit(struct rte_eth_dev *eth_dev)
{
- struct rte_pci_device *pci_dev;
struct virtio_hw *hw = eth_dev->data->dev_private;
PMD_INIT_FUNC_TRACE();
@@ -1353,7 +1352,6 @@ eth_virtio_dev_uninit(struct rte_eth_dev *eth_dev)
virtio_dev_stop(eth_dev);
virtio_dev_close(eth_dev);
- pci_dev = eth_dev->pci_dev;
eth_dev->dev_ops = NULL;
eth_dev->tx_pkt_burst = NULL;
@@ -1367,7 +1365,8 @@ eth_virtio_dev_uninit(struct rte_eth_dev *eth_dev)
rte_intr_callback_unregister(vtpci_intr_handle(hw),
virtio_interrupt_handler,
eth_dev);
- rte_eal_pci_unmap_device(pci_dev);
+ if (hw->dev)
+ rte_eal_pci_unmap_device(hw->dev);
PMD_INIT_LOG(DEBUG, "dev_uninit completed");
--
2.7.4
^ permalink raw reply related
* [PATCH 5/7] virtio: Add vtpci_intr_handle() helper to get rte_intr_handle
From: Jan Blunck @ 2016-11-20 10:05 UTC (permalink / raw)
To: dev; +Cc: shreyansh.jain
In-Reply-To: <1479636327-4166-1-git-send-email-jblunck@infradead.org>
This adds a helper to get the rte_intr_handle from the virtio_hw. This is
safe to do since the usage of the helper is guarded by RTE_ETH_DEV_INTR_LSC
which is only set if we found a PCI device during initialization.
Signed-off-by: Jan Blunck <jblunck@infradead.org>
---
drivers/net/virtio/virtio_ethdev.c | 12 +++++++-----
drivers/net/virtio/virtio_pci.h | 6 ++++++
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/net/virtio/virtio_ethdev.c b/drivers/net/virtio/virtio_ethdev.c
index 741688e..da9668e 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -1162,7 +1162,7 @@ virtio_interrupt_handler(__rte_unused struct rte_intr_handle *handle,
isr = vtpci_isr(hw);
PMD_DRV_LOG(INFO, "interrupt status = %#x", isr);
- if (rte_intr_enable(&dev->pci_dev->intr_handle) < 0)
+ if (rte_intr_enable(vtpci_intr_handle(hw)) < 0)
PMD_DRV_LOG(ERR, "interrupt enable failed");
if (isr & VIRTIO_PCI_ISR_CONFIG) {
@@ -1334,7 +1334,7 @@ eth_virtio_dev_init(struct rte_eth_dev *eth_dev)
/* Setup interrupt callback */
if (eth_dev->data->dev_flags & RTE_ETH_DEV_INTR_LSC)
- rte_intr_callback_register(&pci_dev->intr_handle,
+ rte_intr_callback_register(vtpci_intr_handle(hw),
virtio_interrupt_handler, eth_dev);
return 0;
@@ -1344,6 +1344,7 @@ static int
eth_virtio_dev_uninit(struct rte_eth_dev *eth_dev)
{
struct rte_pci_device *pci_dev;
+ struct virtio_hw *hw = eth_dev->data->dev_private;
PMD_INIT_FUNC_TRACE();
@@ -1363,7 +1364,7 @@ eth_virtio_dev_uninit(struct rte_eth_dev *eth_dev)
/* reset interrupt callback */
if (eth_dev->data->dev_flags & RTE_ETH_DEV_INTR_LSC)
- rte_intr_callback_unregister(&pci_dev->intr_handle,
+ rte_intr_callback_unregister(vtpci_intr_handle(hw),
virtio_interrupt_handler,
eth_dev);
rte_eal_pci_unmap_device(pci_dev);
@@ -1481,7 +1482,7 @@ virtio_dev_start(struct rte_eth_dev *dev)
return -ENOTSUP;
}
- if (rte_intr_enable(&dev->pci_dev->intr_handle) < 0) {
+ if (rte_intr_enable(vtpci_intr_handle(hw)) < 0) {
PMD_DRV_LOG(ERR, "interrupt enable failed");
return -EIO;
}
@@ -1573,12 +1574,13 @@ static void virtio_dev_free_mbufs(struct rte_eth_dev *dev)
static void
virtio_dev_stop(struct rte_eth_dev *dev)
{
+ struct virtio_hw *hw = dev->data->dev_private;
struct rte_eth_link link;
PMD_INIT_LOG(DEBUG, "stop");
if (dev->data->dev_conf.intr_conf.lsc)
- rte_intr_disable(&dev->pci_dev->intr_handle);
+ rte_intr_disable(vtpci_intr_handle(hw));
memset(&link, 0, sizeof(link));
virtio_dev_atomic_write_link_status(dev, &link);
diff --git a/drivers/net/virtio/virtio_pci.h b/drivers/net/virtio/virtio_pci.h
index de271bf..5373e39 100644
--- a/drivers/net/virtio/virtio_pci.h
+++ b/drivers/net/virtio/virtio_pci.h
@@ -317,4 +317,10 @@ uint8_t vtpci_isr(struct virtio_hw *);
uint16_t vtpci_irq_config(struct virtio_hw *, uint16_t);
+static inline struct rte_intr_handle *
+vtpci_intr_handle(struct virtio_hw *hw)
+{
+ return hw->dev ? &hw->dev->intr_handle : NULL;
+}
+
#endif /* _VIRTIO_PCI_H_ */
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox