* Re: [PATCH] examples/l3fwd: force CRC stripping for i40evf
From: Thomas Monjalon @ 2016-11-10 7:55 UTC (permalink / raw)
To: Björn Töpel, Topel, Bjorn
Cc: Yao, Lei A, Zhang, Helin, Ananyev, Konstantin, dev, Xu, Qian Q,
Wu, Jingjing
In-Reply-To: <2fddae6f-d9ee-4dfb-2a4b-3ddcda830820@gmail.com>
2016-11-10 07:17, Björn Töpel:
> As discussed in the thread, it might be better to just change the
> default in l3fwd from .hw_strip_crc = 0 to 1.
>
> I'll be looking into changing igbvf and ixgbevf to match the semantics
> of i40evf.
Just to make it sure, you mean returning an error in the driver when
a configuration cannot be applied, right?
^ permalink raw reply
* Re: [PATCH] examples/l3fwd: force CRC stripping for i40evf
From: Björn Töpel @ 2016-11-10 7:59 UTC (permalink / raw)
To: Thomas Monjalon
Cc: Yao, Lei A, Zhang, Helin, Ananyev, Konstantin, dev, Xu, Qian Q,
Wu, Jingjing
In-Reply-To: <1831654.akRUm7xrPO@xps13>
Thomas wrote:
> Just to make it sure, you mean returning an error in the driver when
> a configuration cannot be applied, right?
Yes, as in 1bbcc5d21129 ("i40evf: report error for unsupported CRC
stripping config"), where -EINVAL is returned.
Björn
^ permalink raw reply
* Re: Clarification for eth_driver changes
From: Thomas Monjalon @ 2016-11-10 8:03 UTC (permalink / raw)
To: Jianbo Liu; +Cc: dev, Shreyansh Jain, David Marchand
In-Reply-To: <CAP4Qi3_abM_c72itz7v-YXLW-F3E1Tk2Tuy8uZ5_=7Zk_kdFeQ@mail.gmail.com>
2016-11-10 15:51, Jianbo Liu:
> On 10 November 2016 at 15:26, Shreyansh Jain <shreyansh.jain@nxp.com> wrote:
> > This is what the current outline of eth_driver is:
> >
> > +------------------------+
> > | eth_driver |
> > | +---------------------+|
> > | | rte_pci_driver ||
> > | | +------------------+||
> > | | | rte_driver |||
> > | | | name[] |||
> > | | | ... |||
> > | | +------------------+||
> > | | .probe ||
> > | | .remove ||
> > | | ... ||
> > | +---------------------+|
> > | .eth_dev_init |
> > | .eth_dev_uninit |
> > +------------------------+
> >
> > This is what I was thinking:
> >
> > +---------------------+ +----------------------+
> > | rte_pci_driver | |eth_driver |
> > | +------------------+| _|_struct rte_driver *p |
> > | | rte_driver <-------/ | .eth_dev_init |
> > | | ... || | .eth_dev_uninit |
> > | | name || +----------------------+
> > | | <more> ||
> > | +------------------+|
> > | <PCI specific info>|
> > +---------------------+
> >
> > ::Impact::
> > Various drivers use the rte_pci_driver embedded in the eth_driver object for
> > device initialization.
> > == They assume that rte_pci_driver is directly embedded and hence simply
> > dereference.
> > == e.g. eth_igb_dev_init() in drivers/net/e1000/igb_ethdev.c file
> >
> > With the above change, such drivers would have to access rte_driver and then
> > perform container_of to obtain their respective rte_xxx_driver.
> > == this would be useful in case there is a non-PCI driver
> >
> > ::Problem::
> > I am not sure of reason as to why eth_driver embedded rte_pci_driver in
> > first place - other than a convenient way to define it before PCI driver
> > registration.
> >
> > As all the existing PMDs are impacted - am I missing something here in
> > making the above change?
> >
>
> How do you know eth_driver->p is pointing to a rte_pci_driver or rte_soc_driver?
> Maybe you need to add a type/flag in rte_driver.
Why do you need any bus information at ethdev level?
^ permalink raw reply
* Re: Clarification for eth_driver changes
From: David Marchand @ 2016-11-10 8:16 UTC (permalink / raw)
To: Shreyansh Jain; +Cc: dev@dpdk.org
In-Reply-To: <b81216f4-bb8e-81ec-f727-168fff11f0dd@nxp.com>
Hello Shreyansh,
On Thu, Nov 10, 2016 at 8:26 AM, Shreyansh Jain <shreyansh.jain@nxp.com> wrote:
> I need some help and clarification regarding some changes I am doing to
> cleanup the EAL code.
>
> There are some changes which should be done for eth_driver/rte_eth_device
> structures:
>
> 1. most obvious, eth_driver should be renamed to rte_eth_driver.
> 2. eth_driver currently has rte_pci_driver embedded in it
> - there can be ethernet devices which are _not_ PCI
> - in which case, this structure should be removed.
Do we really need to keep a eth_driver ?
As far as I can see, it is only a convenient wrapper for existing pci
drivers, but in the end it is just a pci_driver with ethdev context in
it that could be pushed to each existing driver.
In my initial description
http://dpdk.org/ml/archives/dev/2016-January/031390.html, what I had
in mind was only having a rte_eth_device pointing to a generic
rte_device.
If we need to invoke some generic driver ops from ethdev (I can only
see the ethdev hotplug api, maybe I missed something), then we would
go through rte_eth_device -> rte_device -> rte_driver.
The rte_driver keeps its own bus/private logic in its code, and no
need to expose a type.
> 3. Similarly, rte_eth_dev has rte_pci_device which should be replaced with
> rte_device.
Yes, that's the main change for me.
Thanks.
--
David Marchand
^ permalink raw reply
* Re: Clarification for eth_driver changes
From: Shreyansh Jain @ 2016-11-10 8:38 UTC (permalink / raw)
To: Jianbo Liu; +Cc: David Marchand, dev@dpdk.org
In-Reply-To: <CAP4Qi3_abM_c72itz7v-YXLW-F3E1Tk2Tuy8uZ5_=7Zk_kdFeQ@mail.gmail.com>
On Thursday 10 November 2016 01:21 PM, Jianbo Liu wrote:
> On 10 November 2016 at 15:26, Shreyansh Jain <shreyansh.jain@nxp.com> wrote:
>> Hello David, list,
>>
>> I need some help and clarification regarding some changes I am doing to
>> cleanup the EAL code.
>>
>> There are some changes which should be done for eth_driver/rte_eth_device
>> structures:
>>
>> 1. most obvious, eth_driver should be renamed to rte_eth_driver.
>> 2. eth_driver currently has rte_pci_driver embedded in it
>> - there can be ethernet devices which are _not_ PCI
>> - in which case, this structure should be removed.
>> 3. Similarly, rte_eth_dev has rte_pci_device which should be replaced with
>> rte_device.
>>
>> This is what the current outline of eth_driver is:
>>
>> +------------------------+
>> | eth_driver |
>> | +---------------------+|
>> | | rte_pci_driver ||
>> | | +------------------+||
>> | | | rte_driver |||
>> | | | name[] |||
>> | | | ... |||
>> | | +------------------+||
>> | | .probe ||
>> | | .remove ||
>> | | ... ||
>> | +---------------------+|
>> | .eth_dev_init |
>> | .eth_dev_uninit |
>> +------------------------+
>>
>> This is what I was thinking:
>>
>> +---------------------+ +----------------------+
>> | rte_pci_driver | |eth_driver |
>> | +------------------+| _|_struct rte_driver *p |
>> | | rte_driver <-------/ | .eth_dev_init |
>> | | ... || | .eth_dev_uninit |
>> | | name || +----------------------+
>> | | <more> ||
>> | +------------------+|
>> | <PCI specific info>|
>> +---------------------+
>>
>> ::Impact::
>> Various drivers use the rte_pci_driver embedded in the eth_driver object for
>> device initialization.
>> == They assume that rte_pci_driver is directly embedded and hence simply
>> dereference.
>> == e.g. eth_igb_dev_init() in drivers/net/e1000/igb_ethdev.c file
>>
>> With the above change, such drivers would have to access rte_driver and then
>> perform container_of to obtain their respective rte_xxx_driver.
>> == this would be useful in case there is a non-PCI driver
>>
>> ::Problem::
>> I am not sure of reason as to why eth_driver embedded rte_pci_driver in
>> first place - other than a convenient way to define it before PCI driver
>> registration.
>>
>> As all the existing PMDs are impacted - am I missing something here in
>> making the above change?
>>
>
> How do you know eth_driver->p is pointing to a rte_pci_driver or rte_soc_driver?
> Maybe you need to add a type/flag in rte_driver.
My take: PMD implementation would specify this - similar to how it is
done now. A PCI PMD would perform a container_of(rte_pci_driver,...).
I don't think we need a differentiation here - primarily because
generic doesn't handle the eth_driver.
>
>> Probably, similar is the case for rte_eth_dev.
>>
>> -
>> Shreyansh
>
--
-
Shreyansh
^ permalink raw reply
* Re: Clarification for eth_driver changes
From: Shreyansh Jain @ 2016-11-10 8:42 UTC (permalink / raw)
To: Thomas Monjalon, Jianbo Liu; +Cc: dev, David Marchand
In-Reply-To: <26890399.yRKBLeyzpS@xps13>
On Thursday 10 November 2016 01:33 PM, Thomas Monjalon wrote:
> 2016-11-10 15:51, Jianbo Liu:
>> On 10 November 2016 at 15:26, Shreyansh Jain <shreyansh.jain@nxp.com> wrote:
>>> This is what the current outline of eth_driver is:
>>>
>>> +------------------------+
>>> | eth_driver |
>>> | +---------------------+|
>>> | | rte_pci_driver ||
>>> | | +------------------+||
>>> | | | rte_driver |||
>>> | | | name[] |||
>>> | | | ... |||
>>> | | +------------------+||
>>> | | .probe ||
>>> | | .remove ||
>>> | | ... ||
>>> | +---------------------+|
>>> | .eth_dev_init |
>>> | .eth_dev_uninit |
>>> +------------------------+
>>>
>>> This is what I was thinking:
>>>
>>> +---------------------+ +----------------------+
>>> | rte_pci_driver | |eth_driver |
>>> | +------------------+| _|_struct rte_driver *p |
>>> | | rte_driver <-------/ | .eth_dev_init |
>>> | | ... || | .eth_dev_uninit |
>>> | | name || +----------------------+
>>> | | <more> ||
>>> | +------------------+|
>>> | <PCI specific info>|
>>> +---------------------+
>>>
>>> ::Impact::
>>> Various drivers use the rte_pci_driver embedded in the eth_driver object for
>>> device initialization.
>>> == They assume that rte_pci_driver is directly embedded and hence simply
>>> dereference.
>>> == e.g. eth_igb_dev_init() in drivers/net/e1000/igb_ethdev.c file
>>>
>>> With the above change, such drivers would have to access rte_driver and then
>>> perform container_of to obtain their respective rte_xxx_driver.
>>> == this would be useful in case there is a non-PCI driver
>>>
>>> ::Problem::
>>> I am not sure of reason as to why eth_driver embedded rte_pci_driver in
>>> first place - other than a convenient way to define it before PCI driver
>>> registration.
>>>
>>> As all the existing PMDs are impacted - am I missing something here in
>>> making the above change?
>>>
>>
>> How do you know eth_driver->p is pointing to a rte_pci_driver or rte_soc_driver?
>> Maybe you need to add a type/flag in rte_driver.
>
> Why do you need any bus information at ethdev level?
>
AFAIK, we don't need it. Above text is not stating anything on that
grounds either, I think. Isn't it?
-
Shreyansh
^ permalink raw reply
* Re: Clarification for eth_driver changes
From: Thomas Monjalon @ 2016-11-10 8:58 UTC (permalink / raw)
To: Shreyansh Jain; +Cc: Jianbo Liu, dev, David Marchand
In-Reply-To: <bfaf4db5-3b1c-2e2b-5395-c2219a9fb772@nxp.com>
2016-11-10 14:12, Shreyansh Jain:
> On Thursday 10 November 2016 01:33 PM, Thomas Monjalon wrote:
> > 2016-11-10 15:51, Jianbo Liu:
> >> On 10 November 2016 at 15:26, Shreyansh Jain <shreyansh.jain@nxp.com> wrote:
> >>> This is what the current outline of eth_driver is:
> >>>
> >>> +------------------------+
> >>> | eth_driver |
> >>> | +---------------------+|
> >>> | | rte_pci_driver ||
> >>> | | +------------------+||
> >>> | | | rte_driver |||
> >>> | | | name[] |||
> >>> | | | ... |||
> >>> | | +------------------+||
> >>> | | .probe ||
> >>> | | .remove ||
> >>> | | ... ||
> >>> | +---------------------+|
> >>> | .eth_dev_init |
> >>> | .eth_dev_uninit |
> >>> +------------------------+
> >>>
> >>> This is what I was thinking:
> >>>
> >>> +---------------------+ +----------------------+
> >>> | rte_pci_driver | |eth_driver |
> >>> | +------------------+| _|_struct rte_driver *p |
> >>> | | rte_driver <-------/ | .eth_dev_init |
> >>> | | ... || | .eth_dev_uninit |
> >>> | | name || +----------------------+
> >>> | | <more> ||
> >>> | +------------------+|
> >>> | <PCI specific info>|
> >>> +---------------------+
> >>>
> >>> ::Impact::
> >>> Various drivers use the rte_pci_driver embedded in the eth_driver object for
> >>> device initialization.
> >>> == They assume that rte_pci_driver is directly embedded and hence simply
> >>> dereference.
> >>> == e.g. eth_igb_dev_init() in drivers/net/e1000/igb_ethdev.c file
> >>>
> >>> With the above change, such drivers would have to access rte_driver and then
> >>> perform container_of to obtain their respective rte_xxx_driver.
> >>> == this would be useful in case there is a non-PCI driver
> >>>
> >>> ::Problem::
> >>> I am not sure of reason as to why eth_driver embedded rte_pci_driver in
> >>> first place - other than a convenient way to define it before PCI driver
> >>> registration.
> >>>
> >>> As all the existing PMDs are impacted - am I missing something here in
> >>> making the above change?
> >>>
> >>
> >> How do you know eth_driver->p is pointing to a rte_pci_driver or rte_soc_driver?
> >> Maybe you need to add a type/flag in rte_driver.
> >
> > Why do you need any bus information at ethdev level?
>
> AFAIK, we don't need it. Above text is not stating anything on that
> grounds either, I think. Isn't it?
No, I was replying to Jianbo.
Anyway, David made a more interesting comment.
^ permalink raw reply
* Re: [PATCH v7 11/21] eal/soc: implement probing of drivers
From: Shreyansh Jain @ 2016-11-10 9:10 UTC (permalink / raw)
To: Jianbo Liu; +Cc: dev, Thomas Monjalon, Jan Viktorin
In-Reply-To: <CAP4Qi3921oPtKWYH0rNQSPq_Rq_QYfLjqXP1YYLR9=3pLjsS0Q@mail.gmail.com>
On Thursday 10 November 2016 01:11 PM, Jianbo Liu wrote:
> On 10 November 2016 at 14:10, Shreyansh Jain <shreyansh.jain@nxp.com> wrote:
>> On Thursday 10 November 2016 09:00 AM, Jianbo Liu wrote:
>>>
>>> On 28 October 2016 at 20:26, Shreyansh Jain <shreyansh.jain@nxp.com>
>>> wrote:
>>>>
>>>> Each SoC PMD registers a set of callback for scanning its own bus/infra
>>>> and
>>>> matching devices to drivers when probe is called.
>>>> This patch introduces the infra for calls to SoC scan on
>>>> rte_eal_soc_init()
>>>> and match on rte_eal_soc_probe().
>>>>
>>>> Patch also adds test case for scan and probe.
>>>>
>>>> Signed-off-by: Jan Viktorin <viktorin@rehivetech.com>
>>>> Signed-off-by: Shreyansh Jain <shreyansh.jain@nxp.com>
>>>> Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
>>>> --
>>>> v4:
>>>> - Update test_soc for descriptive test function names
>>>> - Comments over test functions
>>>> - devinit and devuninint --> probe/remove
>>>> - RTE_VERIFY at some places
>>>> ---
>>>> app/test/test_soc.c | 205
>>>> ++++++++++++++++++++++-
>>>> lib/librte_eal/bsdapp/eal/rte_eal_version.map | 4 +
>>>> lib/librte_eal/common/eal_common_soc.c | 213
>>>> +++++++++++++++++++++++-
>>>> lib/librte_eal/common/include/rte_soc.h | 75 ++++++++-
>>>> lib/librte_eal/linuxapp/eal/eal.c | 5 +
>>>> lib/librte_eal/linuxapp/eal/eal_soc.c | 21 ++-
>>>> lib/librte_eal/linuxapp/eal/rte_eal_version.map | 4 +
>>>> 7 files changed, 519 insertions(+), 8 deletions(-)
>>>>
>>> ......
>>>
>>>> /**
>>>> + * SoC device scan callback, called from rte_eal_soc_init.
>>>> + * For various SoC, the bus on which devices are attached maynot be
>>>> compliant
>>>> + * to a standard platform (or platform bus itself). In which case, extra
>>>> + * steps are implemented by PMD to scan over the bus and add devices to
>>>> SoC
>>>> + * device list.
>>>> + */
>>>> +typedef void (soc_scan_t)(void);
>>>
>>>
>>> I'm still not sure about the purpose of soc_scan, and how to use it.
>>
>>
>> For each device to be used by DPDK, which cannot be scanned/identified using
>> the existing PCI/VDEV methods (sysfs/bus/pci), 'soc_scan_t' provides a way
>> for driver to make those devices part of device lists.
>>
>> Ideally, 'scan' is not a function of a driver. It is a bus function - which
>> is missing in this case.
>>
>>> If it's for each driver, it should at least struct rte_soc_driver * as
>>> its parameter.
>>
>>
>> Its for each driver - assuming that each non-PCI driver which implements it
>> knows how to find devices which it can control (for example, special area in
>> sysfs, or even platform bus).
>>
>
> Considering there are several drivers in a platform bus, each driver
> call the scan function, like the rte_eal_soc_scan_platform_bus() you
> implemented.
> The first will add soc devices to the list, but the remaining calls
> are redundant.
Indeed. This is exactly the issue we will face if we try and move this
scan/match logic to PCI - all devices are identified in one step.
There is a difference in principle here:
A SoC device/driver combination is essentially focused towards a single
type of bus<->devices. For example, a NXP PMD would implement a scan
function which would scan for all devices on NXP's bus. This would not
conflict with another XYZ SoC PMD which scans its specific bus.
There is caveat to this - the platform bus. There can be multiple
drivers which can serve platform bus compliant devices. First
PMD->scan() initiated for such a bus/device would leave all other scans
redundant.
More similar caveats will come if we consider somewhat generic buses. At
least I couldn't find any interest for such devices in the ML when I
picked this series (from where Jan left it).
Probably when more common type of PMDs come in, some default scan
implementation can check for skipping those devices which are already
added. It would be redundant but harmless.
>
> The other issue is adding the driver parameter. Do you need extra
> information from driver to scan the bus?
>
>>> If it's for each bus, why it is in rte_soc_driver?
>>
>>
>> Short answer - lack of a better place. It should be in dev.h probably
>> (rte_device/driver) but it would look out of place (as that represents PCI
>> devices also which cannot implement it - all PCI devices are scanned in one
>> go irrespective of driver)
>>
>>> I know you will implement bus driver in the future, but we need to
>>> make it clear for current simplified implementation.
>>
>>
>> Current implementation makes only a single assumption - that rather than
>> relying on EAL for identifying devices (as being done now), next best option
>> in existing framework (driver) should have control of finding devices.
>>
>> This is primarily to make the SoC work parallel to PCI implementation
>> without much top-down changes in EAL.
>>
>> Bus model, improvises it by moving this implementation a little above in
>> hierarchy - in rte_bus<-rte_driver<-PMD.
>>
>> I understand your apprehension - 'driver-scanning-for-devices' is indeed not
>> correct real world analogy. It is just a place holder for enabling those
>> drivers/PMDs which cannot work in absence of the right model.
>> And that is still work in progress.
>>
>>
>>>
>>>> +
>>>> +/**
>>>> + * Custom device<=>driver match callback for SoC
>>>> + * Unlike PCI, SoC devices don't have a fixed definition of device
>>>> + * identification. PMDs can implement a specific matching function in
>>>> which
>>>> + * driver and device objects are provided to perform custom match.
>>>> + */
>>>> +typedef int (soc_match_t)(struct rte_soc_driver *, struct rte_soc_device
>>>> *);
>>>> +
>>>> +/**
>>>> * A structure describing a SoC driver.
>>>> */
>>>> struct rte_soc_driver {
>>>> @@ -104,6 +120,8 @@ struct rte_soc_driver {
>>>> struct rte_driver driver; /**< Inherit core driver. */
>>>> soc_probe_t *probe; /**< Device probe */
>>>> soc_remove_t *remove; /**< Device remove */
>>>> + soc_scan_t *scan_fn; /**< Callback for scanning SoC
>>>> bus*/
>>>> + soc_match_t *match_fn; /**< Callback to match
>>>> dev<->drv */
>>>> const struct rte_soc_id *id_table; /**< ID table, NULL terminated
>>>> */
>>>> };
>>>>
>>>> @@ -146,12 +164,63 @@ rte_eal_compare_soc_addr(const struct rte_soc_addr
>>>> *a0,
>>>> }
>>>>
>>>> /**
>>>> + * Default function for matching the Soc driver with device. Each driver
>>>> can
>>>> + * either use this function or define their own soc matching function.
>>>> + * This function relies on the compatible string extracted from sysfs.
>>>> But,
>>>> + * a SoC might have different way of identifying its devices. Such SoC
>>>> can
>>>> + * override match_fn.
>>>> + *
>>>> + * @return
>>>> + * 0 on success
>>>> + * -1 when no match found
>>>> + */
>>>> +int
>>>> +rte_eal_soc_match_compat(struct rte_soc_driver *drv,
>>>> + struct rte_soc_device *dev);
>>>> +
>>>> +/**
>>>> + * Probe SoC devices for registered drivers.
>>>> + *
>>>> + * @return
>>>> + * 0 on success
>>>> + * !0 in case of any failure in probe
>>>> + */
>>>> +int rte_eal_soc_probe(void);
>>>> +
>>>> +/**
>>>> + * Probe the single SoC device.
>>>> + */
>>>> +int rte_eal_soc_probe_one(const struct rte_soc_addr *addr);
>>>> +
>>>> +/**
>>>> + * Close the single SoC device.
>>>> + *
>>>> + * Scan the SoC devices and find the SoC device specified by the SoC
>>>> + * address, then call the remove() function for registered driver
>>>> + * that has a matching entry in its id_table for discovered device.
>>>> + *
>>>> + * @param addr
>>>> + * The SoC address to close.
>>>> + * @return
>>>> + * - 0 on success.
>>>> + * - Negative on error.
>>>> + */
>>>> +int rte_eal_soc_detach(const struct rte_soc_addr *addr);
>>>> +
>>>> +/**
>>>> * Dump discovered SoC devices.
>>>> + *
>>>> + * @param f
>>>> + * File to dump device info in.
>>>> */
>>>> void rte_eal_soc_dump(FILE *f);
>>>>
>>>> /**
>>>> * Register a SoC driver.
>>>> + *
>>>> + * @param driver
>>>> + * Object for SoC driver to register
>>>> + * @return void
>>>> */
>>>> void rte_eal_soc_register(struct rte_soc_driver *driver);
>>>>
>>>> @@ -167,6 +236,10 @@ RTE_PMD_EXPORT_NAME(nm, __COUNTER__)
>>>>
>>>> /**
>>>> * Unregister a SoC driver.
>>>> + *
>>>> + * @param driver
>>>> + * Object for SoC driver to unregister
>>>> + * @return void
>>>> */
>>>> void rte_eal_soc_unregister(struct rte_soc_driver *driver);
>>>>
>>>> diff --git a/lib/librte_eal/linuxapp/eal/eal.c
>>>> b/lib/librte_eal/linuxapp/eal/eal.c
>>>> index 098ba02..bd775f3 100644
>>>> --- a/lib/librte_eal/linuxapp/eal/eal.c
>>>> +++ b/lib/librte_eal/linuxapp/eal/eal.c
>>>> @@ -70,6 +70,7 @@
>>>> #include <rte_cpuflags.h>
>>>> #include <rte_interrupts.h>
>>>> #include <rte_pci.h>
>>>> +#include <rte_soc.h>
>>>> #include <rte_dev.h>
>>>> #include <rte_devargs.h>
>>>> #include <rte_common.h>
>>>> @@ -890,6 +891,10 @@ rte_eal_init(int argc, char **argv)
>>>> if (rte_eal_pci_probe())
>>>> rte_panic("Cannot probe PCI\n");
>>>>
>>>> + /* Probe & Initialize SoC devices */
>>>> + if (rte_eal_soc_probe())
>>>> + rte_panic("Cannot probe SoC\n");
>>>> +
>>>> rte_eal_mcfg_complete();
>>>>
>>>> return fctret;
>>>> diff --git a/lib/librte_eal/linuxapp/eal/eal_soc.c
>>>> b/lib/librte_eal/linuxapp/eal/eal_soc.c
>>>> index 04848b9..3929a76 100644
>>>> --- a/lib/librte_eal/linuxapp/eal/eal_soc.c
>>>> +++ b/lib/librte_eal/linuxapp/eal/eal_soc.c
>>>> @@ -44,13 +44,28 @@
>>>> #include <rte_log.h>
>>>> #include <rte_soc.h>
>>>>
>>>> -#include "eal_internal_cfg.h"
>>>> -#include "eal_filesystem.h"
>>>> -#include "eal_private.h"
>>>> +#include <eal_internal_cfg.h>
>>>> +#include <eal_filesystem.h>
>>>> +#include <eal_private.h>
>>>>
>>>> /* Init the SoC EAL subsystem */
>>>> int
>>>> rte_eal_soc_init(void)
>>>> {
>>>> + struct rte_soc_driver *drv;
>>>> +
>>>> + /* SoC is disabled by default */
>>>> + if (!internal_config.enable_soc)
>>>> + return 0;
>>>> +
>>>> + /* For each registered driver, call their scan routine to perform
>>>> any
>>>> + * custom scan for devices (for example, custom buses)
>>>> + */
>>>> + TAILQ_FOREACH(drv, &soc_driver_list, next) {
>>>> + RTE_VERIFY(drv->scan_fn);
>>>> + drv->scan_fn();
>>>> + /* Ignore all errors from this */
>>>> + }
>>>> +
>>>> return 0;
>>>> }
>>>> diff --git a/lib/librte_eal/linuxapp/eal/rte_eal_version.map
>>>> b/lib/librte_eal/linuxapp/eal/rte_eal_version.map
>>>> index 0155025..c28e093 100644
>>>> --- a/lib/librte_eal/linuxapp/eal/rte_eal_version.map
>>>> +++ b/lib/librte_eal/linuxapp/eal/rte_eal_version.map
>>>> @@ -175,7 +175,11 @@ DPDK_16.11 {
>>>> rte_eal_dev_attach;
>>>> rte_eal_dev_detach;
>>>> rte_eal_map_resource;
>>>> + rte_eal_soc_detach;
>>>> rte_eal_soc_dump;
>>>> + rte_eal_soc_match;
>>>> + rte_eal_soc_probe;
>>>> + rte_eal_soc_probe_one;
>>>> rte_eal_soc_register;
>>>> rte_eal_soc_unregister;
>>>> rte_eal_unmap_resource;
>>>> --
>>>> 2.7.4
>>>>
>>>
>>
>>
>> --
>> -
>> Shreyansh
>
--
-
Shreyansh
^ permalink raw reply
* Fwd: mbuf changes
From: Alejandro Lucero @ 2016-11-10 9:19 UTC (permalink / raw)
To: dev
In-Reply-To: <CAD+H991WxWjCPR0xUza4Q_vVG1XJLOwtd98okFon1NEP9Wo49Q@mail.gmail.com>
I forgot to include dev@dpdk.org in my response.
My comment at the end o this email.
On Wed, Oct 26, 2016 at 10:28 AM, Alejandro Lucero <
alejandro.lucero@netronome.com> wrote:
>
>
> On Tue, Oct 25, 2016 at 2:05 PM, Bruce Richardson <
> bruce.richardson@intel.com> wrote:
>
>> On Tue, Oct 25, 2016 at 05:24:28PM +0530, Shreyansh Jain wrote:
>> > On Monday 24 October 2016 09:55 PM, Bruce Richardson wrote:
>> > > On Mon, Oct 24, 2016 at 04:11:33PM +0000, Wiles, Keith wrote:
>> > > >
>> > > > > On Oct 24, 2016, at 10:49 AM, Morten Brørup <
>> mb@smartsharesystems.com> wrote:
>> > > > >
>> > > > > First of all: Thanks for a great DPDK Userspace 2016!
>> > > > >
>> > > > >
>> > > > >
>> > > > > Continuing the Userspace discussion about Olivier Matz’s proposed
>> mbuf changes...
>> > >
>> > > Thanks for keeping the discussion going!
>> > > > >
>> > > > >
>> > > > >
>> > > > > 1.
>> > > > >
>> > > > > Stephen Hemminger had a noteworthy general comment about keeping
>> metadata for the NIC in the appropriate section of the mbuf: Metadata
>> generated by the NIC’s RX handler belongs in the first cache line, and
>> metadata required by the NIC’s TX handler belongs in the second cache line.
>> This also means that touching the second cache line on ingress should be
>> avoided if possible; and Bruce Richardson mentioned that for this reason
>> m->next was zeroed on free().
>> > > > >
>> > > Thinking about it, I suspect there are more fields we can reset on
>> free
>> > > to save time on alloc. Refcnt, as discussed below is one of them, but
>> so
>> > > too could be the nb_segs field and possibly others.
>> > >
>> > > > >
>> > > > >
>> > > > > 2.
>> > > > >
>> > > > > There seemed to be consensus that the size of m->refcnt should
>> match the size of m->port because a packet could be duplicated on all
>> physical ports for L3 multicast and L2 flooding.
>> > > > >
>> > > > > Furthermore, although a single physical machine (i.e. a single
>> server) with 255 physical ports probably doesn’t exist, it might contain
>> more than 255 virtual machines with a virtual port each, so it makes sense
>> extending these mbuf fields from 8 to 16 bits.
>> > > >
>> > > > I thought we also talked about removing the m->port from the mbuf
>> as it is not really needed.
>> > > >
>> > > Yes, this was mentioned, and also the option of moving the port value
>> to
>> > > the second cacheline, but it appears that NXP are using the port value
>> > > in their NIC drivers for passing in metadata, so we'd need their
>> > > agreement on any move (or removal).
>> >
>> > I am not sure where NXP's NIC came into picture on this, but now that
>> it is
>> > highlighted, this field is required for libevent implementation [1].
>> >
>> > A scheduler sending an event, which can be a packet, would only have
>> > information of a flow_id. From this matching it back to a port, without
>> > mbuf->port, would be very difficult (costly). There may be way around
>> this
>> > but at least in current proposal I think port would be important to
>> have -
>> > even if in second cache line.
>> >
>> > But, off the top of my head, as of now it is not being used for any
>> specific
>> > purpose in NXP's PMD implementation.
>> >
>> > Even the SoC patches don't necessarily rely on it except using it
>> because it
>> > is available.
>> >
>> > @Bruce: where did you get the NXP context here from?
>> >
>> Oh, I'm just mis-remembering. :-( It was someone else who was looking for
>> this - Netronome, perhaps?
>>
>> CC'ing Alejandro in the hope I'm remembering correctly second time
>> round!
>>
>>
> Yes. Thanks Bruce!
>
> So Netronome uses the port field and, as I commented on the user meeting,
> we are happy with the field going from 8 to 16 bits.
>
> In our case, this is something some clients have demanded, and if I'm not
> wrong (I'll double check this asap), the port value is for knowing where
> the packet is coming from. Think about a switch in the NIC, with ports
> linked to VFs/VMs, and one or more physical ports. That port value is not
> related to DPDK ports but to the switch ports. Code in the host (DPDK or
> not) can receive packets from the wire or from VFs through the NIC. This is
> also true for packets received by VMs, but I guess the port value is just
> interested for host code.
>
>
>
I consulted this functionality internally and it seems we do not need this
anymore. In fact, I will remove the metadata port handling soon from our
PMD.
> /Bruce
>>
>
>
^ permalink raw reply
* Re: Clarification for eth_driver changes
From: Jianbo Liu @ 2016-11-10 9:20 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: Shreyansh Jain, dev, David Marchand
In-Reply-To: <1707413.bZtX9g6zPm@xps13>
Hi Thomas,
On 10 November 2016 at 16:58, Thomas Monjalon <thomas.monjalon@6wind.com> wrote:
> 2016-11-10 14:12, Shreyansh Jain:
>> On Thursday 10 November 2016 01:33 PM, Thomas Monjalon wrote:
>> > 2016-11-10 15:51, Jianbo Liu:
>> >> On 10 November 2016 at 15:26, Shreyansh Jain <shreyansh.jain@nxp.com> wrote:
>> >>> This is what the current outline of eth_driver is:
>> >>>
>> >>> +------------------------+
>> >>> | eth_driver |
>> >>> | +---------------------+|
>> >>> | | rte_pci_driver ||
>> >>> | | +------------------+||
>> >>> | | | rte_driver |||
>> >>> | | | name[] |||
>> >>> | | | ... |||
>> >>> | | +------------------+||
>> >>> | | .probe ||
>> >>> | | .remove ||
>> >>> | | ... ||
>> >>> | +---------------------+|
>> >>> | .eth_dev_init |
>> >>> | .eth_dev_uninit |
>> >>> +------------------------+
>> >>>
>> >>> This is what I was thinking:
>> >>>
>> >>> +---------------------+ +----------------------+
>> >>> | rte_pci_driver | |eth_driver |
>> >>> | +------------------+| _|_struct rte_driver *p |
>> >>> | | rte_driver <-------/ | .eth_dev_init |
>> >>> | | ... || | .eth_dev_uninit |
>> >>> | | name || +----------------------+
>> >>> | | <more> ||
>> >>> | +------------------+|
>> >>> | <PCI specific info>|
>> >>> +---------------------+
>> >>>
>> >>> ::Impact::
>> >>> Various drivers use the rte_pci_driver embedded in the eth_driver object for
>> >>> device initialization.
>> >>> == They assume that rte_pci_driver is directly embedded and hence simply
>> >>> dereference.
>> >>> == e.g. eth_igb_dev_init() in drivers/net/e1000/igb_ethdev.c file
>> >>>
>> >>> With the above change, such drivers would have to access rte_driver and then
>> >>> perform container_of to obtain their respective rte_xxx_driver.
>> >>> == this would be useful in case there is a non-PCI driver
>> >>>
>> >>> ::Problem::
>> >>> I am not sure of reason as to why eth_driver embedded rte_pci_driver in
>> >>> first place - other than a convenient way to define it before PCI driver
>> >>> registration.
>> >>>
>> >>> As all the existing PMDs are impacted - am I missing something here in
>> >>> making the above change?
>> >>>
>> >>
>> >> How do you know eth_driver->p is pointing to a rte_pci_driver or rte_soc_driver?
>> >> Maybe you need to add a type/flag in rte_driver.
>> >
>> > Why do you need any bus information at ethdev level?
>>
>> AFAIK, we don't need it. Above text is not stating anything on that
>> grounds either, I think. Isn't it?
>
> No, I was replying to Jianbo.
> Anyway, David made a more interesting comment.
Indeed, no need as I checked the code.
It's not even a issue if using David's design.
Thanks!
Jianbo
^ permalink raw reply
* Re: [PATCH v7 11/21] eal/soc: implement probing of drivers
From: Thomas Monjalon @ 2016-11-10 9:26 UTC (permalink / raw)
To: Shreyansh Jain; +Cc: Jianbo Liu, dev, Jan Viktorin, david.marchand
In-Reply-To: <9c727b8d-2fc1-49f6-04f4-33a847b2c915@nxp.com>
2016-11-10 14:40, Shreyansh Jain:
> On Thursday 10 November 2016 01:11 PM, Jianbo Liu wrote:
> > On 10 November 2016 at 14:10, Shreyansh Jain <shreyansh.jain@nxp.com> wrote:
> >> On Thursday 10 November 2016 09:00 AM, Jianbo Liu wrote:
> >>> I'm still not sure about the purpose of soc_scan, and how to use it.
> >>
> >>
> >> For each device to be used by DPDK, which cannot be scanned/identified using
> >> the existing PCI/VDEV methods (sysfs/bus/pci), 'soc_scan_t' provides a way
> >> for driver to make those devices part of device lists.
> >>
> >> Ideally, 'scan' is not a function of a driver. It is a bus function - which
> >> is missing in this case.
> >>
> >>> If it's for each driver, it should at least struct rte_soc_driver * as
> >>> its parameter.
> >>
> >>
> >> Its for each driver - assuming that each non-PCI driver which implements it
> >> knows how to find devices which it can control (for example, special area in
> >> sysfs, or even platform bus).
> >>
> >
> > Considering there are several drivers in a platform bus, each driver
> > call the scan function, like the rte_eal_soc_scan_platform_bus() you
> > implemented.
> > The first will add soc devices to the list, but the remaining calls
> > are redundant.
>
> Indeed. This is exactly the issue we will face if we try and move this
> scan/match logic to PCI - all devices are identified in one step.
>
> There is a difference in principle here:
> A SoC device/driver combination is essentially focused towards a single
> type of bus<->devices. For example, a NXP PMD would implement a scan
> function which would scan for all devices on NXP's bus. This would not
> conflict with another XYZ SoC PMD which scans its specific bus.
>
> There is caveat to this - the platform bus. There can be multiple
> drivers which can serve platform bus compliant devices. First
> PMD->scan() initiated for such a bus/device would leave all other scans
> redundant.
>
> More similar caveats will come if we consider somewhat generic buses. At
> least I couldn't find any interest for such devices in the ML when I
> picked this series (from where Jan left it).
>
> Probably when more common type of PMDs come in, some default scan
> implementation can check for skipping those devices which are already
> added. It would be redundant but harmless.
If several drivers use the same bus, it means the bus is standard enough
to be implemented in EAL. So the scan function of this bus should be
called only once when calling the generic EAL scan function.
^ permalink raw reply
* Re: [PATCH] doc: postpone ABI changes for Tx prepare
From: Mcnamara, John @ 2016-11-10 10:16 UTC (permalink / raw)
To: Thomas Monjalon, Kulasek, TomaszX; +Cc: dev@dpdk.org
In-Reply-To: <1478730662-26664-1-git-send-email-thomas.monjalon@6wind.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Wednesday, November 9, 2016 10:31 PM
> To: Kulasek, TomaszX <tomaszx.kulasek@intel.com>
> Cc: dev@dpdk.org
> Subject: [dpdk-dev] [PATCH] doc: postpone ABI changes for Tx prepare
>
> The changes for the feature "Tx prepare" should be made in version 17.02.
>
> Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Acked-by: John McNamara <john.mcnamara@intel.com>
^ permalink raw reply
* Re: [PATCH] doc: postpone ABI changes for Tx prepare
From: Kulasek, TomaszX @ 2016-11-10 10:26 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev@dpdk.org
In-Reply-To: <1478730662-26664-1-git-send-email-thomas.monjalon@6wind.com>
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Wednesday, November 9, 2016 23:31
> To: Kulasek, TomaszX <tomaszx.kulasek@intel.com>
> Cc: dev@dpdk.org
> Subject: [PATCH] doc: postpone ABI changes for Tx prepare
>
> The changes for the feature "Tx prepare" should be made in version 17.02.
>
> Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
> ---
> doc/guides/rel_notes/deprecation.rst | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst
> b/doc/guides/rel_notes/deprecation.rst
> index 1a9e1ae..ab6014d 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -8,8 +8,8 @@ API and ABI deprecation notices are to be posted here.
> Deprecation Notices
> -------------------
>
> -* In 16.11 ABI changes are planned: the ``rte_eth_dev`` structure will be
> - extended with new function pointer ``tx_pkt_prep`` allowing
> verification
> +* In 17.02 ABI changes are planned: the ``rte_eth_dev`` structure will be
> + extended with new function pointer ``tx_pkt_prepare`` allowing
> verification
> and processing of packet burst to meet HW specific requirements before
> transmit. Also new fields will be added to the ``rte_eth_desc_lim``
> structure:
> ``nb_seg_max`` and ``nb_mtu_seg_max`` providing information about
> number of
> --
> 2.7.0
Acked-by: Tomasz Kulasek <tomaszx.kulasek@intel.com>
^ permalink raw reply
* Re: [PATCH v1] doc: announce API and ABI change for librte_ether
From: Pattan, Reshma @ 2016-11-10 10:26 UTC (permalink / raw)
To: Iremonger, Bernard; +Cc: Iremonger, Bernard, Mcnamara, John, dev@dpdk.org
In-Reply-To: <1476797888-29698-1-git-send-email-bernard.iremonger@intel.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Bernard Iremonger
> Sent: Tuesday, October 18, 2016 2:38 PM
> To: dev@dpdk.org; Mcnamara, John <john.mcnamara@intel.com>
> Cc: Iremonger, Bernard <bernard.iremonger@intel.com>
> Subject: [dpdk-dev] [PATCH v1] doc: announce API and ABI change for
> librte_ether
>
> In 17.02 five rte_eth_dev_set_vf_*** functions will be removed from
> librte_ether, renamed and moved to the ixgbe PMD.
>
> Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com>
> ---
> doc/guides/rel_notes/deprecation.rst | 36
> ++++++++++++++++++++++++++++++++++++
> 1 file changed, 36 insertions(+)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst
> b/doc/guides/rel_notes/deprecation.rst
> index 1d274d8..20e11ac 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -53,3 +53,39 @@ Deprecation Notices
> * librte_ether: an API change is planned for 17.02 for the function
> ``_rte_eth_dev_callback_process``. In 17.02 the function will return an
> ``int``
> instead of ``void`` and a fourth parameter ``void *ret_param`` will be
> added.
> +
> +* librte_ether: for 17.02 it is planned to deprecate the following five
> functions:
> +
> + ``rte_eth_dev_set_vf_rxmode``
> +
> + ``rte_eth_dev_set_vf_rx``
> +
> + ``rte_eth_dev_set_vf_tx``
> +
> + ``rte_eth_dev_set_vf_vlan_filter``
> +
> + ``rte_eth_set_vf_rate_limit``
> +
> + The following fields will be removed from ``struct eth_dev_ops``:
> +
> + ``eth_set_vf_rx_mode_t``
> +
> + ``eth_set_vf_rx_t``
> +
> + ``eth_set_vf_tx_t``
> +
> + ``eth_set_vf_vlan_filter_t``
> +
> + ``eth_set_vf_rate_limit_t``
> +
> + The functions will be renamed to the following, and moved to the ``ixgbe``
> PMD.
> +
> + ``rte_pmd_ixgbe_set_vf_rxmode``
> +
> + ``rte_pmd_ixgbe_set_vf_rx``
> +
> + ``rte_pmd_ixgbe_set_vf_tx``
> +
> + ``rte_pmd_ixgbe_set_vf_vlan_filter``
> +
> + ``rte_pmd_ixgbe_set_vf_rate_limit``
> --
> 2.10.1
Acked-by: Reshma Pattan <reshma.pattan@intel.com>
^ permalink raw reply
* Re: [PATCH v1] doc: announce API and ABI change for librte_ether
From: Ferruh Yigit @ 2016-11-10 10:36 UTC (permalink / raw)
To: Mcnamara, John, Iremonger, Bernard, dev@dpdk.org
In-Reply-To: <B27915DBBA3421428155699D51E4CFE20264A8FB@IRSMSX103.ger.corp.intel.com>
On 11/4/2016 1:39 PM, Mcnamara, John wrote:
>
>
>> -----Original Message-----
>> From: Iremonger, Bernard
>> Sent: Tuesday, October 18, 2016 2:38 PM
>> To: dev@dpdk.org; Mcnamara, John <john.mcnamara@intel.com>
>> Cc: Iremonger, Bernard <bernard.iremonger@intel.com>
>> Subject: [PATCH v1] doc: announce API and ABI change for librte_ether
>>
>> In 17.02 five rte_eth_dev_set_vf_*** functions will be removed from
>> librte_ether, renamed and moved to the ixgbe PMD.
>>
>> Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com>
>
> Acked-by: John McNamara <john.mcnamara@intel.com>
Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
^ permalink raw reply
* Re: Clarification for eth_driver changes
From: Stephen Hemminger @ 2016-11-10 10:51 UTC (permalink / raw)
To: Jianbo Liu; +Cc: David Marchand, Shreyansh Jain, dev, Thomas Monjalon
In-Reply-To: <CAP4Qi3_VzoQ9UZW52udnSUUG6HuMzRtjGpQ8jUbnKqDJrSVDcA@mail.gmail.com>
I also think drv_flags should part of device not PCI. Most of the flags
there like link state support are generic. If it isn't changed for this
release will probably have to break ABI to fully support VMBUS
^ permalink raw reply
* Re: Clarification for eth_driver changes
From: Shreyansh Jain @ 2016-11-10 11:05 UTC (permalink / raw)
To: David Marchand; +Cc: dev@dpdk.org
In-Reply-To: <CALwxeUv7aC-5AHGs6xW9B-7hR7mU4P2oCz13ReSNBKYNiq7puw@mail.gmail.com>
Hello David,
On Thursday 10 November 2016 01:46 PM, David Marchand wrote:
> Hello Shreyansh,
>
> On Thu, Nov 10, 2016 at 8:26 AM, Shreyansh Jain <shreyansh.jain@nxp.com> wrote:
>> I need some help and clarification regarding some changes I am doing to
>> cleanup the EAL code.
>>
>> There are some changes which should be done for eth_driver/rte_eth_device
>> structures:
>>
>> 1. most obvious, eth_driver should be renamed to rte_eth_driver.
>> 2. eth_driver currently has rte_pci_driver embedded in it
>> - there can be ethernet devices which are _not_ PCI
>> - in which case, this structure should be removed.
>
> Do we really need to keep a eth_driver ?
No. As you have rightly mentioned below (as well as in your Jan'16
post), it is a mere convenience.
> As far as I can see, it is only a convenient wrapper for existing pci
> drivers, but in the end it is just a pci_driver with ethdev context in
> it that could be pushed to each existing driver.
Indeed. My problem (or lack of understanding) is that all PMDs rely on
it and I don't know in what all pattern they have envisioned using this
model of ethdev->pci_dev, the initialization sequences.
rte_device->init/uninit would settle most of those worries, I think.
>
> In my initial description
> http://dpdk.org/ml/archives/dev/2016-January/031390.html, what I had
> in mind was only having a rte_eth_device pointing to a generic
> rte_device.
Though I had read it (during the rte_device/driver series) but didn't
remember it while posting this. I agree with your point of doing away
with eth_driver.
> If we need to invoke some generic driver ops from ethdev (I can only
> see the ethdev hotplug api, maybe I missed something), then we would
> go through rte_eth_device -> rte_device -> rte_driver.
Agree with you.
> The rte_driver keeps its own bus/private logic in its code, and no
> need to expose a type.
Agree.
>
>
>> 3. Similarly, rte_eth_dev has rte_pci_device which should be replaced with
>> rte_device.
>
> Yes, that's the main change for me.
Indeed. This is a big change. It impacts a lot of EAL code.
>
>
> Thanks.
>
Intent of this email was to know if I am missing something in assuming
that eth_driver is actually not being used much. I will keep the
comments from your email in mind while making changes. Thanks.
_
Shreyansh
^ permalink raw reply
* Re: Clarification for eth_driver changes
From: Thomas Monjalon @ 2016-11-10 11:07 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Jianbo Liu, David Marchand, Shreyansh Jain, dev
In-Reply-To: <CAOaVG16rdaGTNpVxiY2qhX1=zLJfgjrpAnLGRmxzJ3eVGKUfYA@mail.gmail.com>
Hi Stephen,
2016-11-10 02:51, Stephen Hemminger:
> I also think drv_flags should part of device not PCI. Most of the flags
> there like link state support are generic. If it isn't changed for this
> release will probably have to break ABI to fully support VMBUS
When do you plan to send VMBUS patches?
Could you send a deprecation notice for this change?
Are you aware of the work started by Shreyansh to have a generic bus model?
Could you help in 17.02 timeframe to have a solid bus model?
Thanks
^ permalink raw reply
* Re: Clarification for eth_driver changes
From: Shreyansh Jain @ 2016-11-10 11:09 UTC (permalink / raw)
To: Stephen Hemminger, Jianbo Liu; +Cc: David Marchand, dev, Thomas Monjalon
In-Reply-To: <CAOaVG16rdaGTNpVxiY2qhX1=zLJfgjrpAnLGRmxzJ3eVGKUfYA@mail.gmail.com>
On Thursday 10 November 2016 04:21 PM, Stephen Hemminger wrote:
> I also think drv_flags should part of device not PCI. Most of the flags
> there like link state support are generic. If it isn't changed for this
> release will probably have to break ABI to fully support VMBUS
>
I didn't get your point.
Currently drv_flags is in rte_pci_driver.
You intend to say that it should be moved to rte_device?
And, all the changes being discussed here are for 17.02.
-
Shreyansh
^ permalink raw reply
* Re: [PATCH] doc: add more tested platforms and nics and OSes
From: Mcnamara, John @ 2016-11-10 11:13 UTC (permalink / raw)
To: Pei, Yulong, dev@dpdk.org; +Cc: thomas.monjalon@6wind.com
In-Reply-To: <1478772164-8270-1-git-send-email-yulong.pei@intel.com>
> -----Original Message-----
> From: Pei, Yulong
> Sent: Thursday, November 10, 2016 10:03 AM
> To: dev@dpdk.org
> Cc: Mcnamara, John <john.mcnamara@intel.com>; thomas.monjalon@6wind.com;
> Pei, Yulong <yulong.pei@intel.com>
> Subject: [PATCH] doc: add more tested platforms and nics and OSes
>
> Add more tested platforms and nics and OSes to the release notes.
>
> Signed-off-by: Yulong Pei <yulong.pei@intel.com>
Acked-by: John McNamara <john.mcnamara@intel.com>
^ permalink raw reply
* [PATCH] doc: announce API and ABI changes for librte_eal
From: Shreyansh Jain @ 2016-11-10 11:17 UTC (permalink / raw)
To: nhorman; +Cc: dev, thomas.monjalon, Shreyansh Jain
Signed-off-by: Shreyansh Jain <shreyansh.jain@nxp.com>
---
doc/guides/rel_notes/deprecation.rst | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 1a9e1ae..2af2476 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -35,3 +35,13 @@ Deprecation Notices
* mempool: The functions for single/multi producer/consumer are deprecated
and will be removed in 17.02.
It is replaced by ``rte_mempool_generic_get/put`` functions.
+
+* ABI/API changes are planned for 17.02: ``rte_device``, ``rte_driver`` will be
+ impacted because of introduction of a new ``rte_bus`` hierarchy. This would
+ also impact the way devices are identified by EAL. A bus-device-driver model
+ will be introduced providing a hierarchical view of devices.
+
+* ``eth_driver`` is planned to be removed in 17.02. This currently serves as
+ a placeholder for PMDs to register themselves. Changes for ``rte_bus`` will
+ provide a way to handle device initialization currently being done in
+ ``eth_driver``.
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] doc: postpone ABI changes for Tx prepare
From: Ananyev, Konstantin @ 2016-11-10 11:15 UTC (permalink / raw)
To: Thomas Monjalon, Kulasek, TomaszX; +Cc: dev@dpdk.org
In-Reply-To: <1478730662-26664-1-git-send-email-thomas.monjalon@6wind.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Wednesday, November 9, 2016 10:31 PM
> To: Kulasek, TomaszX <tomaszx.kulasek@intel.com>
> Cc: dev@dpdk.org
> Subject: [dpdk-dev] [PATCH] doc: postpone ABI changes for Tx prepare
>
> The changes for the feature "Tx prepare" should be made in version 17.02.
>
> Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
> ---
> doc/guides/rel_notes/deprecation.rst | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index 1a9e1ae..ab6014d 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -8,8 +8,8 @@ API and ABI deprecation notices are to be posted here.
> Deprecation Notices
> -------------------
>
> -* In 16.11 ABI changes are planned: the ``rte_eth_dev`` structure will be
> - extended with new function pointer ``tx_pkt_prep`` allowing verification
> +* In 17.02 ABI changes are planned: the ``rte_eth_dev`` structure will be
> + extended with new function pointer ``tx_pkt_prepare`` allowing verification
> and processing of packet burst to meet HW specific requirements before
> transmit. Also new fields will be added to the ``rte_eth_desc_lim`` structure:
> ``nb_seg_max`` and ``nb_mtu_seg_max`` providing information about number of
> --
Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> 2.7.0
^ permalink raw reply
* [PATCH] i40e: Fix eth_i40e_dev_init sequence on ThunderX
From: Satha Rao @ 2016-11-10 12:04 UTC (permalink / raw)
To: helin.zhang; +Cc: jingjing.wu, jerin.jacob, jianbo.liu, dev, Satha Rao
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_adminq.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/i40e/base/i40e_adminq.c b/drivers/net/i40e/base/i40e_adminq.c
index 0d3a83f..1038a95 100644
--- a/drivers/net/i40e/base/i40e_adminq.c
+++ b/drivers/net/i40e/base/i40e_adminq.c
@@ -832,6 +832,7 @@ enum i40e_status_code i40e_asq_send_command(struct i40e_hw *hw,
}
val = rd32(hw, hw->aq.asq.head);
+ rte_rmb();
if (val >= hw->aq.num_asq_entries) {
i40e_debug(hw, I40E_DEBUG_AQ_MESSAGE,
"AQTX: head overrun at %d\n", val);
@@ -929,8 +930,10 @@ enum i40e_status_code i40e_asq_send_command(struct i40e_hw *hw,
(hw->aq.asq.next_to_use)++;
if (hw->aq.asq.next_to_use == hw->aq.asq.count)
hw->aq.asq.next_to_use = 0;
- if (!details->postpone)
+ if (!details->postpone) {
wr32(hw, hw->aq.asq.tail, hw->aq.asq.next_to_use);
+ rte_wmb();
+ }
/* if cmd_details are not defined or async flag is not set,
* we need to wait for desc write back
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] i40e: Fix eth_i40e_dev_init sequence on ThunderX
From: Jerin Jacob @ 2016-11-10 12:11 UTC (permalink / raw)
To: Satha Rao; +Cc: helin.zhang, jingjing.wu, jianbo.liu, dev
In-Reply-To: <1478779467-35123-1-git-send-email-skoteshwar@caviumnetworks.com>
On Thu, Nov 10, 2016 at 04:04:27AM -0800, Satha Rao wrote:
> 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_adminq.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/i40e/base/i40e_adminq.c b/drivers/net/i40e/base/i40e_adminq.c
> index 0d3a83f..1038a95 100644
> --- a/drivers/net/i40e/base/i40e_adminq.c
> +++ b/drivers/net/i40e/base/i40e_adminq.c
> @@ -832,6 +832,7 @@ enum i40e_status_code i40e_asq_send_command(struct i40e_hw *hw,
> }
>
> val = rd32(hw, hw->aq.asq.head);
> + rte_rmb();
use rte_smp_rmb() variant to avoid performance regression on x86
> if (val >= hw->aq.num_asq_entries) {
> i40e_debug(hw, I40E_DEBUG_AQ_MESSAGE,
> "AQTX: head overrun at %d\n", val);
> @@ -929,8 +930,10 @@ enum i40e_status_code i40e_asq_send_command(struct i40e_hw *hw,
> (hw->aq.asq.next_to_use)++;
> if (hw->aq.asq.next_to_use == hw->aq.asq.count)
> hw->aq.asq.next_to_use = 0;
> - if (!details->postpone)
> + if (!details->postpone) {
> wr32(hw, hw->aq.asq.tail, hw->aq.asq.next_to_use);
> + rte_wmb();
ditto
> + }
>
> /* if cmd_details are not defined or async flag is not set,
> * we need to wait for desc write back
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH] maintainers: add staging tree for network drivers
From: Ferruh Yigit @ 2016-11-10 12:14 UTC (permalink / raw)
To: dev; +Cc: Bruce Richardson, Thomas Monjalon
In-Reply-To: <20160725162143.GA34436@bricha3-MOBL3>
Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
---
CC: Bruce Richardson <bruce.richardson@intel.com>
CC: Thomas Monjalon <thomas.monjalon@6wind.com>
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 065397b..d6bb8f8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -252,6 +252,8 @@ F: examples/l2fwd-crypto/
Networking Drivers
------------------
+M: Ferruh Yigit <ferruh.yigit@intel.com>
+T: git://dpdk.org/next/dpdk-next-net
Link bonding
M: Declan Doherty <declan.doherty@intel.com>
--
2.9.3
^ 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