[dpdk-dev] [PATCH] ethdev: fix doc comment for struct rte_flow_action
The struct rte_flow_action was missing from DPDK API documentation. Signed-off-by: Jan Viktorin --- lib/ethdev/rte_flow.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h index 961a5884fe..70f455d47d 100644 --- a/lib/ethdev/rte_flow.h +++ b/lib/ethdev/rte_flow.h @@ -3278,7 +3278,7 @@ rte_flow_dynf_metadata_set(struct rte_mbuf *m, uint32_t v) *RTE_FLOW_DYNF_METADATA(m) = v; } -/* +/** * Definition of a single action. * * A list of actions is terminated by a END action. -- 2.32.0
Re: [dpdk-dev] [PATCH 3/3] net/bonding: start ethdev prior to setting 8023ad flow
On Sun, 4 Jul 2021 15:18:01 +
Matan Azrad wrote:
> From: Havlík Martin
> > Dne 2021-06-23 09:04, Min Hu (Connor) napsal:
> > > 在 2021/6/22 17:25, Martin Havlik 写道:
> > >> When dedicated queues are enabled, mlx5 PMD fails to install RTE
> > >> Flows if the underlying ethdev is not started:
> > >> bond_ethdev_8023ad_flow_set(267) - bond_ethdev_8023ad_flow_set:
> > port
> > >> not started (slave_port=0 queue_id=1)
> > >>
> > > Why mlx5 PMD doing flow create relys on port started ?
> > > I noticed other PMDs did not has that reliance.
> > >
> > After looking into it, I really can't answer this mlx5 centered
> > question. Closest related info we found so far is the 5th point in
> > https://doc.dpdk.org/guides/prog_guide/rte_flow.html#caveats
> > but it only specifies it's the application's responsibility and
> > that flow rules are assumed invalid after port stop/close/restart
> > but doesn't say anything about vs
> > where the former is the point of
> > failure on mlx5. I'm addressing the maintainers for mlx5, who might
> > know a bit more on the topic.
>
Hello Matan,
> From rte_ethdev.h
>
> * Please note that some configuration is not stored between calls to
> * rte_eth_dev_stop()/rte_eth_dev_start(). The following
> configuration will
> * be retained:
> *
> * - MTU
> * - flow control settings
> * - receive mode configuration (promiscuous mode, all-multicast
> mode,
> * hardware checksum mode, RSS/VMDQ settings etc.)
> * - VLAN filtering configuration
> * - default MAC address
> * - MAC addresses supplied to MAC address array
> * - flow director filtering mode (but not filtering rules)
> * - NIC queue statistics mappings
just after this section, you can find the following statement:
* Any other configuration will not be stored and will need to be re-entered
* before a call to rte_eth_dev_start().
It is not very clear how is this exactly related to flows (and this
applies for all the quoted section, I think) but at least it can be used
as a counter argument.
>
>
> Mlx5 assumes flows are allowed to be configured only after
> rte_eth_dev_start(). Before start \ after stop - no flow is valid
> anymore.
I believe that this discussion is not about validity of flows. Let the flows
be invalid after calling to rte_eth_dev_stop(). This is OK, flows must be
recreated and the bonding driver works this way. But why not *before start*?
Does somebody know how other drivers behaves in this situation? (We know and
can check for Intel, there it does not seem to be an issue.)
By the way, the mlx5 behaviour opens a (probably short) time window
between starting of a port and configuation of filtering flows. You may
want to start the port with thousands of flows that apply just when the
port starts (not after, that's late). This may introduce glitches in
filtering and measuring of traffic (well, it is a question how serious
issue could it be...).
This matters for the bonding case as well, doesn't it?. It is not
desirable to accidently omit a packet that was received by primary
ingress logic instead of being redirected into the dedicated queue.
Are there any chances that for mlx5 it would be possible to insert flow
rules before calling rte_eth_dev_start? Anyway, the behaviour should be
specified and documented in DPDK more precisely to avoid such
uncertainty in the future.
Jan
>
> Matan
>
> > >> Signed-off-by: Martin Havlik
> > >> Cc: Jan Viktorin
> > >> ---
> > >> drivers/net/bonding/rte_eth_bond_pmd.c | 26
> > >> ++
> > >> 1 file changed, 18 insertions(+), 8 deletions(-)
> > >>
> > >> diff --git a/drivers/net/bonding/rte_eth_bond_pmd.c
> > >> b/drivers/net/bonding/rte_eth_bond_pmd.c
> > >> index a6755661c..fea3bc537 100644
> > >> --- a/drivers/net/bonding/rte_eth_bond_pmd.c
> > >> +++ b/drivers/net/bonding/rte_eth_bond_pmd.c
> > >> @@ -1818,25 +1818,35 @@ slave_configure(struct rte_eth_dev
> > >> *bonded_eth_dev,
> > >> rte_flow_destroy(slave_eth_dev->data->port_id,
> > >>
> > >> internals-
> > >mode4.dedicated_queues.flow[slave_eth_dev->data->port_id],
> > >> &flow_error);
> > >> +}
> > >> + /* Start device */
> > >> +errval = rte_eth_dev_start(slave_eth_dev->data->port_id);
> > >> +if (errval != 0) {
> > >> +
Re: [dpdk-dev] [PATCH 3/3] net/bonding: start ethdev prior to setting 8023ad flow
On Sun, 11 Jul 2021 08:49:18 + Ori Kam wrote: > Hi Jan, Hi Ori, > > > > -Original Message- > > From: dev On Behalf Of Jan Viktorin > > Sent: Wednesday, July 7, 2021 6:54 PM > > > > On Sun, 4 Jul 2021 15:18:01 + > > Matan Azrad wrote: > > > > > From: Havlík Martin > > > > Dne 2021-06-23 09:04, Min Hu (Connor) napsal: > > > > > 在 2021/6/22 17:25, Martin Havlik 写道: > > > > >> When dedicated queues are enabled, mlx5 PMD fails to install RTE > > > > >> Flows if the underlying ethdev is not started: > > > > >> bond_ethdev_8023ad_flow_set(267) - > > bond_ethdev_8023ad_flow_set: > > > > port > > > > >> not started (slave_port=0 queue_id=1) > > > > >> > > > > > Why mlx5 PMD doing flow create relys on port started ? > > > > > I noticed other PMDs did not has that reliance. > > > > > > > > > After looking into it, I really can't answer this mlx5 centered > > > > question. Closest related info we found so far is the 5th point in > > > > https://doc.dpdk.org/guides/prog_guide/rte_flow.html#caveats > > > > but it only specifies it's the application's responsibility and that > > > > flow rules are assumed invalid after port stop/close/restart but > > > > doesn't say anything about vs > > > > where the former is the point of > > > > failure on mlx5. I'm addressing the maintainers for mlx5, who might > > > > know a bit more on the topic. > > > > > > > Hello Matan, > > > > > From rte_ethdev.h > > > > > > * Please note that some configuration is not stored between calls to > > > * rte_eth_dev_stop()/rte_eth_dev_start(). The following configuration > > > will > > > * be retained: > > > * > > > * - MTU > > > * - flow control settings > > > * - receive mode configuration (promiscuous mode, all-multicast > > > mode, > > > * hardware checksum mode, RSS/VMDQ settings etc.) > > > * - VLAN filtering configuration > > > * - default MAC address > > > * - MAC addresses supplied to MAC address array > > > * - flow director filtering mode (but not filtering rules) > > > * - NIC queue statistics mappings > > > > just after this section, you can find the following statement: > > > > * Any other configuration will not be stored and will need to be re-entered > > * before a call to rte_eth_dev_start(). > > > > It is not very clear how is this exactly related to flows (and this applies > > for all > > the quoted section, I think) but at least it can be used as a counter > > argument. > > > I agree the doc is not clear, as I see it flows are not part of > configuration, at least not > when we are talking about rte_flow. Agree. > > > > > > > > > > Mlx5 assumes flows are allowed to be configured only after > > > rte_eth_dev_start(). Before start \ after stop - no flow is valid > > > anymore. > > > > I believe that this discussion is not about validity of flows. Let the > > flows be > > invalid after calling to rte_eth_dev_stop(). This is OK, flows must be > > recreated and the bonding driver works this way. But why not *before > > start*? > Think about it this way by changing the configuration you may create invalid > flows, > for example, you can only change the number of queues after port stop, so if > you create a flow with jump to queue 3 and then you remove queue 3 then, > the flow that is cached is not valid anymore. This goes for other > configuration that > may affect the validity of a flow. This is a valid argument, of course. The thing is whether it is a responsibility of the PMD to take care of those corner cases or if this is up to the application developer. If we respect the fact that calling to stop invalidates all flows then when you do: > port stop 0 > flow create 0 ingress pattern ... / end actions queue 6 / end > port config rxq 3 > port start 0 it's clear that something is really wrong with the caller/user. I would say that this is an application bug. I would expect that you first reconfigure port and after that you modify flows. It seems quite logical and intuitive, doesn't it? Anyway, the PMD can possibly catch this rxq inconsistency but I can imagine that there are more complicated sitations than just changing count of queues. Any idea for a more
Re: [dpdk-dev] [PATCH 3/3] net/bonding: start ethdev prior to setting 8023ad flow
On Tue, 13 Jul 2021 12:26:35 +0300 Andrew Rybchenko wrote: > On 7/13/21 11:18 AM, Havlík Martin wrote: > > Dne 2021-07-12 15:07, Ori Kam napsal: > >> Hi Jan, > >> > >>> -----Original Message- > >>> From: Jan Viktorin > >>> Sent: Monday, July 12, 2021 12:46 AM > >>> > >>> On Sun, 11 Jul 2021 08:49:18 + > >>> Ori Kam wrote: > >>> > >>> > Hi Jan, > >>> > >>> Hi Ori, > >>> > >>> > > >>> > > >>> > > -Original Message- > >>> > > From: dev On Behalf Of Jan Viktorin > >>> > > Sent: Wednesday, July 7, 2021 6:54 PM > >>> > > > >>> > > On Sun, 4 Jul 2021 15:18:01 + > >>> > > Matan Azrad wrote: > >>> > > > >>> > > > From: Havlík Martin > >>> > > > > Dne 2021-06-23 09:04, Min Hu (Connor) napsal: > >>> > > > > > 在 2021/6/22 17:25, Martin Havlik 写道: > >>> > > > > >> When dedicated queues are enabled, mlx5 PMD fails to > >>> > > > > >> install RTE Flows if the underlying ethdev is not > >>> > > > > >> started: bond_ethdev_8023ad_flow_set(267) - > >>> > > bond_ethdev_8023ad_flow_set: > >>> > > > > port > >>> > > > > >> not started (slave_port=0 queue_id=1) > >>> > > > > >> > >>> > > > > > Why mlx5 PMD doing flow create relys on port started ? > >>> > > > > > I noticed other PMDs did not has that reliance. > >>> > > > > > > >>> > > > > After looking into it, I really can't answer this mlx5 > >>> > > > > centered question. Closest related info we found so far > >>> > > > > is the 5th point in > >>> > > > > https://doc.dpdk.org/guides/prog_guide/rte_flow.html#caveats > >>> > > > > but it only specifies it's the application's > >>> > > > > responsibility and that flow rules are assumed invalid > >>> > > > > after port stop/close/restart but doesn't say anything > >>> > > > > about vs >>> > > > > - flow rule create> where the former is the point of > >>> > > > > failure on mlx5. I'm addressing the maintainers for mlx5, > >>> > > > > who might know a bit more on the topic. > >>> > > > > >>> > > > >>> > > Hello Matan, > >>> > > > >>> > > > From rte_ethdev.h > >>> > > > > >>> > > > * Please note that some configuration is not stored between > >>> > > > calls to > >>> > > > * rte_eth_dev_stop()/rte_eth_dev_start(). The following > >>> > > > configuration will > >>> > > > * be retained: > >>> > > > * > >>> > > > * - MTU > >>> > > > * - flow control settings > >>> > > > * - receive mode configuration (promiscuous mode, > >>> all-multicast > >>> > > > mode, > >>> > > > * hardware checksum mode, RSS/VMDQ settings etc.) > >>> > > > * - VLAN filtering configuration > >>> > > > * - default MAC address > >>> > > > * - MAC addresses supplied to MAC address array > >>> > > > * - flow director filtering mode (but not filtering > >>> > > >rules) > >>> > > > * - NIC queue statistics mappings > >>> > > > >>> > > just after this section, you can find the following statement: > >>> > > > >>> > > * Any other configuration will not be stored and will need > >>> > >to be > >>> > > re-entered > >>> > > * before a call to rte_eth_dev_start(). > >>> > > > >>> > > It is not very clear how is this exactly related to flows > >>> > > (and this applies for all the quoted section, I think) but at > >>> > > least it can > >>> be used as a > >>> counter argument. > >>> > > > >>
Re: [dpdk-dev] [PATCH 3/3] net/bonding: start ethdev prior to setting 8023ad flow
On Tue, 13 Jul 2021 17:17:51 + Ori Kam wrote: > Hi Jan, > > > -Original Message- > > From: Jan Viktorin > > Sent: Tuesday, July 13, 2021 2:06 PM > > > > On Tue, 13 Jul 2021 12:26:35 +0300 > > Andrew Rybchenko wrote: > > > > > On 7/13/21 11:18 AM, Havlík Martin wrote: > > > > Dne 2021-07-12 15:07, Ori Kam napsal: > > > >> Hi Jan, > > > >> > > > >>> -Original Message- > > > >>> From: Jan Viktorin > > > >>> Sent: Monday, July 12, 2021 12:46 AM > > > >>> > > > >>> On Sun, 11 Jul 2021 08:49:18 + Ori Kam > > > >>> wrote: > > > >>> > > > >>> > Hi Jan, > > > >>> > > > >>> Hi Ori, > > > >>> > > > >>> > > > > >>> > > > > >>> > > -Original Message- > > > >>> > > From: dev On Behalf Of Jan Viktorin > > > >>> > > Sent: Wednesday, July 7, 2021 6:54 PM > > > >>> > > > > > >>> > > On Sun, 4 Jul 2021 15:18:01 + Matan Azrad > > > >>> > > wrote: > > > >>> > > > > > >>> > > > From: Havlík Martin > > > >>> > > > > Dne 2021-06-23 09:04, Min Hu (Connor) napsal: > > > >>> > > > > > 在 2021/6/22 17:25, Martin Havlik 写道: > > > >>> > > > > >> When dedicated queues are enabled, mlx5 PMD fails > > > >>> > > > > >> to install RTE Flows if the underlying ethdev is > > > >>> > > > > >> not started: bond_ethdev_8023ad_flow_set(267) - > > > >>> > > bond_ethdev_8023ad_flow_set: > > > >>> > > > > port > > > >>> > > > > >> not started (slave_port=0 queue_id=1) > > > >>> > > > > >> > > > >>> > > > > > Why mlx5 PMD doing flow create relys on port > > > >>> > > > > > started ? I noticed other PMDs did not has that > > > >>> > > > > > reliance. > > > >>> > > > > After looking into it, I really can't answer this mlx5 > > > >>> > > > > centered question. Closest related info we found so > > > >>> > > > > far is the 5th point in > > > >>> > > > > https://doc.dpdk.org/guides/prog_guide/rte_flow.html#cavea > > > >>> > > > > ts but it only specifies it's the application's > > > >>> > > > > responsibility and that flow rules are assumed invalid > > > >>> > > > > after port stop/close/restart but doesn't say anything > > > >>> > > > > about vs > > >>> > > > > start > > > >>> > > > > - flow rule create> where the former is the point of > > > >>> > > > > failure on mlx5. I'm addressing the maintainers for > > > >>> > > > > mlx5, who might know a bit more on the topic. > > > >>> > > > > > > >>> > > > > > >>> > > Hello Matan, > > > >>> > > > > > >>> > > > From rte_ethdev.h > > > >>> > > > > > > >>> > > > * Please note that some configuration is not stored > > > >>> > > > between > > > >>> > > >calls to > > > >>> > > > * rte_eth_dev_stop()/rte_eth_dev_start(). The following > > > >>> > > >configuration will > > > >>> > > > * be retained: > > > >>> > > > * > > > >>> > > > * - MTU > > > >>> > > > * - flow control settings > > > >>> > > > * - receive mode configuration (promiscuous mode, > > > >>> all-multicast > > > >>> > > > mode, > > > >>> > > > * hardware checksum mode, RSS/VMDQ settings etc.) > > > >>> > > > * - VLAN filtering configuration > > > >>> > > > * - default MAC address > > &g
Re: [dpdk-dev] [PATCH 2/2] fib: announce experimental tag removal of the fib API
On Thu, 5 Aug 2021 15:27:15 +0200 "Medvedkin, Vladimir" wrote: > Hi Jan, > > The RIB is always used as a control plane struct intended to maintain > the correct content of the dataplane struct, such as DIR24_8 for > example. So it is always used on _add()/_delete(). For simplicity you > can consider it as an LPM's rule_info. But instead of keeping routes > in a plane array as it is in LPM, FIB uses RIB which is more suitable > binary tree. OK. I thought that I can have a single RIB, use it for maintaining routes and based on this single RIB, I can build a FIB for the data plane. And when the single RIB is updated (which can take quite a lot of time) I build a new FIB and locklessly give it to the dataplane. Such approach is not considered? Jan > > > On 05/08/2021 15:14, Jan Viktorin wrote: > > On Thu, 5 Aug 2021 15:08:13 +0200 > > Vladimir Medvedkin wrote: > > > >> This patch announces the experimental tag removal of all fib APIs, > >> which have been experimental for 2 years. > >> API will be promoted to stable in DPDK 21.11 > > > > Hi Vladimir, > > > > I have a question related to FIB. I am just learning how to use it > > and I found that each FIB always creates a new RIB internally. > > There is no doc about this topic... > > > > If I understand correctly, the underlying RIB is only used when > > dummy_lookup() and dummy_modify() are used. But they are only used > > when the configured mode is RTE_FIB_DUMMY. Is there any reason to > > create the RIB with RTE_FIB_DIR24_8? > > > > The issue with this is that each RIB allocates a new mempool > > internally which can waste quite a lot of never used memory that > > would be unused with DIR24_8 implementation. > > > > Regards > > Jan > > > >> > >> > >> Signed-off-by: Vladimir Medvedkin > >> --- > >> doc/guides/rel_notes/deprecation.rst | 2 ++ > >> 1 file changed, 2 insertions(+) > >> > >> diff --git a/doc/guides/rel_notes/deprecation.rst > >> b/doc/guides/rel_notes/deprecation.rst > >> index afb599a..58826a8 100644 > >> --- a/doc/guides/rel_notes/deprecation.rst > >> +++ b/doc/guides/rel_notes/deprecation.rst > >> @@ -195,3 +195,5 @@ Deprecation Notices > >> communicate events such as soft expiry with IPsec in lookaside > >> mode. > >> * rib: The ``rib`` library will be promoted from experimental to > >> stable. + > >> +* fib: The ``fib`` library will be promoted from experimental to > >> stable. >
Re: [dpdk-dev] [PATCH 2/2] fib: announce experimental tag removal of the fib API
On Thu, 5 Aug 2021 15:57:14 +0200 "Medvedkin, Vladimir" wrote: > On 05/08/2021 15:32, Jan Viktorin wrote: > > On Thu, 5 Aug 2021 15:27:15 +0200 > > "Medvedkin, Vladimir" wrote: > > > >> Hi Jan, > >> > >> The RIB is always used as a control plane struct intended to > >> maintain the correct content of the dataplane struct, such as > >> DIR24_8 for example. So it is always used on _add()/_delete(). For > >> simplicity you can consider it as an LPM's rule_info. But instead > >> of keeping routes in a plane array as it is in LPM, FIB uses RIB > >> which is more suitable binary tree. > > > > OK. I thought that I can have a single RIB, use it for maintaining > > routes and based on this single RIB, I can build a FIB for the data > > plane. And when the single RIB is updated (which can take quite a > > lot of time) I build a new FIB and locklessly give it to the > > dataplane. Such approach is not considered? > > > > Jan > > > > I'm not sure I understood completely your use case. Do you want to > rebuild the entire FIB from scratch every time the RIB changes? The idea was to maintain a single RIB and two FIBs. One FIB is active and under heavy load and when a route change arrives, it is first written to RIB. When RIB is ready, it is used to quickly construct/update the second inactive FIB. Then I swap with the current active FIB. The old one can be edited/updated/recreated and new one is active. I've got one place where all routes are placed (RIB). And two FIBs that contain only routes that are relevant. (Well, yes, not all routes in RIB might be relevant, this depends on other conditions.) Jan > > >> > >> > >> On 05/08/2021 15:14, Jan Viktorin wrote: > >>> On Thu, 5 Aug 2021 15:08:13 +0200 > >>> Vladimir Medvedkin wrote: > >>> > >>>> This patch announces the experimental tag removal of all fib > >>>> APIs, which have been experimental for 2 years. > >>>> API will be promoted to stable in DPDK 21.11 > >>> > >>> Hi Vladimir, > >>> > >>> I have a question related to FIB. I am just learning how to use it > >>> and I found that each FIB always creates a new RIB internally. > >>> There is no doc about this topic... > >>> > >>> If I understand correctly, the underlying RIB is only used when > >>> dummy_lookup() and dummy_modify() are used. But they are only used > >>> when the configured mode is RTE_FIB_DUMMY. Is there any reason to > >>> create the RIB with RTE_FIB_DIR24_8? > >>> > >>> The issue with this is that each RIB allocates a new mempool > >>> internally which can waste quite a lot of never used memory that > >>> would be unused with DIR24_8 implementation. > >>> > >>> Regards > >>> Jan > >>> > >>>> > >>>> > >>>> Signed-off-by: Vladimir Medvedkin > >>>> --- > >>>>doc/guides/rel_notes/deprecation.rst | 2 ++ > >>>>1 file changed, 2 insertions(+) > >>>> > >>>> diff --git a/doc/guides/rel_notes/deprecation.rst > >>>> b/doc/guides/rel_notes/deprecation.rst > >>>> index afb599a..58826a8 100644 > >>>> --- a/doc/guides/rel_notes/deprecation.rst > >>>> +++ b/doc/guides/rel_notes/deprecation.rst > >>>> @@ -195,3 +195,5 @@ Deprecation Notices > >>>> communicate events such as soft expiry with IPsec in > >>>> lookaside mode. > >>>>* rib: The ``rib`` library will be promoted from experimental > >>>> to stable. + > >>>> +* fib: The ``fib`` library will be promoted from experimental to > >>>> stable. > >> > > >
Re: [dpdk-dev] [PATCH 2/2] fib: announce experimental tag removal of the fib API
On Thu, 5 Aug 2021 16:29:50 +0200 "Medvedkin, Vladimir" wrote: > On 05/08/2021 16:07, Jan Viktorin wrote: > > On Thu, 5 Aug 2021 15:57:14 +0200 > > "Medvedkin, Vladimir" wrote: > > > >> On 05/08/2021 15:32, Jan Viktorin wrote: > >>> On Thu, 5 Aug 2021 15:27:15 +0200 > >>> "Medvedkin, Vladimir" wrote: > >>> > >>>> Hi Jan, > >>>> > >>>> The RIB is always used as a control plane struct intended to > >>>> maintain the correct content of the dataplane struct, such as > >>>> DIR24_8 for example. So it is always used on _add()/_delete(). > >>>> For simplicity you can consider it as an LPM's rule_info. But > >>>> instead of keeping routes in a plane array as it is in LPM, FIB > >>>> uses RIB which is more suitable binary tree. > >>> > >>> OK. I thought that I can have a single RIB, use it for maintaining > >>> routes and based on this single RIB, I can build a FIB for the > >>> data plane. And when the single RIB is updated (which can take > >>> quite a lot of time) I build a new FIB and locklessly give it to > >>> the dataplane. Such approach is not considered? > >>> > >>> Jan > >>> > >> > >> I'm not sure I understood completely your use case. Do you want to > >> rebuild the entire FIB from scratch every time the RIB changes? > > > > The idea was to maintain a single RIB and two FIBs. One FIB is > > active and under heavy load and when a route change arrives, it is > > first written to RIB. When RIB is ready, it is used to quickly > > construct/update the second inactive FIB. Then I swap with the > > current active FIB. The old one can be edited/updated/recreated and > > new one is active. > > > > I've got one place where all routes are placed (RIB). And two FIBs > > that contain only routes that are relevant. (Well, yes, not all > > routes in RIB might be relevant, this depends on other conditions.) > > > > Jan > > > > This technique is used for data structures that do not support > incremental updates. However FIB supports incremental updates. > > You can keep a separate rib struct and reflect changes to the fib. But reflecting the changes is sometimes really more difficult than just rebuilding from scratch. > > Also, using rte_fib_get_rib() you can get the corresponding RIB > struct and work with it directly using rib API. However you need to But than I've got two RIBs that I have to keep in sync with each other which is quite difficult. > be cautious, all adding/deletion and next hop changing must be done > using fib API. Because, otherwise the DIR24_8 is not in sync, right? Jan > > >> > >>>> > >>>> > >>>> On 05/08/2021 15:14, Jan Viktorin wrote: > >>>>> On Thu, 5 Aug 2021 15:08:13 +0200 > >>>>> Vladimir Medvedkin wrote: > >>>>> > >>>>>> This patch announces the experimental tag removal of all fib > >>>>>> APIs, which have been experimental for 2 years. > >>>>>> API will be promoted to stable in DPDK 21.11 > >>>>> > >>>>> Hi Vladimir, > >>>>> > >>>>> I have a question related to FIB. I am just learning how to use > >>>>> it and I found that each FIB always creates a new RIB > >>>>> internally. There is no doc about this topic... > >>>>> > >>>>> If I understand correctly, the underlying RIB is only used when > >>>>> dummy_lookup() and dummy_modify() are used. But they are only > >>>>> used when the configured mode is RTE_FIB_DUMMY. Is there any > >>>>> reason to create the RIB with RTE_FIB_DIR24_8? > >>>>> > >>>>> The issue with this is that each RIB allocates a new mempool > >>>>> internally which can waste quite a lot of never used memory that > >>>>> would be unused with DIR24_8 implementation. > >>>>> > >>>>> Regards > >>>>> Jan > >>>>> > >>>>>> > >>>>>> > >>>>>> Signed-off-by: Vladimir Medvedkin > >>>>>> --- > >>>>>> doc/guides/rel_notes/deprecation.rst | 2 ++ > >>>>>> 1 file changed, 2 insertions(+) > >>>>>> > >>>>>> diff --git a/doc/guides/rel_notes/deprecation.rst > >>>>>> b/doc/guides/rel_notes/deprecation.rst > >>>>>> index afb599a..58826a8 100644 > >>>>>> --- a/doc/guides/rel_notes/deprecation.rst > >>>>>> +++ b/doc/guides/rel_notes/deprecation.rst > >>>>>> @@ -195,3 +195,5 @@ Deprecation Notices > >>>>>> communicate events such as soft expiry with IPsec in > >>>>>> lookaside mode. > >>>>>> * rib: The ``rib`` library will be promoted from > >>>>>> experimental to stable. + > >>>>>> +* fib: The ``fib`` library will be promoted from experimental > >>>>>> to stable. > >>>> > >>> > >> > > >
Re: [dpdk-dev] Duplicating traffic with RTE Flow
Hello Asaf, it is a while we were in touch regarding this topic. Finally, I am again trying to get work this feature. I've seen that sampling is already upstreamed which is great. However, I am not very successful with that. There is nearly no documentation, just [1], I found no examples, just commit logs... I tried: > set sample_actions 0 port_id id 1 / end > flow validate 0 ingress pattern end actions sample ratio 1 index 0 / drop / > end port_flow_complain(): Caught PMD error type 1 (cause unspecified): port id action is valid in transfer mode only: Operation not supported > flow validate 0 ingress transfer pattern end actions sample ratio 1 index 0 > / drop / end port_flow_complain(): Caught PMD error type 1 (cause unspecified): (no stated reason): Operation not supported Using CentOS 7, DPDK 20.11.0, OFED-5.2-1.0.4. NICs: MT2892 Family [ConnectX-6 Dx] 101d (fw 22.28.1002), MT27800 Family [ConnectX-5] 1017 (fw 16.27.2008). My primary goal is to be able to deliver exactly the same packets both to DPDK and to the Linux kernel. Doing this at RTE Flow level would be great due to performance and transparency. Jan [1] https://doc.dpdk.org/guides/prog_guide/rte_flow.html#action-sample On Fri, 18 Sep 2020 14:23:42 + Asaf Penso wrote: > Hello Jan, > > You can have a look in series [1] where we propose to add APIs to DPDK20.11 > for both mirroring and sampling for packets, with additional actions of the > different traffic. > > [1] > http://patches.dpdk.org/project/dpdk/list/?series=12045 > > Regards, > Asaf Penso > > >-Original Message- > >From: dev On Behalf Of Jan Viktorin > >Sent: Friday, September 18, 2020 3:56 PM > >To: dev@dpdk.org > >Subject: [dpdk-dev] Duplicating traffic with RTE Flow > > > >Hello all, > > > >we are looking for a way to duplicate ingress traffic in hardware. > > > >There is an example in [1] suggesting to insert two fate actions into the > >RTE Flow > >actions array like: > > > > flow create 0 ingress pattern end \ > > actions queue index 0 / void / queue index 1 / end > > > >But our experience is that PMDs reject two fate actions (tried with mlx5). > >Another > >similar approach would be to deliver every single packet into two virtual > >functions: > > > > flow create 0 ingress pattern end \ > > actions vf index 0 / vf index 1 / end > > > >Third possibility was to use passthru: > > > > flow create 0 ingress pattern end \ > > actions passthru / vf index 0 / end > > flow create 0 ingress pattern end \ > > actions vf index 1 / end > > > >Again, tried on mlx5 and it does not support the passthru. > > > >Last idea was to use isolate with passthru (to deliver both to DPDK > >application > >and to the kernel) but again there was no support on mlx5 for passthru... > > > > flow isolate 0 true > > flow create 0 ingress pattern end actions passthru / rss end / end > > > >Is there any other possibility or PMD+NIC that is known to solve such issue? > > > >Thanks > >Jan Viktorin > > > >[1] > >https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoc.dpdk > >.org%2Fguides%2Fprog_guide%2Frte_flow.html%23table-rte-flow-redirect- > >queue-5- > >3&data=02%7C01%7Casafp%40nvidia.com%7C1a46005bec5245e729e708d > >85bd24caf%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C6373603060 > >73519816&sdata=EOF%2Fz62crvBZK8rwzwKIWxj5cVlfPVnU3FLmcL9X2w0%3 > >D&reserved=0
Re: [dpdk-dev] Duplicating traffic with RTE Flow
On Mon, 1 Mar 2021 14:34:07 + Slava Ovsiienko wrote: > Hi, Jan > > To use port action (I see it is in your sample action list) the flow should > be applied to the FDB domain, > ie "transfer" attribute should be specified: > > flow validate 0 ingress transfer... As you can see (however, it's a bit messy in the response below, in [1], it is better), I tried both. First without transfer and second with. The first gives hint "action is valid in transfer mode only" but the second try with transfer gives "Operation not supported". Jan [1] http://mails.dpdk.org/archives/dev/2021-March/200475.html > > With best regards, Slava > > > -Original Message- > > From: Jan Viktorin > > Sent: Monday, March 1, 2021 14:21 > > To: Asaf Penso > > Cc: dev@dpdk.org; Ori Kam ; Jiawei(Jonny) Wang > > ; Slava Ovsiienko > > Subject: Re: [dpdk-dev] Duplicating traffic with RTE Flow > > > > Hello Asaf, > > > > it is a while we were in touch regarding this topic. Finally, I am again > > trying to > > get work this feature. I've seen that sampling is already upstreamed which > > is > > great. However, I am not very successful with that. There is nearly no > > documentation, just [1], I found no examples, just commit logs... > > > > I tried: > > > > > set sample_actions 0 port_id id 1 / end > flow validate 0 ingress > > pattern > > end actions sample ratio 1 index 0 / drop / end > > port_flow_complain(): Caught PMD error type 1 (cause unspecified): port id > > action is valid in transfer mode only: Operation not supported > flow > > validate > > 0 ingress transfer pattern end actions sample ratio 1 index 0 / drop / end > > port_flow_complain(): Caught PMD error type 1 (cause unspecified): (no > > stated reason): Operation not supported > > > > Using CentOS 7, DPDK 20.11.0, OFED-5.2-1.0.4. > > NICs: MT2892 Family [ConnectX-6 Dx] 101d (fw 22.28.1002), MT27800 Family > > [ConnectX-5] 1017 (fw 16.27.2008). > > > > My primary goal is to be able to deliver exactly the same packets both to > > DPDK and to the Linux kernel. Doing this at RTE Flow level would be great > > due > > to performance and transparency. > > > > Jan > > > > [1] https://doc.dpdk.org/guides/prog_guide/rte_flow.html#action-sample > > > > On Fri, 18 Sep 2020 14:23:42 + > > Asaf Penso wrote: > > > > > Hello Jan, > > > > > > You can have a look in series [1] where we propose to add APIs to > > DPDK20.11 for both mirroring and sampling for packets, with additional > > actions of the different traffic. > > > > > > [1] > > > http://patches.dpdk.org/project/dpdk/list/?series=12045 > > > > > > Regards, > > > Asaf Penso > > > > > > >-Original Message- > > > >From: dev On Behalf Of Jan Viktorin > > > >Sent: Friday, September 18, 2020 3:56 PM > > > >To: dev@dpdk.org > > > >Subject: [dpdk-dev] Duplicating traffic with RTE Flow > > > > > > > >Hello all, > > > > > > > >we are looking for a way to duplicate ingress traffic in hardware. > > > > > > > >There is an example in [1] suggesting to insert two fate actions into > > > >the RTE Flow actions array like: > > > > > > > > flow create 0 ingress pattern end \ > > > > actions queue index 0 / void / queue index 1 / end > > > > > > > >But our experience is that PMDs reject two fate actions (tried with > > > >mlx5). Another similar approach would be to deliver every single > > > >packet into two virtual > > > >functions: > > > > > > > > flow create 0 ingress pattern end \ > > > > actions vf index 0 / vf index 1 / end > > > > > > > >Third possibility was to use passthru: > > > > > > > > flow create 0 ingress pattern end \ > > > > actions passthru / vf index 0 / end flow create 0 ingress > > > > pattern end \ > > > > actions vf index 1 / end > > > > > > > >Again, tried on mlx5 and it does not support the passthru. > > > > > > > >Last idea was to use isolate with passthru (to deliver both to DPDK > > > >application and to the kernel) but again there was no support on mlx5 > > > >for > > passthru... > > > > > > > > flow isolate 0 true > > > > flow create 0 ingress pattern end actions passthru / rss end / end > > > > > > > >Is there any other possibility or PMD+NIC that is known to solve such > > issue? > > > > > > > >Thanks > > > >Jan Viktorin > > > > > > > >[1] > > > >https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoc > > > >.dpdk > > > >.org%2Fguides%2Fprog_guide%2Frte_flow.html%23table-rte-flow-redirect- > > > >queue-5- > > > > > >3&data=02%7C01%7Casafp%40nvidia.com%7C1a46005bec5245e729e70 > > 8d > > > > > >85bd24caf%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C63736030 > > 60 > > > > > >73519816&sdata=EOF%2Fz62crvBZK8rwzwKIWxj5cVlfPVnU3FLmcL9X2w0 > > %3 > > > >D&reserved=0 >
Re: [PATCH 4/4] doc: note that testpmd on mlx5 has dedicated queues problem
Hello all, Mario (CC) will look at this. H. On Tue, 07 Mar 2023 10:00:35 +0100 Havlík Martin wrote: > Hi Slava, > > as I no longer work on the DPDK centered project which led me to > encounter said issue, I am no longer in touch with changes made to > net/bonding and moreover I don't have access to resources to test the > current state of things. > > But that aside, the linked commit seems to fix the issue (again, > cannot test it myself but I'll trust the time passed since the commit > without further changes). > > If archiving is what is done to obsolete patches, then yes, go ahead, > please. > > Wish you all the best, > Martin > > Dne 2023-03-06 16:21, Slava Ovsiienko napsal: > > Hi, Martin > > > > Is this issue resolved by: > > http://git.dpdk.org/dpdk/commit/?id=f66323717e ? > > > > Should we archive the patch? > > > > With best regards, > > Slava > > > > > > > >> -Original Message- > >> From: Martin Havlik > >> Sent: среда, 21 июля 2021 г. 18:59 > >> To: xhavl...@stud.fit.vutbr.cz; Xiaoyun Li ; > >> Ferruh Yigit > >> ; Andrew Rybchenko > >> ; > >> Ajit Khaparde ; Haiyue Wang > >> ; Ori Kam ; Haifei Luo > >> ; Slava Ovsiienko ; > >> Andrey Vesnovaty ; Bing Zhao > >> ; Jiawei(Jonny) Wang ; > >> Gregory Etelson ; Li Zhang > >> Cc: dev@dpdk.org; Jan Viktorin > >> Subject: [PATCH 4/4] doc: note that testpmd on mlx5 has dedicated > >> queues > >> problem > >> > >> In bonding mode 4 (8023ad), dedicated queues are not working on > >> mlx5 NICs. > >> > >> Signed-off-by: Martin Havlik > >> --- > >> doc/guides/testpmd_app_ug/testpmd_funcs.rst | 3 +++ > >> 1 file changed, 3 insertions(+) > >> > >> diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst > >> b/doc/guides/testpmd_app_ug/testpmd_funcs.rst > >> index 2c43719ad3..8a6edc2bad 100644 > >> --- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst > >> +++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst > >> @@ -2603,6 +2603,9 @@ when in mode 4 (link-aggregation-802.3ad):: > >> > >> testpmd> set bonding lacp dedicated_queues (port_id) > >> (enable|disable) > >> > >> +.. note:: > >> + Dedicated queues `do not currently work > >> + <https://bugs.dpdk.org/show_bug.cgi?id=759>`__ on mlx5 NICs. > >> > >> set bonding agg_mode > >> > >> -- > >> 2.27.0
Re: [dpdk-dev][PATCH] ethdev: add send queue flow matching item
Hi all,
I'd like to test this feature somehow but this patch just implements the API...
Will there
be some PMD support soon? I could see that mlx5 implements some internal hidden
RTE Flow
item SC already that matches this behaviour... It would be great to make it
available
via this TX_QUEUE feature. Any plans for this (Ori)?
Jan
On Thu, 20 Apr 2023 10:59:01 +0530
wrote:
> From: Kiran Kumar K
>
> Adding support for send queue flow matching item.
> This item is valid only for egress rules.
> An example use case would be that application can
> set different vlan insert rules with different PCP values
> based on tx queue number.
>
> Signed-off-by: Kiran Kumar K
> ---
> app/test-pmd/cmdline_flow.c | 28 +++
> doc/guides/prog_guide/rte_flow.rst | 7 +
> doc/guides/rel_notes/release_23_07.rst | 31 ++---
> doc/guides/testpmd_app_ug/testpmd_funcs.rst | 4 +++
> lib/ethdev/rte_flow.c | 1 +
> lib/ethdev/rte_flow.h | 26 +
> 6 files changed, 68 insertions(+), 29 deletions(-)
>
> diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
> index 58939ec321..a68a6080a8 100644
> --- a/app/test-pmd/cmdline_flow.c
> +++ b/app/test-pmd/cmdline_flow.c
> @@ -496,6 +496,8 @@ enum index {
> ITEM_QUOTA_STATE_NAME,
> ITEM_AGGR_AFFINITY,
> ITEM_AGGR_AFFINITY_VALUE,
> + ITEM_TX_QUEUE,
> + ITEM_TX_QUEUE_VALUE,
>
> /* Validate/create actions. */
> ACTIONS,
> @@ -1452,6 +1454,7 @@ static const enum index next_item[] = {
> ITEM_METER,
> ITEM_QUOTA,
> ITEM_AGGR_AFFINITY,
> + ITEM_TX_QUEUE,
> END_SET,
> ZERO,
> };
> @@ -1953,6 +1956,12 @@ static const enum index item_aggr_affinity[] = {
> ZERO,
> };
>
> +static const enum index item_tx_queue[] = {
> + ITEM_TX_QUEUE_VALUE,
> + ITEM_NEXT,
> + ZERO,
> +};
> +
> static const enum index next_action[] = {
> ACTION_END,
> ACTION_VOID,
> @@ -6945,6 +6954,22 @@ static const struct token token_list[] = {
> .args = ARGS(ARGS_ENTRY(struct rte_flow_item_aggr_affinity,
> affinity)),
> },
> + [ITEM_TX_QUEUE] = {
> + .name = "tx_queue",
> + .help = "match on the tx queue of send packet",
> + .priv = PRIV_ITEM(TX_QUEUE,
> + sizeof(struct rte_flow_item_tx_queue)),
> + .next = NEXT(item_tx_queue),
> + .call = parse_vc,
> + },
> + [ITEM_TX_QUEUE_VALUE] = {
> + .name = "tx_queue_value",
> + .help = "tx queue value",
> + .next = NEXT(item_tx_queue, NEXT_ENTRY(COMMON_UNSIGNED),
> + item_param),
> + .args = ARGS(ARGS_ENTRY(struct rte_flow_item_tx_queue,
> + tx_queue)),
> + },
> };
>
> /** Remove and return last entry from argument stack. */
> @@ -11849,6 +11874,9 @@ flow_item_default_mask(const struct rte_flow_item
> *item)
> case RTE_FLOW_ITEM_TYPE_AGGR_AFFINITY:
> mask = &rte_flow_item_aggr_affinity_mask;
> break;
> + case RTE_FLOW_ITEM_TYPE_TX_QUEUE:
> + mask = &rte_flow_item_tx_queue_mask;
> + break;
> default:
> break;
> }
> diff --git a/doc/guides/prog_guide/rte_flow.rst
> b/doc/guides/prog_guide/rte_flow.rst
> index 32fc45516a..7154b56330 100644
> --- a/doc/guides/prog_guide/rte_flow.rst
> +++ b/doc/guides/prog_guide/rte_flow.rst
> @@ -1486,6 +1486,13 @@ This item is meant to use the same structure as `Item:
> PORT_REPRESENTOR`_.
>
> See also `Action: REPRESENTED_PORT`_.
>
> +Item: ``TX_QUEUE``
> +^^^
> +
> +Matches on the tx queue of send packet .
> +
> +- ``tx_queue``: Tx queue.
> +
> Item: ``AGGR_AFFINITY``
> ^^^
>
> diff --git a/doc/guides/rel_notes/release_23_07.rst
> b/doc/guides/rel_notes/release_23_07.rst
> index a9b1293689..631cbd2b58 100644
> --- a/doc/guides/rel_notes/release_23_07.rst
> +++ b/doc/guides/rel_notes/release_23_07.rst
> @@ -24,36 +24,9 @@ DPDK Release 23.07
> New Features
>
>
> -.. This section should contain new features added in this release.
> - Sample format:
> +* **Added flow matching of tx queue.**
>
> - * **Add a title in the past tense with a full stop.**
> -
> - Add a short 1-2 sentence description in the past tense.
> - The description should be enough to allow someone scanning
> - the release notes to understand the new feature.
> -
> - If the feature adds a lot of sub-features you can use a bullet list
> - like this:
> -
> - * Added feature foo to do something.
> - * Enhanced feature bar to do something else.
> -
> - Refer to the previous release notes for examples.
> -
> - Suggested order in release notes items:
> - * Core libs (EAL,
Re: [PATCH] MAINTAINERS: drop email address for Jan Viktorin
On Wed, 31 Aug 2022 22:25:24 +0200 Thomas Monjalon wrote: > 31/08/2022 21:30, Stephen Hemminger: > > Going over list of active DPDK developers and MAINTAINERS > > and noticed that Jan's email was not active. His response was: > > > >well, that rehivetech.com address is probably receiving but it's not > >under my control for quite some time. Anyway, I can see that there is > >Ruifeng Wang listed now as a maintainer. I would prefer to remove my > >address from the maintainers entirely. > > > >Jan The vikto...@rehivetech.com is no longer under my control. As there is already another maintainer (Ruifeng Wang), I would prefer and suggest to remove my address from the maintainers entirely. > > Jan, do you want to keep this message verbatim in the git history? > You can suggest a rewording here. > > Thanks Jan
Re: [dpdk-dev] [PATCH 3/3] net/bonding: start ethdev prior to setting 8023ad flow
On Tue, 24 Aug 2021 14:18:16 +0100 Ferruh Yigit wrote: > On 7/15/2021 2:58 PM, Thomas Monjalon wrote: > > 14/07/2021 17:00, Jan Viktorin: > >>>> On Tue, 13 Jul 2021 12:26:35 +0300 > >>>> Andrew Rybchenko wrote: > >>>>>>>>>> This matters for the bonding case as well, doesn't it?. > >>>>>>>>>> It is not desirable to accidently omit a packet that was > >>>>>>>>>> received by primary ingress logic instead of being > >>>>>>>>>> redirected into the dedicated queue. > >>>>>>>>>> > >>>>>>>>>> Are there any chances that for mlx5 it would be possible > >>>>>>>>>> to insert flow rules before calling rte_eth_dev_start? > >>>>>>>>>> Anyway, the behaviour should be specified and documented > >>>>>>>>>> in DPDK more precisely to avoid such uncertainty in the > >>>>>>>>>> future. > >>>>>>>>> I agree the documentation should be fixed. > >>>>>>>> > >>>>>>>> +1 > >>>>> > >>>>> Cc Thomas and Ferruh since ethdev documentation should be > >>>>> clarified. > >>>>> > >>>>> It looks like there is no consensus if the patch is a right > >>>>> direction or wrong. For me it looks wrong taking all above > >>>>> arguments in to account (mainly necessity to be able to insert > >>>>> flows before pushing start button which enables the traffic if > >>>>> HW supports it). > >>>>> > >>>>> So, I'm applying first two patches and hold on this one. > >> > >> Andrew, I believe that it would be helpful to start some new thread > >> otherwise we would get lost here :). It seems that we will have few > >> more fixes for the bonding driver. Do you prefer an entirely new > >> patchset or v2 of this topic? Or any other advise how to proceed? > > > > This thread is about 3 things: > > - bonding issue > > - ethdev doc > > - mlx5 design > > That's too much topics to address in one thread :) > > > > You may restart the discussion with a doc update > > if the stop/start requirement is not clear. > > > > > > Is separate discussions created as follow up? > Martin is recently unavailable. But he has already started a new thread for _ethdev doc_ topic: [PATCH 0/4] doc: update RTE flow rule and bonding related info https://www.mail-archive.com/dev@dpdk.org/msg214517.html to first clarify/document what is the current status and how to proceed. Jan
Re: [dpdk-dev] Duplicating traffic with RTE Flow
On Thu, 11 Mar 2021 02:11:07 + "Jiawei(Jonny) Wang" wrote: > Hi Jan, > > Sorry for late response, > > First rule is invalid, port only works on FDB domain so need 'transfer' here; > Second rule should be ok, could you please check if the port 1 was enabled > on you dpdk application? I assume that it is enabled, see full transcript: $ ofed_info MLNX_OFED_LINUX-5.2-1.0.4.0 (OFED-5.2-1.0.4): ... $ sudo dpdk-testpmd -v -- -i EAL: Detected 24 lcore(s) EAL: Detected 1 NUMA nodes EAL: RTE Version: 'DPDK 20.11.0' EAL: Multi-process socket /var/run/dpdk/rte/mp_socket EAL: Selected IOVA mode 'PA' EAL: No available hugepages reported in hugepages-1048576kB EAL: Probing VFIO support... EAL: Probe PCI driver: mlx5_pci (15b3:1017) device: :04:00.0 (socket 0) mlx5_pci: No available register for Sampler. mlx5_pci: Size 0x is not power of 2, will be aligned to 0x1. EAL: Probe PCI driver: mlx5_pci (15b3:1017) device: :04:00.1 (socket 0) mlx5_pci: No available register for Sampler. mlx5_pci: Size 0x is not power of 2, will be aligned to 0x1. EAL: No legacy callbacks, legacy socket not created Interactive-mode selected testpmd: create a new mbuf pool : n=331456, size=2176, socket=0 testpmd: preferred mempool ops selected: ring_mp_mc Configuring Port 0 (socket 0) Port 0: B8:59:9F:E2:09:F6 Configuring Port 1 (socket 0) Port 1: B8:59:9F:E2:09:F7 Checking link statuses... Done testpmd> port start 1 Port 1 is now not stopped Please stop the ports first Done testpmd> set sample_actions 0 port_id id 1 / end testpmd> flow validate 0 ingress transfer pattern end actions sample ratio 1 index 0 / drop / end port_flow_complain(): Caught PMD error type 1 (cause unspecified): (no stated reason): Operation not supported testpmd> flow create 0 ingress transfer pattern end actions sample ratio 1 index 0 / drop / end port_flow_complain(): Caught PMD error type 1 (cause unspecified): (no stated reason): Operation not supported testpmd> Stopping port 0... Stopping ports... Done Stopping port 1... Stopping ports... Done Shutting down port 0... Closing ports... Port 0 is closed Done Shutting down port 1... Closing ports... Port 1 is closed Done Bye... Jan > > Thanks. > Jonny > > > -Original Message- > > From: Jan Viktorin > > Sent: Monday, March 1, 2021 10:43 PM > > To: Slava Ovsiienko > > Cc: Asaf Penso ; dev@dpdk.org; Ori Kam > > ; Jiawei(Jonny) Wang > > Subject: Re: [dpdk-dev] Duplicating traffic with RTE Flow > > > > On Mon, 1 Mar 2021 14:34:07 + > > Slava Ovsiienko wrote: > > > > > Hi, Jan > > > > > > To use port action (I see it is in your sample action list) the flow > > > should be applied to the FDB domain, ie "transfer" attribute should be > > specified: > > > > > > flow validate 0 ingress transfer... > > > > As you can see (however, it's a bit messy in the response below, in [1], it > > is > > better), I tried both. First without transfer and second with. The first > > gives > > hint "action is valid in transfer mode only" but the second try with > > transfer > > gives "Operation not supported". > > > > Jan > > > > [1] http://mails.dpdk.org/archives/dev/2021-March/200475.html > > > > > > > > With best regards, Slava > > > > > > > -Original Message- > > > > From: Jan Viktorin > > > > Sent: Monday, March 1, 2021 14:21 > > > > To: Asaf Penso > > > > Cc: dev@dpdk.org; Ori Kam ; Jiawei(Jonny) Wang > > > > ; Slava Ovsiienko > > > > Subject: Re: [dpdk-dev] Duplicating traffic with RTE Flow > > > > > > > > Hello Asaf, > > > > > > > > it is a while we were in touch regarding this topic. Finally, I am > > > > again trying to get work this feature. I've seen that sampling is > > > > already upstreamed which is great. However, I am not very successful > > > > with that. There is nearly no documentation, just [1], I found no > > > > examples, > > just commit logs... > > > > > > > > I tried: > > > > > > > > > set sample_actions 0 port_id id 1 / end > flow validate 0 > > > > ingress pattern end actions sample ratio 1 index 0 / drop / end > > > > port_flow_complain(): Caught PMD error type 1 (cause unspecified): > > > > port id action is valid in transfer mode only: Operation not > > > > supported > flow validate > > > > 0 ingress transfer p
Re: [dpdk-dev] Duplicating traffic with RTE Flow
Hello Jiawei, On Fri, 12 Mar 2021 09:32:44 + "Jiawei(Jonny) Wang" wrote: > Hi Jan, > > > -Original Message- > > From: Jan Viktorin > > Sent: Friday, March 12, 2021 12:33 AM > > To: Jiawei(Jonny) Wang > > Cc: Slava Ovsiienko ; Asaf Penso > > ; dev@dpdk.org; Ori Kam > > Subject: Re: [dpdk-dev] Duplicating traffic with RTE Flow > > > > On Thu, 11 Mar 2021 02:11:07 + > > "Jiawei(Jonny) Wang" wrote: > > > > > Hi Jan, > > > > > > Sorry for late response, > > > > > > First rule is invalid, port only works on FDB domain so need > > > 'transfer' here; Second rule should be ok, could you please check if the > > > > > port 1 was enabled on you dpdk application? > > > > I assume that it is enabled, see full transcript: > > > > $ ofed_info > > MLNX_OFED_LINUX-5.2-1.0.4.0 (OFED-5.2-1.0.4): > > ... > > $ sudo dpdk-testpmd -v -- -i > > EAL: Detected 24 lcore(s) > > EAL: Detected 1 NUMA nodes > > EAL: RTE Version: 'DPDK 20.11.0' > > EAL: Multi-process socket /var/run/dpdk/rte/mp_socket > > EAL: Selected IOVA mode 'PA' > > EAL: No available hugepages reported in hugepages-1048576kB > > EAL: Probing VFIO support... > > EAL: Probe PCI driver: mlx5_pci (15b3:1017) device: :04:00.0 (socket 0) > > mlx5_pci: No available register for Sampler. > > mlx5_pci: Size 0x is not power of 2, will be aligned to 0x1. > > EAL: Probe PCI driver: mlx5_pci (15b3:1017) device: :04:00.1 (socket 0) > > mlx5_pci: No available register for Sampler. > > mlx5_pci: Size 0x is not power of 2, will be aligned to 0x1. > > EAL: No legacy callbacks, legacy socket not created Interactive-mode > > selected > > testpmd: create a new mbuf pool : n=331456, size=2176, > > socket=0 > > testpmd: preferred mempool ops selected: ring_mp_mc Configuring Port 0 > > (socket 0) Port 0: B8:59:9F:E2:09:F6 Configuring Port 1 (socket 0) Port > > 1: > > B8:59:9F:E2:09:F7 Checking link statuses... > > Done > > Seems that you start two PF port here, Port 1 is not VF port; > FDB rule can steering the packet form PF to its VFs and vice versa, Could you > please try to open the > VF ports and start the testpmd with representor=. I did not know this, so I tried with VFs: # echo 2 > /sys/class/net/hge1/device/sriov_numvfs # echo switchdev > /sys/class/net/hge1/compat/devlink/mode # dpdk-testpmd -v -a ':05:00.1,representor=[0-1]' -- -i EAL: Detected 24 lcore(s) EAL: Detected 1 NUMA nodes EAL: RTE Version: 'DPDK 20.11.0' EAL: Multi-process socket /var/run/dpdk/rte/mp_socket EAL: Selected IOVA mode 'VA' EAL: No available hugepages reported in hugepages-1048576kB EAL: Probing VFIO support... EAL: Probe PCI driver: mlx5_pci (15b3:1017) device: :05:00.1 (socket 0) mlx5_pci: No available register for Sampler. mlx5_pci: Size 0x is not power of 2, will be aligned to 0x1. mlx5_pci: No available register for Sampler. mlx5_pci: No available register for Sampler. EAL: No legacy callbacks, legacy socket not created Interactive-mode selected testpmd: create a new mbuf pool : n=331456, size=2176, socket=0 testpmd: preferred mempool ops selected: ring_mp_mc Warning! port-topology=paired and odd forward ports number, the last port will pair with itself. Configuring Port 0 (socket 0) Port 0: B8:59:9F:E2:09:F7 Configuring Port 1 (socket 0) Port 1: B2:57:D6:72:F3:31 Configuring Port 2 (socket 0) Port 2: 9E:CB:D0:73:59:CE Checking link statuses... Done testpmd> show port summary all Number of available ports: 3 Port MAC Address Name Driver Status Link 0B8:59:9F:E2:09:F7 :05:00.1 mlx5_pci up 100 Gbps 1B2:57:D6:72:F3:31 :05:00.1_representor_0 mlx5_pci up 100 Gbps 29E:CB:D0:73:59:CE :05:00.1_representor_1 mlx5_pci up 100 Gbps testpmd> set sample_actions 0 port_id id 1 / end testpmd> flow validate 0 ingress transfer pattern end actions sample ratio 1 index 0 / drop / end port_flow_complain(): Caught PMD error type 1 (cause unspecified): sample action not supported: Operation not supported Still no luck. However, there is this message 3-times in the log: mlx5_pci: No available register for Sampler. It looks like it might be related. What does it mean? Jan > > Thanks. > > > testpmd> port start 1 > > Port 1 is now not stopped > > Please stop the ports first > > Done > > testpmd> set sample_actions 0 port_id id 1 / end testpmd> flow validate 0 > > > > ingress transfer
Re: [dpdk-dev] [PATCH 2/2] net/mlx5: avoid unbind step to enable switchdev mode
Hello Salva, On Mon, 15 Mar 2021 15:53:51 + Slava Ovsiienko wrote: > Hi, Jan > > Yes, bullet [4] explicitly requires to unbind VFs, and detach the netdevs > from the mlx5_core driver. > Otherwise, kernel driver refuses to be configured with switchdev mode in [5]. > So, [4] can't be skipped. > After setting swithdev mode, VFs can be bound back (if it is needed, and > these ones are not mapped to VMs): OK, but I believe that it is **not possible** to follow the rule [5]. The guide explicitly says in [4] "can be rebind **after** the switchdev mode". Just, if you unbind the device, there is no way how to configure the switchdev mode, this is the contradiction I mentioned in the commit. You cannot configure switchdev mode because the interface is gone and the path /sys/class/net//compat/devlink/mode no longer exists. So, maybe, just the formulation is wrong. So, what is the **exact right** way how to do it? I would change the commit accordingly. Just, let's make it right. Would it work this way? # echo -n "" > /sys/bus/pci/drivers/mlx5_core/unbind # echo -n "" > /sys/bus/pci/drivers/mlx5_core/bind # echo switchdev > /sys/class/net//compat/devlink/mode It is good to mention that after the rebind, the can change. Regards, Jan > > echo -n "" > > /sys/bus/pci/drivers/mlx5_core/bind > > With best regards, > Slava > > > -Original Message- > > From: Jan Viktorin > > Sent: Monday, March 15, 2021 17:34 > > To: dev@dpdk.org > > Cc: Jan Viktorin ; Asaf Penso ; > > Shahaf Shuler ; Slava Ovsiienko > > ; Matan Azrad > > Subject: [PATCH 2/2] net/mlx5: avoid unbind step to enable switchdev mode > > > > From: Jan Viktorin > > > > The step 4 is a contradiction. It advices to unbind the device from the > > mlx5_core which removes the associated system network interface (e.g. > > eth0). In the step 5, the same system network interface (e.g. eth0) is > > required to exist. > > > > Signed-off-by: Jan Viktorin > > --- > > doc/guides/nics/mlx5.rst | 6 +- > > 1 file changed, 1 insertion(+), 5 deletions(-) > > > > diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst index > > 0a2dc3dee..122d8e0fc 100644 > > --- a/doc/guides/nics/mlx5.rst > > +++ b/doc/guides/nics/mlx5.rst > > @@ -1370,11 +1370,7 @@ the DPDK application. > > > > echo /sys/class/net//device/sriov_numvfs > > > > -4. Unbind the device (can be rebind after the switchdev mode):: > > - > > -echo -n "" > > > /sys/bus/pci/drivers/mlx5_core/unbind > > - > > -5. Enable switchdev mode:: > > +4. Enable switchdev mode:: > > > > echo switchdev > /sys/class/net//compat/devlink/mode > > > > -- > > 2.30.1 >
[dpdk-dev] [PATCH 1/2] net/mlx5: fix typos
From: Jan Viktorin Signed-off-by: Jan Viktorin --- doc/guides/nics/mlx5.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst index 7c50497fb..0a2dc3dee 100644 --- a/doc/guides/nics/mlx5.rst +++ b/doc/guides/nics/mlx5.rst @@ -1372,9 +1372,9 @@ the DPDK application. 4. Unbind the device (can be rebind after the switchdev mode):: -echo -n " /sys/bus/pci/drivers/mlx5_core/unbind +echo -n "" > /sys/bus/pci/drivers/mlx5_core/unbind -5. Enbale switchdev mode:: +5. Enable switchdev mode:: echo switchdev > /sys/class/net//compat/devlink/mode -- 2.30.1
[dpdk-dev] [PATCH 2/2] net/mlx5: avoid unbind step to enable switchdev mode
From: Jan Viktorin The step 4 is a contradiction. It advices to unbind the device from the mlx5_core which removes the associated system network interface (e.g. eth0). In the step 5, the same system network interface (e.g. eth0) is required to exist. Signed-off-by: Jan Viktorin --- doc/guides/nics/mlx5.rst | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst index 0a2dc3dee..122d8e0fc 100644 --- a/doc/guides/nics/mlx5.rst +++ b/doc/guides/nics/mlx5.rst @@ -1370,11 +1370,7 @@ the DPDK application. echo /sys/class/net//device/sriov_numvfs -4. Unbind the device (can be rebind after the switchdev mode):: - -echo -n "" > /sys/bus/pci/drivers/mlx5_core/unbind - -5. Enable switchdev mode:: +4. Enable switchdev mode:: echo switchdev > /sys/class/net//compat/devlink/mode -- 2.30.1
Re: [dpdk-dev] Duplicating traffic with RTE Flow
OK, after firmware update, it seems that it works now. Thank you for help! Jan On Mon, 15 Mar 2021 14:22:16 +0100 Jan Viktorin wrote: > Hello Jiawei, > > On Fri, 12 Mar 2021 09:32:44 + > "Jiawei(Jonny) Wang" wrote: > > > Hi Jan, > > > > > -Original Message- > > > From: Jan Viktorin > > > Sent: Friday, March 12, 2021 12:33 AM > > > To: Jiawei(Jonny) Wang > > > Cc: Slava Ovsiienko ; Asaf Penso > > > ; dev@dpdk.org; Ori Kam > > > Subject: Re: [dpdk-dev] Duplicating traffic with RTE Flow > > > > > > On Thu, 11 Mar 2021 02:11:07 + > > > "Jiawei(Jonny) Wang" wrote: > > > > > > > Hi Jan, > > > > > > > > Sorry for late response, > > > > > > > > First rule is invalid, port only works on FDB domain so need > > > > 'transfer' here; Second rule should be ok, could you please check if > > > > the > > > port 1 was enabled on you dpdk application? > > > > > > I assume that it is enabled, see full transcript: > > > > > > $ ofed_info > > > MLNX_OFED_LINUX-5.2-1.0.4.0 (OFED-5.2-1.0.4): > > > ... > > > $ sudo dpdk-testpmd -v -- -i > > > EAL: Detected 24 lcore(s) > > > EAL: Detected 1 NUMA nodes > > > EAL: RTE Version: 'DPDK 20.11.0' > > > EAL: Multi-process socket /var/run/dpdk/rte/mp_socket > > > EAL: Selected IOVA mode 'PA' > > > EAL: No available hugepages reported in hugepages-1048576kB > > > EAL: Probing VFIO support... > > > EAL: Probe PCI driver: mlx5_pci (15b3:1017) device: :04:00.0 (socket > > > 0) > > > mlx5_pci: No available register for Sampler. > > > mlx5_pci: Size 0x is not power of 2, will be aligned to 0x1. > > > EAL: Probe PCI driver: mlx5_pci (15b3:1017) device: :04:00.1 (socket > > > 0) > > > mlx5_pci: No available register for Sampler. > > > mlx5_pci: Size 0x is not power of 2, will be aligned to 0x1. > > > EAL: No legacy callbacks, legacy socket not created Interactive-mode > > > selected > > > testpmd: create a new mbuf pool : n=331456, size=2176, > > > socket=0 > > > testpmd: preferred mempool ops selected: ring_mp_mc Configuring Port 0 > > > (socket 0) Port 0: B8:59:9F:E2:09:F6 Configuring Port 1 (socket 0) > > > Port 1: > > > B8:59:9F:E2:09:F7 Checking link statuses... > > > Done > > > > Seems that you start two PF port here, Port 1 is not VF port; > > FDB rule can steering the packet form PF to its VFs and vice versa, Could > > you please try to open the > > VF ports and start the testpmd with representor=. > > I did not know this, so I tried with VFs: > > # echo 2 > /sys/class/net/hge1/device/sriov_numvfs > # echo switchdev > /sys/class/net/hge1/compat/devlink/mode > > # dpdk-testpmd -v -a ':05:00.1,representor=[0-1]' -- -i > EAL: Detected 24 lcore(s) > EAL: Detected 1 NUMA nodes > EAL: RTE Version: 'DPDK 20.11.0' > EAL: Multi-process socket /var/run/dpdk/rte/mp_socket > EAL: Selected IOVA mode 'VA' > EAL: No available hugepages reported in hugepages-1048576kB > EAL: Probing VFIO support... > EAL: Probe PCI driver: mlx5_pci (15b3:1017) device: :05:00.1 (socket 0) > mlx5_pci: No available register for Sampler. > mlx5_pci: Size 0x is not power of 2, will be aligned to 0x1. > mlx5_pci: No available register for Sampler. > mlx5_pci: No available register for Sampler. > EAL: No legacy callbacks, legacy socket not created > Interactive-mode selected > testpmd: create a new mbuf pool : n=331456, size=2176, socket=0 > testpmd: preferred mempool ops selected: ring_mp_mc > > Warning! port-topology=paired and odd forward ports number, the last port > will pair with itself. > > Configuring Port 0 (socket 0) > Port 0: B8:59:9F:E2:09:F7 > Configuring Port 1 (socket 0) > Port 1: B2:57:D6:72:F3:31 > Configuring Port 2 (socket 0) > Port 2: 9E:CB:D0:73:59:CE > Checking link statuses... > Done > testpmd> show port summary all > Number of available ports: 3 > Port MAC Address Name Driver Status Link > 0B8:59:9F:E2:09:F7 :05:00.1 mlx5_pci up 100 Gbps > 1B2:57:D6:72:F3:31 :05:00.1_representor_0 mlx5_pci up > 100 Gbps > 29E:CB:D0:73:59:CE :05:00.1_representor_1 mlx5_pci up > 100 Gbps > testpmd> set sample_actions 0 port
Re: [dpdk-dev] [PATCH 2/2] net/mlx5: avoid unbind step to enable switchdev mode
On Mon, 15 Mar 2021 19:31:25 + Slava Ovsiienko wrote: > Hi, Jan Hello Salva, I am sorry, but I didn't get the point of your response. For me, there was 1 PF :05:00.1, SRIOV disabled. So, I followed the guide [1]. 1. Enable SRIOV via mlxconfig. Done. 2. Configure max number of VFs. Done. 3. Reset firmware. Done. In fact, I had to reboot the machine here so I am not convinced the reset of firmware is the thing. But I can image that there is some other use case for it. After reboot, I configured 2 VFs: :05:00.4, :05:00.5. 4. Unbind the PF :05:00.1. Done. 5. Fail, no way how to configure switchdev because of previous step. Thus, I strongly believe that the guide is misleading here. When I bound the PF :05:00.1 back, I could configure the switchdev mode and everything was just OK and seemed to be working. So **after** the bind I configured the switchdev mode properly. [1] https://doc.dpdk.org/guides/nics/mlx5.html#enable-switchdev-mode Jan > > 1. Let's suppose we have the one port NIC, PCI BDF 08:00.0, SR-IOV enabled, 0 > VFs is configured, > netdev name is ens1f0 (depends on distro and kernel version). > > 2. Then, we configure 3 VFs with SR-IOV, we get : > - 08:00.0 - PF, ens1f0 > - 08:00.1 - VF0, ens1f1 > - 08:00.2 - VF1, ens1f2 > - 08:00.3 - VF2, ens1f3 > > 3. Then, we should unbind VFs ONLY, PF should be kept untouched. > - 08:00.0 - PF, ens1f0 > - 08:00.1 - VF0, - > - 08:00.2 - VF1, - > - 08:00.3 - VF2, - > > 4. Then, configure switchdev mode > - 08:00.0 - PF, ens1f0 > - 08:00.1 - VF0, - > - 08:00.2 - VF1, - > - 08:00.3 - VF2, - > + we get 3 representor netdevs: > ens1f0_0 (no dedicated PCI device) > ens1f0_1 (no dedicated PCI device) > ens1f0_2 (no dedicated PCI device) > > 5. Then, bind VFs back (assume we are no going to map them to VMs) > - 08:00.0 - PF, ens1f0 > - 08:00.1 - VF0, ens1f1 > - 08:00.2 - VF1, ens1f2 > - 08:00.3 - VF2, ens1f3 > - ens1f0_0 (no dedicated PCI device) > - ens1f0_1 (no dedicated PCI device) > - ens1f0_2 (no dedicated PCI device) > > 6. As result we should get 7 netdevs - 1 PF (Uplink representor), 3 VFs, 3 > representors (no PCI device, pure netdev) > > With best regards, Slava > > > -Original Message- > > From: Jan Viktorin > > Sent: Monday, March 15, 2021 18:11 > > To: Slava Ovsiienko > > Cc: dev@dpdk.org; Asaf Penso ; Shahaf Shuler > > ; Matan Azrad > > Subject: Re: [PATCH 2/2] net/mlx5: avoid unbind step to enable switchdev > > mode > > > > Hello Salva, > > > > On Mon, 15 Mar 2021 15:53:51 + > > Slava Ovsiienko wrote: > > > > > Hi, Jan > > > > > > Yes, bullet [4] explicitly requires to unbind VFs, and detach the netdevs > > > > > from the mlx5_core driver. > > > Otherwise, kernel driver refuses to be configured with switchdev mode in > > [5]. So, [4] can't be skipped. > > > After setting swithdev mode, VFs can be bound back (if it is needed, and > > these ones are not mapped to VMs): > > > > OK, but I believe that it is **not possible** to follow the rule [5]. > > The guide explicitly says in [4] "can be rebind **after** the switchdev > > mode". > > Just, if you unbind the device, there is no way how to configure the > > switchdev mode, this is the contradiction I mentioned in the commit. You > > cannot configure switchdev mode because the interface is gone and the path > > /sys/class/net//compat/devlink/mode no longer exists. > > > > So, maybe, just the formulation is wrong. So, what is the **exact > > right** way how to do it? I would change the commit accordingly. Just, let's > > make it right. Would it work this way? > > > > # echo -n "" > /sys/bus/pci/drivers/mlx5_core/unbind > > # echo -n "" > /sys/bus/pci/drivers/mlx5_core/bind > > # echo switchdev > /sys/class/net//compat/devlink/mode > > > > It is good to mention that after the rebind, the can change. > > > > Regards, > > Jan > > > > > > > > echo -n "" > > /sys/bus/pci/drivers/mlx5_core/bind > > > > > > With best regards, > > > Slava > > > > > > > -Original Message- > > > > From: Jan Viktorin > > > > Sent: Monday, March 15, 2021 17:34 > > > > To: dev@dpdk.org > > > > Cc: Jan Viktorin ; Asaf Penso > > > > ; Shahaf Shuler ; Slava > > > > Ovsiienko ; Matan Azrad > > > > > > Subject: [PATCH 2/2] net/mlx5: avoid unbind step to enable switchdev > > > > mode > >
Re: [dpdk-dev] [PATCH 2/2] net/mlx5: avoid unbind step to enable switchdev mode
On Mon, 15 Mar 2021 19:52:46 + Slava Ovsiienko wrote: > Hi, Jan > > > -Original Message- > > From: Jan Viktorin > > Sent: Monday, March 15, 2021 21:49 > > To: Slava Ovsiienko > > Cc: dev@dpdk.org; Asaf Penso ; Shahaf Shuler > > ; Matan Azrad > > Subject: Re: [PATCH 2/2] net/mlx5: avoid unbind step to enable switchdev > > mode > > > > On Mon, 15 Mar 2021 19:31:25 + > > Slava Ovsiienko wrote: > > > > > Hi, Jan > > > > Hello Salva, > > > > I am sorry, but I didn't get the point of your response. For me, there was > > 1 PF > > :05:00.1, SRIOV disabled. So, I followed the guide [1]. > > > > 1. Enable SRIOV via mlxconfig. Done. > > > > 2. Configure max number of VFs. Done. > > > > 3. Reset firmware. Done. > > > > In fact, I had to reboot the machine here so I am not convinced the reset of > > firmware is the thing. But I can image that there is some other use case > > for it. > > After reboot, I configured 2 VFs: :05:00.4, :05:00.5. > > > > 4. Unbind the PF :05:00.1. Done. > No, it is the second physical port. You should unbind your VFs instead - > :05:00.4, :05:00.5. > > Please, see: > > > 3. Then, we should unbind VFs ONLY, PF should be kept untouched. OK. Now I understand. Thus, the guide should read "Unbind the VF devices (can be rebind after the switchdev mode)". I will post v2 with this change. Thanks for clarification. Jan > > With best regards, > Slava > > > > > 5. Fail, no way how to configure switchdev because of previous step. > > Thus, I strongly believe that the guide is misleading here. > > > > When I bound the PF :05:00.1 back, I could configure the switchdev > > mode and everything was just OK and seemed to be working. So **after** > > the bind I configured the switchdev mode properly. > > > > [1] https://doc.dpdk.org/guides/nics/mlx5.html#enable-switchdev-mode > > > > Jan > > > > > > > > 1. Let's suppose we have the one port NIC, PCI BDF 08:00.0, SR-IOV > > > enabled, 0 VFs is configured, netdev name is ens1f0 (depends on distro > > and kernel version). > > > > > > 2. Then, we configure 3 VFs with SR-IOV, we get : > > > - 08:00.0 - PF, ens1f0 > > > - 08:00.1 - VF0, ens1f1 > > > - 08:00.2 - VF1, ens1f2 > > > - 08:00.3 - VF2, ens1f3 > > > > > > 3. Then, we should unbind VFs ONLY, PF should be kept untouched. > > > - 08:00.0 - PF, ens1f0 > > > - 08:00.1 - VF0, - > > > - 08:00.2 - VF1, - > > > - 08:00.3 - VF2, - > > > > > > 4. Then, configure switchdev mode > > > - 08:00.0 - PF, ens1f0 > > > - 08:00.1 - VF0, - > > > - 08:00.2 - VF1, - > > > - 08:00.3 - VF2, - > > > + we get 3 representor netdevs: > > > ens1f0_0 (no dedicated PCI device) > > > ens1f0_1 (no dedicated PCI device) > > > ens1f0_2 (no dedicated PCI device) > > > > > > 5. Then, bind VFs back (assume we are no going to map them to VMs) > > > - 08:00.0 - PF, ens1f0 > > > - 08:00.1 - VF0, ens1f1 > > > - 08:00.2 - VF1, ens1f2 > > > - 08:00.3 - VF2, ens1f3 > > > - ens1f0_0 (no dedicated PCI device) > > > - ens1f0_1 (no dedicated PCI device) > > > - ens1f0_2 (no dedicated PCI device) > > > > > > 6. As result we should get 7 netdevs - 1 PF (Uplink representor), 3 > > > VFs, 3 representors (no PCI device, pure netdev) > > > > > > With best regards, Slava > > > > > > > -Original Message- > > > > From: Jan Viktorin > > > > Sent: Monday, March 15, 2021 18:11 > > > > To: Slava Ovsiienko > > > > Cc: dev@dpdk.org; Asaf Penso ; Shahaf Shuler > > > > ; Matan Azrad > > > > Subject: Re: [PATCH 2/2] net/mlx5: avoid unbind step to enable > > > > switchdev mode > > > > > > > > Hello Salva, > > > > > > > > On Mon, 15 Mar 2021 15:53:51 + > > > > Slava Ovsiienko wrote: > > > > > > > > > Hi, Jan > > > > > > > > > > Yes, bullet [4] explicitly requires to unbind VFs, and detach the > > > > > netdevs > > > > from the mlx5_core driver. > > > > > Otherwise, kernel driver refuses to be configured with switchdev > > > > > mode in > > > > [5]. So, [4] can't be skipped. > > > > > A
Re: [dpdk-dev] [dpdk-stable] [PATCH 1/2] net/virtio: fix performance regression due to TSO enabling
On Thu, 12 Jan 2017 10:30:58 +0800
Yuanhan Liu wrote:
> On Wed, Jan 11, 2017 at 03:51:22PM +0100, Thomas Monjalon wrote:
> > 2017-01-11 12:27, Yuanhan Liu:
> > > The fact that virtio net header is initiated to zero in PMD driver
> > > init stage means that these costly writes are unnecessary and could
> > > be avoided:
> > >
> > > if (hdr->csum_start != 0)
> > > hdr->csum_start = 0;
> > >
> > > And that's what the macro ASSIGN_UNLESS_EQUAL does. With this, the
> > > performance drop introduced by TSO enabling is recovered: it could
> > > be up to 20% in micro benchmarking.
> >
> > This patch is adding a condition to assignments.
> > We need a benchmark on other architectures like ARM. Please anyone?
>
> I think the cost of condition should be way lower than the cost from the
> penalty introduced by the cache issue, that I don't see it would perform
> bad on other platforms.
>
> But, of course, testing is always welcome!
>
> --yliu
Hello,
we've done a synthetic measurement, principle briefly:
== Without condition check ==
start = gettimeofday();
for (i = 0; i < 1024*1024*128; ++i) {
hdr->csum_start = 0;
hdr->csum_offset = 0;
hdr->flags = 0;
}
end = gettimeofday();
== With condition check ==
start = gettimeofday();
for (i = 0; i < 1024*1024*128; ++i) {
ASSIGN_UNLESS_EQUAL(hdr->csum_start, 0);
ASSIGN_UNLESS_EQUAL(hdr->csum_offset, 0);
ASSIGN_UNLESS_EQUAL(hdr->flags, 0);
}
end = gettimeofday();
== Results ==
Computed as total time of all threads:
for i = 1..THREAD_COUNT:
result += end[i] - start[i]
cpu threads without-check (ms) with-check
Xeon E5-26701516 529
Xeon E5-26702 1155 953
Xeon E5-26708 8947 5044
Xeon E5-2670 16 2333516836
Zynq-7020 (armv7) 1 6735 7205
Zynq-7020 (armv7) 2 1375314418
The advantage for Intel is evident when increasing the number
of threads.
However, on 32-bit ARMs we might expect some performance drop.
Regards
Jan
> >
> >
> > [...]
> > > +/* avoid write operation when necessary, to lessen cache issues */
> > > +#define ASSIGN_UNLESS_EQUAL(var, val) do { \
> > > + if ((var) != (val)) \
> > > + (var) = (val); \
> > > +} while (0)
Re: [dpdk-dev] compilation error in l3fwd for ARMv7 NEON
On Fri, 07 Jul 2017 17:24:38 +0200 Thomas Monjalon wrote: > Hi Jianbo, > > It seems your NEON acceleration of the example l3fwd > is not compiling for ARMv7: > examples/l3fwd/l3fwd_neon.h:113:6: error: > implicit declaration of function ‘vaddvq_u16’ > > I am using gcc-linaro-6.3.1-2017.05-x86_64_arm-linux-gnueabihf. > > Is it something we can fix easily? It seems that the vaddvq_u16 is for AArch64 only. It is not listed in: https://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/ARM-NEON-Intrinsics.html And e.g. here: https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00162.html they ifdef it for __aarch64. Regards Jan -- Jan Viktorin E-mail: vikto...@rehivetech.com System Architect Web:www.RehiveTech.com RehiveTech Brno, Czech Republic
[dpdk-dev] [PATCH v4 11/17] eal/soc: add default scan for Soc devices
On Mon, 24 Oct 2016 17:38:29 +0530
Shreyansh Jain wrote:
> Hi Jan,
>
> On Sunday 16 October 2016 12:42 PM, Shreyansh Jain wrote:
> > Hi Jan,
> >
[...]
> >>
> >>> +
> >>> +int
> >>> +rte_eal_soc_scan(void)
> >>
> >> What about naming it rte_eal_soc_scan_default? This would underline the
> >> fact that this function can be replaced.
> >
> > Yes, that would be in sync with match default. I will do it.
>
> In v5 I have replaced the name with rte_eal_soc_platform_bus(). This is
> long but it does exactly what the name states - scan for platform bus.
> This is still a helper.
OK.
>
> >
> >>
> >> Second, this is for the 7/17 patch:
> >>
> >> -/* register a driver */
> >> void
> >> rte_eal_soc_register(struct rte_soc_driver *driver)
> >> {
> >> + /* For a valid soc driver, match and scan function
> >> + * should be provided.
> >> + */
> >> + RTE_VERIFY(driver != NULL);
> >> + RTE_VERIFY(driver->match_fn != NULL);
> >> + RTE_VERIFY(driver->scan_fn != NULL);
> >>
> >> What about setting the match_fn and scan_fn to default implementations if
> >> they
> >> are NULL? This would make the standard/default approach easier to use.
> >>
> >>TAILQ_INSERT_TAIL(&soc_driver_list, driver, next);
> >> }
> >
> > I am not in favor of a forced default. What if user never intended it - it
> > would lead to wrong scan being used and only intimation which can provided
> > to user is a log.
> > Selecting such functions should be a model of PMD - one which is enforced.
>
> As mentioned before, I am not in favor of a 'default' implementation.
> Thus, I would rather call these functions as 'helpers' rather than defaults.
Hmm, OK.
Jan
>
> [...]
>
> -
> Shreyansh
--
Jan Viktorin E-mail: Viktorin at RehiveTech.com
System Architect Web:www.RehiveTech.com
RehiveTech
Brno, Czech Republic
[dpdk-dev] [PATCH v5 01/21] eal: generalize PCI kernel driver enum to EAL
On Mon, 24 Oct 2016 17:29:20 +0530 Shreyansh Jain wrote: > From: Jan Viktorin > > Signed-off-by: Jan Viktorin > Signed-off-by: Shreyansh Jain I think, there is no reason to prevent merging this. Feel free to add: Acked-by: Jan Viktorin
[dpdk-dev] [PATCH v5 06/21] eal/soc: introduce very essential SoC infra definitions
On Mon, 24 Oct 2016 17:29:25 +0530
Shreyansh Jain wrote:
> From: Jan Viktorin
>
> Define initial structures and functions for the SoC infrastructure.
> This patch supports only a very minimal functions for now.
> More features will be added in the following commits.
>
> Includes rte_device/rte_driver inheritance of
> rte_soc_device/rte_soc_driver.
>
> Signed-off-by: Jan Viktorin
> Signed-off-by: Shreyansh Jain
> Signed-off-by: Hemant Agrawal
> ---
> app/test/Makefile | 1 +
> app/test/test_soc.c | 90 +
> lib/librte_eal/common/Makefile | 2 +-
> lib/librte_eal/common/eal_private.h | 4 +
> lib/librte_eal/common/include/rte_soc.h | 138
>
> 5 files changed, 234 insertions(+), 1 deletion(-)
> create mode 100644 app/test/test_soc.c
> create mode 100644 lib/librte_eal/common/include/rte_soc.h
>
> diff --git a/app/test/Makefile b/app/test/Makefile
[...]
> +++ b/lib/librte_eal/common/include/rte_soc.h
> @@ -0,0 +1,138 @@
[...]
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +struct rte_soc_id {
> + const char *compatible; /**< OF compatible specification */
> + uint64_t priv_data; /**< SoC Driver specific data */
Do you expect this to be a pointer?
> +};
> +
[...]
> +
> +/**
> + * Initialization function for the driver called during SoC probing.
> + */
> +typedef int (soc_devinit_t)(struct rte_soc_driver *, struct rte_soc_device
> *);
> +
> +/**
> + * Uninitialization function for the driver called during hotplugging.
> + */
> +typedef int (soc_devuninit_t)(struct rte_soc_device *);
> +
> +/**
> + * A structure describing a SoC driver.
> + */
> +struct rte_soc_driver {
> + TAILQ_ENTRY(rte_soc_driver) next; /**< Next in list */
> + struct rte_driver driver; /**< Inherit core driver. */
> + soc_devinit_t *devinit;/**< Device initialization */
> + soc_devuninit_t *devuninit;/**< Device uninitialization */
Shouldn't those functions be named probe/remove?
> + const struct rte_soc_id *id_table; /**< ID table, NULL terminated */
> +};
> +
[...]
> +#endif
--
Jan Viktorin E-mail: Viktorin at RehiveTech.com
System Architect Web:www.RehiveTech.com
RehiveTech
Brno, Czech Republic
[dpdk-dev] [PATCH v8 00/25] Introducing rte_driver/rte_device generalization
Hi Shreyansh,
I am sorry to be quiet on this thread. I am traveling in those
two weeks and have some vacation. However, I passively follow the
conversation. Thank you for your work so far!
Regards
Jan
On Fri, 26 Aug 2016 19:26:38 +0530
Shreyansh Jain wrote:
> Based on master (e22856313fff2)
>
> Background:
> ===
>
> It includes two different patch-sets floated on ML earlier:
> * Original patch series is from David Marchand [1], [2].
> `- This focused mainly on PCI (PDEV) part
> `- v7 of this was posted by me [8] in August/2016
> * Patch series [4] from Jan Viktorin
> `- This focused on VDEV and rte_device integration
>
> Introduction:
> =
>
> This patch series introduces a generic device model, moving away from PCI
> centric code layout. Key change is to introduce rte_driver/rte_device
> structures at the top level which are inherited by
> rte_XXX_driver/rte_XXX_device - where XXX belongs to {pci, vdev, soc (in
> future),...}.
>
> Key motivation for this series is to move away from PCI centric design of
> EAL to a more hierarchical device model - pivoted around a generic driver
> and device. Each specific driver and device can inherit the common
> properties of the generic set and build upon it through driver/device
> specific functions.
>
> Earlier, the EAL device initialization model was:
> (Refer: [3])
>
> --
> Constructor:
> |- PMD_DRIVER_REGISTER(rte_driver)
> `- insert into dev_driver_list, rte_driver object
>
> rte_eal_init():
> |- rte_eal_pci_init()
> | `- scan and fill pci_device_list from sysfs
> |
> |- rte_eal_dev_init()
> | `- For each rte_driver in dev_driver_list
> | `- call the rte_driver->init() function
> ||- PMDs designed to call rte_eth_driver_register(eth_driver)
> ||- eth_driver have rte_pci_driver embedded in them
> |`- rte_eth_driver_register installs the
> | rte_pci_driver->devinit/devuninit callbacks.
> |
> |- rte_eal_pci_probe()
> | |- For each device detected, dev_driver_list is parsed and matching is
> | | done.
> | |- For each matching device, the rte_pci_driver->devinit() is called.
> | |- Default map is to rte_eth_dev_init() which in turn creates a
> | | new ethernet device (eth_dev)
> | | `- eth_drv->eth_dev_init() is called which is implemented by
> `--|individual PMD drivers.
>
> --
>
> The structure of driver looks something like:
>
> ++ ._.
> | rte_driver <-| PMD |___
> | .init | `-` \
> +.---+ | \
> `-.| What PMD actually is
> \ | |
> +--v+ |
> | eth_driver| |
> | .eth_dev_init | |
> +.--+ |
>`-. |
> \ |
>+v---+
>| rte_pci_driver |
>| .pci_devinit |
>++
>
> and all devices are part of a following linked lists:
> - dev_driver_list for all rte_drivers
> - pci_device_list for all devices, whether PCI or VDEV
>
>
> From the above:
> * a PMD initializes a rte_driver, eth_driver even though actually it is a
>pci_driver
> * initialization routines are passed from rte_driver->pci_driver->eth_driver
>even though they should ideally be rte_eal_init()->rte_pci_driver()
> * For a single driver/device type model, this is not necessarily a
>functional issue - but more of a design language.
> * But, when number of driver/device type increase, this would create problem
>in how driver<=>device links are represented.
>
> Proposed Architecture:
> ==
>
> A nice representation has already been created by David in [3]. Copying that
> here:
>
> +--+ +---+
> | | | |
> | rte_pci_device | | rte_pci_driver|
> | | | |
> +-+ | +--+ | | +---+ |
> | | | | | | | | | |
> | rte_eth_dev +---> rte_device +-> rte_driver| |
> | | | | char name[] | | | | char name[] | |
> +-+ | | | | | | int init(rte_device *) | |
> | +--+ | | | i
[dpdk-dev] [PATCH v3 02/15] eal/soc: add rte_eal_soc_register/unregister logic
On Thu, 15 Sep 2016 14:00:25 +0100 "Hunt, David" wrote: > > new file mode 100644 > > index 000..56135ed > > --- /dev/null > > +++ b/lib/librte_eal/common/eal_common_soc.c > > @@ -0,0 +1,56 @@ > > +/*- > > + * BSD LICENSE > > + * > > + * Copyright(c) 2016 RehiveTech. All rights reserved. > > + * All rights reserved. > > Duplicate "All rights reserved" This is present in many source files in DPDK... I don't know why. lib/librte_eal/common/eal_common_pci.c lib/librte_eal/common/eal_common_dev.c ... Jan > > > + * > > + * Redistribution and use in source and binary forms, with or without > > + * modification, are permitted provided that the following conditions > > + * are met: > > + * > > + * * Redistributions of source code must retain the above copyright > > + * notice, this list of conditions and the following disclaimer. > > + * * Redistributions in binary form must reproduce the above copyright > > + * notice, this list of conditions and the following disclaimer in > > + * the documentation and/or other materials provided with the > > + * distribution. > > + * * Neither the name of RehiveTech nor the names of its > > + * contributors may be used to endorse or promote products derived > > + * from this software without specific prior written permission. > > + *
[dpdk-dev] [PATCH v3 04/15] eal: introduce --no-soc option
Hello Shreyansh,
there was an objection to reverse this option from negative
to positive semantics:
http://dpdk.org/ml/archives/dev/2016-May/038953.html
As SoC infrastructure would to be experimental for some time,
I think it is a good idea to disable it as default.
Regards
Jan
On Fri, 9 Sep 2016 14:13:48 +0530
Shreyansh Jain wrote:
> This option has the same meaning for the SoC infra as the --no-pci
> for the PCI infra.
>
> Signed-off-by: Jan Viktorin
> Signed-off-by: Shreyansh Jain
> Signed-off-by: Hemant Agrawal
> ---
> lib/librte_eal/common/eal_common_options.c | 5 +
> lib/librte_eal/common/eal_internal_cfg.h | 1 +
> lib/librte_eal/common/eal_options.h| 2 ++
> 3 files changed, 8 insertions(+)
>
> diff --git a/lib/librte_eal/common/eal_common_options.c
> b/lib/librte_eal/common/eal_common_options.c
> index 1a1bab3..d97cf0a 100644
> --- a/lib/librte_eal/common/eal_common_options.c
> +++ b/lib/librte_eal/common/eal_common_options.c
> @@ -85,6 +85,7 @@ eal_long_options[] = {
> {OPT_NO_HPET, 0, NULL, OPT_NO_HPET_NUM },
> {OPT_NO_HUGE, 0, NULL, OPT_NO_HUGE_NUM },
> {OPT_NO_PCI,0, NULL, OPT_NO_PCI_NUM },
> + {OPT_NO_SOC,0, NULL, OPT_NO_SOC_NUM },
> {OPT_NO_SHCONF, 0, NULL, OPT_NO_SHCONF_NUM},
> {OPT_PCI_BLACKLIST, 1, NULL, OPT_PCI_BLACKLIST_NUM},
> {OPT_PCI_WHITELIST, 1, NULL, OPT_PCI_WHITELIST_NUM},
> @@ -855,6 +856,10 @@ eal_parse_common_option(int opt, const char *optarg,
> conf->no_pci = 1;
> break;
>
> + case OPT_NO_SOC_NUM:
> + conf->no_soc = 1;
> + break;
> +
> case OPT_NO_HPET_NUM:
> conf->no_hpet = 1;
> break;
> diff --git a/lib/librte_eal/common/eal_internal_cfg.h
> b/lib/librte_eal/common/eal_internal_cfg.h
> index 5f1367e..3a98e94 100644
> --- a/lib/librte_eal/common/eal_internal_cfg.h
> +++ b/lib/librte_eal/common/eal_internal_cfg.h
> @@ -67,6 +67,7 @@ struct internal_config {
> unsigned hugepage_unlink; /**< true to unlink backing files */
> volatile unsigned xen_dom0_support; /**< support app running on Xen
> Dom0*/
> volatile unsigned no_pci; /**< true to disable PCI */
> + volatile unsigned no_soc; /**< true to disable SoC */
> volatile unsigned no_hpet;/**< true to disable HPET */
> volatile unsigned vmware_tsc_map; /**< true to use VMware TSC mapping
>
> * instead of native TSC */
> diff --git a/lib/librte_eal/common/eal_options.h
> b/lib/librte_eal/common/eal_options.h
> index a881c62..ba1e704 100644
> --- a/lib/librte_eal/common/eal_options.h
> +++ b/lib/librte_eal/common/eal_options.h
> @@ -69,6 +69,8 @@ enum {
> OPT_NO_HUGE_NUM,
> #define OPT_NO_PCI"no-pci"
> OPT_NO_PCI_NUM,
> +#define OPT_NO_SOC"no-soc"
> + OPT_NO_SOC_NUM,
> #define OPT_NO_SHCONF "no-shconf"
> OPT_NO_SHCONF_NUM,
> #define OPT_SOCKET_MEM"socket-mem"
--
Jan Viktorin E-mail: Viktorin at RehiveTech.com
System Architect Web:www.RehiveTech.com
RehiveTech
Brno, Czech Republic
[dpdk-dev] [PATCH v10 02/25] eal: remove duplicate function declaration
On Fri, 16 Sep 2016 09:59:37 +0530
Shreyansh Jain wrote:
> From: David Marchand
>
> rte_eal_dev_init is declared in both eal_private.h and rte_dev.h since its
> introduction.
> This function has been exported in ABI, so remove it from eal_private.h
>
> Fixes: e57f20e05177 ("eal: make vdev init path generic for both virtual and
> pci devices")
>
> Signed-off-by: David Marchand
> Signed-off-by: Shreyansh Jain
Reviewed-by: Jan Viktorin
[dpdk-dev] [PATCH v10 05/25] crypto: no need for a crypto pmd type
On Fri, 16 Sep 2016 09:59:40 +0530 Shreyansh Jain wrote: > From: David Marchand > > This information is not used and just adds noise. > > Signed-off-by: David Marchand > Signed-off-by: Shreyansh Jain Reviewed-by: Jan Viktorin
[dpdk-dev] [PATCH v3 06/15] eal/soc: implement probing of drivers
On Fri, 9 Sep 2016 14:13:50 +0530
Shreyansh Jain 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
> Signed-off-by: Shreyansh Jain
> Signed-off-by: Hemant Agrawal
> ---
> app/test/test_soc.c | 138 ++-
> lib/librte_eal/bsdapp/eal/rte_eal_version.map | 4 +
> lib/librte_eal/common/eal_common_soc.c | 215
>
> lib/librte_eal/common/include/rte_soc.h | 51 ++
> lib/librte_eal/linuxapp/eal/eal.c | 5 +
> lib/librte_eal/linuxapp/eal/eal_soc.c | 16 ++
> lib/librte_eal/linuxapp/eal/rte_eal_version.map | 4 +
> 7 files changed, 432 insertions(+), 1 deletion(-)
>
> diff --git a/app/test/test_soc.c b/app/test/test_soc.c
> index ac03e64..d2b9462 100644
> --- a/app/test/test_soc.c
> +++ b/app/test/test_soc.c
> @@ -87,14 +87,45 @@ static int test_compare_addr(void)
> */
> struct test_wrapper {
> struct rte_soc_driver soc_drv;
> + struct rte_soc_device soc_dev;
> };
>
> +static int empty_pmd0_devinit(struct rte_soc_driver *drv,
> + struct rte_soc_device *dev);
> +static int empty_pmd0_devuninit(struct rte_soc_device *dev);
I prefer an empty line here.
What is the prupose of the scan here? What device does it provide
to the test? I'd prefer to call it e.g. "allways_find_device0" or
something describing the purpose and explaining what is the goal
of the related test.
Probably a comment explaining "provide a device named 'empty_pmd0_dev'
would be helpful.
> +static void test_soc_scan_dev0_cb(void);
Similar here, something like "match_by_name".
> +static int test_soc_match_dev0_cb(struct rte_soc_driver *drv,
> + struct rte_soc_device *dev);
I prefer an empty line here.
ditto...
> +static void test_soc_scan_dev1_cb(void);
ditto...
> +static int test_soc_match_dev1_cb(struct rte_soc_driver *drv,
> + struct rte_soc_device *dev);
> +
> +static int
> +empty_pmd0_devinit(struct rte_soc_driver *drv __rte_unused,
> +struct rte_soc_device *dev __rte_unused)
> +{
> + return 0;
> +}
> +
> +static int
> +empty_pmd0_devuninit(struct rte_soc_device *dev)
> +{
> + /* Release the memory associated with dev->addr.name */
> + free(dev->addr.name);
> +
> + return 0;
> +}
> +
> struct test_wrapper empty_pmd0 = {
> .soc_drv = {
> .driver = {
> .name = "empty_pmd0"
> },
> - },
> + .devinit = empty_pmd0_devinit,
> + .devuninit = empty_pmd0_devuninit,
> + .scan_fn = test_soc_scan_dev0_cb,
> + .match_fn = test_soc_match_dev0_cb,
> + }
> };
>
> struct test_wrapper empty_pmd1 = {
> @@ -102,9 +133,54 @@ struct test_wrapper empty_pmd1 = {
> .driver = {
> .name = "empty_pmd1"
> },
> + .scan_fn = test_soc_scan_dev1_cb,
> + .match_fn = test_soc_match_dev1_cb,
> },
> };
>
> +static void
> +test_soc_scan_dev0_cb(void)
> +{
> + /* SoC's scan would scan devices on its bus and add to
> + * soc_device_list
> + */
> + empty_pmd0.soc_dev.addr.name = strdup("empty_pmd0_dev");
> +
> + TAILQ_INSERT_TAIL(&soc_device_list, &empty_pmd0.soc_dev, next);
> +}
> +
> +static int
> +test_soc_match_dev0_cb(struct rte_soc_driver *drv __rte_unused,
> +struct rte_soc_device *dev)
> +{
> + if (!dev->addr.name || strcmp(dev->addr.name, "empty_pmd0_dev"))
> + return 0;
> +
> + return 1;
> +}
> +
> +
> +static void
> +test_soc_scan_dev1_cb(void)
> +{
> + /* SoC's scan would scan devices on its bus and add to
> + * soc_device_list
> + */
> + empty_pmd0.soc_dev.addr.name = strdup("empty_pmd1_dev");
> +
> + TAILQ_INSERT_TAIL(&soc_device_list, &empty_pmd1.soc_dev, next);
> +}
> +
> +static int
> +test_soc_match_dev1_cb(struct rte_soc_driver *drv __rte_unused,
> +struct rte_soc_device *dev)
> +{
> + if (!dev->addr.name || strcmp(dev->addr.name, "empty_pmd1_dev"))
> + return 0;
> +
> + return 1;
> +}
>
[dpdk-dev] [PATCH v3 00/15] Introduce SoC device/driver framework for EAL
On Sun, 18 Sep 2016 13:58:50 +0800 Jianbo Liu wrote: > On 9 September 2016 at 16:43, Shreyansh Jain > wrote: > > Introduction: > > = > > > > This patch set is direct derivative of Jan's original series [1],[2]. > > > > - As this deviates substantially from original series, if need be I can > >post it as a separate patch rather than v2. Please suggest. > > - Also, there are comments on original v1 ([4]) which are _not_ > >incorporated in this series as they refer to section no more in new > >version. > > - This v3 version is based on the rte_driver/device patchset v9 [10]. > >That series introduced device structures (rte_driver/rte_device) > >generalizing devices into PCI, VDEV, XXX. For the purpose of this > >patchset, XXX=>SOC. [...] > > > > 5) Design considerations that are different from PCI: > > - Each driver implements its own scan and match function. PCI uses the BDF > >format to read the device from sysfs, but this _may_not_ be a case for a > >SoC ethernet device. > >= This is an important change from initial proposal by Jan in [2]. Unlike > >his attempt to use /sys/bus/platform, this patch relies on the PMD to > > It could be many redundant code if Each PMD driver has the scan > function if its own. > I think Jan's implementation is common to many platform drivers. I personally can find a use case for having a custom scan function. However, we should at least provide a default implementation. Probably, both the scan and match functions should be used to _override_ a default behaviour. So, only drivers that require to scan devices in a specific way would provide a custom function for this. I agree, that this can sometimes lead to code duplication. Moreover, it opens door for a very non-standard, unsecure and wrong-by-design approaches. I'd like more to provide one or more scan implementations in EAL and do not put this responsibility on PMDs. > > >detect the devices. This is because SoC may require specific or > >additional info for device detection. Further, SoC may have embedded Can you provide an example for "additional info for device detection"? > > Can you give us more precise definition about SoC driver? Does it > include the driver in ARM server? I am sorry but I don't understand this question. What you mean by a "driver in ARM server"? Do you mean a kernel driver? There is no "SoC driver" in the text so what definition are asking for? > > >devices/MACs which require initialization which cannot be covered through > >sysfs parsing. I think, the description itself is incorrect. If a device's initialization cannot be satisfied vie sysfs, it means that you have to write a specific probe function. This is not related to scan in any way. However, there may be a group of devices which are not managed by the standard platform_driver of the Linux Kernel (or other OS). In that case, the custom scan function would be helpful. I can imagine a device in a fully I/O coherent platform that only requires to access the /dev/mem only (for the register space). It is unsecure but it would work without any OS-driver. However, I consider it a corner case. It can be useful for testing sometimes but not very helpful for production. We should however support mainly the standard devices which are always represented by the OS. Otherwise, such system would introduce security issues. > > I think it can be done in devinit, not in scan function. devinit can > be different for each driver. +1 > > > = PCI based PMDs rely on EAL's capability to detect devices. This > >proposal puts the onus on PMD to detect devices, add to soc_device_list > >and wait for Probe. Matching, of device<=>driver is again PMD's callback. > > Regards Jan -- Jan ViktorinE-mail: Viktorin at RehiveTech.com System ArchitectWeb:www.RehiveTech.com RehiveTech Brno, Czech Republic
[dpdk-dev] [PATCH v3 00/15] Introduce SoC device/driver framework for EAL
On Sun, 18 Sep 2016 16:56:54 +0800 Jianbo Liu wrote: > On 18 September 2016 at 15:22, Jan Viktorin > wrote: > > On Sun, 18 Sep 2016 13:58:50 +0800 > > Jianbo Liu wrote: > > > >> On 9 September 2016 at 16:43, Shreyansh Jain > >> wrote: > >> > Introduction: > >> > = > >> > > >> > This patch set is direct derivative of Jan's original series [1],[2]. > >> > > >> > - As this deviates substantially from original series, if need be I can > >> >post it as a separate patch rather than v2. Please suggest. > >> > - Also, there are comments on original v1 ([4]) which are _not_ > >> >incorporated in this series as they refer to section no more in new > >> >version. > >> > - This v3 version is based on the rte_driver/device patchset v9 [10]. > >> >That series introduced device structures (rte_driver/rte_device) > >> >generalizing devices into PCI, VDEV, XXX. For the purpose of this > >> >patchset, XXX=>SOC. > > > > [...] > > > >> > > >> > 5) Design considerations that are different from PCI: > >> > - Each driver implements its own scan and match function. PCI uses the > >> > BDF > >> >format to read the device from sysfs, but this _may_not_ be a case > >> > for a > >> >SoC ethernet device. > >> >= This is an important change from initial proposal by Jan in [2]. > >> > Unlike > >> >his attempt to use /sys/bus/platform, this patch relies on the PMD to > >> > > >> > >> It could be many redundant code if Each PMD driver has the scan > >> function if its own. > >> I think Jan's implementation is common to many platform drivers. > > > > I personally can find a use case for having a custom scan function. > > However, we should at least provide a default implementation. Probably, > > both the scan and match functions should be used to _override_ a default > > behaviour. So, only drivers that require to scan devices in a specific > > way would provide a custom function for this. > > > And for each platform/product > > > I agree, that this can sometimes lead to code duplication. Moreover, it > > opens door for a very non-standard, unsecure and wrong-by-design > > approaches. I'd like more to provide one or more scan implementations > > in EAL and do not put this responsibility on PMDs. > > > >> > >> >detect the devices. This is because SoC may require specific or > >> >additional info for device detection. Further, SoC may have embedded > > > > Can you provide an example for "additional info for device detection"? > > > >> > >> Can you give us more precise definition about SoC driver? Does it > >> include the driver in ARM server? > > > > I am sorry but I don't understand this question. > > > > What you mean by a "driver in ARM server"? Do you mean a kernel driver? > > > > There is no "SoC driver" in the text so what definition are asking for? > > > This patchset introduces rte_soc_driver, which is inheriting from rte_driver. > I want to know what devices can use this SoC driver/device framework. > Is it for the devices from ARM servers, or embedded systems of > different vendors? First, this is not an ARM-specific feature. Consider any MAC connected to the processor via some on-chip bus. In the world of ARM, it is usually a kind of AMBA bus. I think, the Intel Xeon with FPGA would be a good non-ARM example. Here they provide the Quick Path bus (but I don't know the details). So, you cannot access such device as PCI. It is usually not possible to distinguish the bus type easily (Linux calls this a platform device). So, an rte_soc_device denotes a device integrated on the chip (SoC, System-on-Chip). Such devices can have a lower access latency because they are closer to the processor. So, if you have a server system driver by a SoC with integrated MACs (no PCI-E involved), there is no way how to access them from DPDK. An rte_soc_device represents such devices and provides a way how to access them from DPDK. That is the goal... You can have an embedded device (router, switch, monitoring device, NAT, firewall, anything in a "small box" with high throughput demands) that perfectly fits into this SoC framework because it would be usually based on some SoC (ARM, ARM64, ...). > And this framework is too generalized, if we don't try to understand > &quo
[dpdk-dev] [PATCH v3 00/15] Introduce SoC device/driver framework for EAL
On Sun, 18 Sep 2016 09:41:55 + Hemant Agrawal wrote: > > -Original Message- > > From: Jan Viktorin [mailto:viktorin at rehivetech.com] > [...] > > > And for each platform/product > > > > > > > I agree, that this can sometimes lead to code duplication. Moreover, > > > > it opens door for a very non-standard, unsecure and wrong-by-design > > > > approaches. I'd like more to provide one or more scan > > > > implementations in EAL and do not put this responsibility on PMDs. > Hi Hemant. > [Hemant] A common/default scan function can be added, provided at least one > or more PMD driver support it. > w.r.t Jan's original scan function, it was not suitable for any of the NXP > SoC's whether ARM or PowerPC. > > Unable to validate the Jan's scan function on a real platform, we have > skipped it for next phase. > Addition of a default scan function can only be done in next phase, when we > find a suitable SoC PMD driver supporting it. Quite frankly, the situation is same for me. I still have no clue about your approach which seems to be pretty non-standard. I have no way how to test it. My approach can be tested on any Linux machine with platform devices and device-tree enabled. You would see that I detect those devices (I don't mean any certain network device, I mean all platform devices) and if you provide a driver with a proper compatible string it will be set for you. I presume that I don't have any upstreamable PMD for this at the moment.
[dpdk-dev] [PATCH v3 06/15] eal/soc: implement probing of drivers
On Mon, 19 Sep 2016 12:17:53 +0530
Shreyansh Jain wrote:
> Hi Jan,
>
> On Friday 16 September 2016 05:57 PM, Jan Viktorin wrote:
> > On Fri, 9 Sep 2016 14:13:50 +0530
> > Shreyansh Jain 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
> >> Signed-off-by: Shreyansh Jain
> >> Signed-off-by: Hemant Agrawal
> >> ---
> >> app/test/test_soc.c | 138 ++-
> >> lib/librte_eal/bsdapp/eal/rte_eal_version.map | 4 +
> >> lib/librte_eal/common/eal_common_soc.c | 215
> >>
> >> lib/librte_eal/common/include/rte_soc.h | 51 ++
> >> lib/librte_eal/linuxapp/eal/eal.c | 5 +
> >> lib/librte_eal/linuxapp/eal/eal_soc.c | 16 ++
> >> lib/librte_eal/linuxapp/eal/rte_eal_version.map | 4 +
> >> 7 files changed, 432 insertions(+), 1 deletion(-)
> >>
[...]
>
> >
> >> +static void test_soc_scan_dev0_cb(void);
> >
> > Similar here, something like "match_by_name".
> >
> >> +static int test_soc_match_dev0_cb(struct rte_soc_driver *drv,
> >> +struct rte_soc_device *dev);
> >
> > I prefer an empty line here.
>
> Do we really place newlines in function declarations? That doesn't
> really help anything, until and unless some comments are added to those.
> Anyways, rather than added blank lines, I will add some comments - those
> are indeed misssing.
It took me a while to parse those lines... If they are logically grouped,
it'd be ok. Comments might be helpful. However, here these are forward
declarations so it's a question whether to put comments here or to the
implementations below.
>
> >
> >
> > ditto...
>
> Will add comments.
>
> >
> >> +static void test_soc_scan_dev1_cb(void);
> >
> > ditto...
>
> Same here, I prefer comment rather than blank line.
>
> >
[...]
> >>
> >> +/* Test Probe (scan and match) functionality */
> >> +static int
> >> +test_soc_init_and_probe(void)
> >
> > You say to test scan and match. I'd prefer to reflect this in the name
> > of the test. Otherwise, it seems you are testing init and probe which
> > is not true, I think.
>
> I agree. I will update the name of the function.
>
> >
> > Do you test that "match principle works" or that "match functions are OK"
> > or "match functions are called as expected", ...?
>
> "match functions are called as expected"
OK, but there is no assert that says "yes, the match function has been called".
In other words, it is not an automatic test and it does not help to verify
that the code is working.
I think that you should test that a particular match function succeeds or not.
So again, I don't consider this to be a test. It does not verify anything.
> The model for the patchset was to allow PMDs to write their own match
> and hence, verifying a particular match is not definitive. Rather, the
If you want to verify a particular match implementation then there should
be a particular test verifying that implementation, e.g.
test_match_compatible(),
test_match_proprietary, test_match_by_name.
However, this is testing the rte_eal_soc_probe (at least, I understand it that
way).
The probe iterates over devices and drivers and matches them. Thus, the argument
"a particular match is not definitive" seems to be irrelevant here. You should
build
a testing match function like "match_always" that verifies the probe is
working. Not
that the "match" is working.
> test case simply confirms that a SoC based PMD would be able to
It does not confirm anything from my point of view. You *always* print
"successful"
at the end of this test (see below).
> implement its own match/scan and these would be called from EAL as expected.
>
> >
> >> +{
> >> + struct rte_soc_driver *drv;
> >> +
> >> + /* Registering dummy drivers */
> >> + rte_eal_soc_register(&empty_pmd0.soc_drv);
> >> + rte_eal_soc_register(&empty_pmd1.soc_drv);
> >> + /* Assuming that test_register_unregister is working, not verif
[dpdk-dev] [PATCH v3 06/15] eal/soc: implement probing of drivers
On Tue, 20 Sep 2016 06:46:31 +
Shreyansh Jain wrote:
> Hi Jan,
>
> > -Original Message-
> > From: Jan Viktorin [mailto:viktorin at rehivetech.com]
> > Sent: Monday, September 19, 2016 5:04 PM
> > To: Shreyansh Jain
> > Cc: dev at dpdk.org; Hemant Agrawal
> > Subject: Re: [PATCH v3 06/15] eal/soc: implement probing of drivers
> >
> > On Mon, 19 Sep 2016 12:17:53 +0530
> > Shreyansh Jain wrote:
> >
> > > Hi Jan,
[...]
>
> >
> > > The model for the patchset was to allow PMDs to write their own match
> > > and hence, verifying a particular match is not definitive. Rather, the
> >
> > If you want to verify a particular match implementation then there should
> > be a particular test verifying that implementation, e.g.
> > test_match_compatible(),
> > test_match_proprietary, test_match_by_name.
> >
> > However, this is testing the rte_eal_soc_probe (at least, I understand it
> > that way).
> > The probe iterates over devices and drivers and matches them. Thus, the
> > argument
> > "a particular match is not definitive" seems to be irrelevant here. You
> > should build
> > a testing match function like "match_always" that verifies the probe is
> > working. Not
> > that the "match" is working.
>
> Ok. 'match_always' called after 'always_find_device0' like scan function. So,
> essentially rather than a functional match, the testcase only checks if these
> handlers can be called or not. The naming of such handlers in test case would
> explain the user what the intention of the test is, rather than its outcome.
> Is this what you are suggesting?
Yes, it seems to be ;).
>
> >
> > > test case simply confirms that a SoC based PMD would be able to
> >
> > It does not confirm anything from my point of view. You *always* print
> > "successful"
> > at the end of this test (see below).
> >
> > > implement its own match/scan and these would be called from EAL as
> > expected.
> > >
> > > >
> > > >> +{
> > > >> + struct rte_soc_driver *drv;
> > > >> +
> > > >> + /* Registering dummy drivers */
> > > >> + rte_eal_soc_register(&empty_pmd0.soc_drv);
> > > >> + rte_eal_soc_register(&empty_pmd1.soc_drv);
> > > >> + /* Assuming that test_register_unregister is working, not
> > verifying
> > > >> + * that drivers are indeed registered
> > > >> + */
> > > >> +
> > > >> + /* rte_eal_soc_init is called by rte_eal_init, which in turn
> > calls the
> > > >> + * scan_fn of each driver.
> >
> > So, I'd comment this as something like:
> >
> > "mimic rte_eal_soc_init to prepare for the rte_eal_soc_probe"
>
> Agree.
>
> >
> > > >> + */
> > > >> + TAILQ_FOREACH(drv, &soc_driver_list, next) {
> > > >> + if (drv && drv->scan_fn)
> > > >> + drv->scan_fn();
> > > >> + }
> > > >
> > > > Here, I suppose you mimic the rte_eal_soc_init?
> > >
> > > Yes.
> > >
> > > >
> > > >> +
> > > >> + /* rte_eal_init() would perform other inits here */
> > > >> +
> > > >> + /* Probe would link the SoC devices<=>drivers */
> > > >> + rte_eal_soc_probe();
> > > >> +
> > > >> + /* Unregistering dummy drivers */
> > > >> + rte_eal_soc_unregister(&empty_pmd0.soc_drv);
> > > >> + rte_eal_soc_unregister(&empty_pmd1.soc_drv);
> > > >> +
> > > >> + free(empty_pmd0.soc_dev.addr.name);
> > > >> +
> > > >> + printf("%s has been successful\n", __func__);
> > > >
> > > > How you detect it is unsuccessful? Is it possible to fail in this test?
> > > > A test that can never fail is in fact not a test :).
> > >
> > > The design assumption for SoC patcheset was: A PMDs scan is called to
> > > find devices on its bus (PMD ~ bus). Whether devices are found or not,
> > > is irrelevant to EAL - whether that is because of error or actually no
> > > devices were available.
> > > With the above logic, no 'su
[dpdk-dev] cmdline.c: error: ‘cmd_set_vf_rxmode’ undeclared here (not in a function)
Hi, my testing build for ARMv7 has failed during the last night with the following output: ... AR librte_pmd_octeontx_ssovf.a SYMLINK-FILE include/rte_pmd_octeontx_ssovf.h INSTALL-LIB librte_pmd_octeontx_ssovf.a == Build app == Build app/test-pmd CC testpmd.o CC parameters.o CC cmdline.o /var/lib/jenkins/jobs/dpdk-armv7/workspace/app/test-pmd/cmdline.c:13813:27: error: ‘cmd_set_vf_rxmode’ undeclared here (not in a function) (cmdline_parse_inst_t *)&cmd_set_vf_rxmode, ^ make[3]: *** [cmdline.o] Error 1 make[2]: *** [test-pmd] Error 2 make[1]: *** [app] Error 2 make: *** [all] Error 2 I've bisected the source of the problem to the following commit: commit 4cfe399f65507f30ddc5df63854638f83f385cce (refs/bisect/bad) Author: Ajit Khaparde Date: Thu Jun 1 12:07:22 2017 -0500 net/bnxt: support to set VF rxmode This patch adds support to configure the VF L2 Rx settings. The per VF setting is maintained in bnxt_child_vf_info.l2_rx_mask Signed-off-by: Ajit Khaparde app/test-pmd/cmdline.c| 15 --- drivers/net/bnxt/bnxt_hwrm.c | 24 +--- drivers/net/bnxt/bnxt_hwrm.h | 2 ++ drivers/net/bnxt/bnxt_rxq.c | 13 ++--- drivers/net/bnxt/bnxt_vnic.h | 5 + drivers/net/bnxt/rte_pmd_bnxt.c | 54 ++ drivers/net/bnxt/rte_pmd_bnxt.h | 19 +++ drivers/net/bnxt/rte_pmd_bnxt_version.map | 1 + 8 files changed, 124 insertions(+), 9 deletions(-) Regards Jan -- Jan Viktorin E-mail: vikto...@rehivetech.com System Architect Web:www.RehiveTech.com RehiveTech Brno, Czech Republic
[dpdk-dev] dpdk-armv7: build failure since de96fe68ae9
6_DST,/* struct in6_addr */ ^ In file included from /var/lib/jenkins/jobs/dpdk-armv7/workspace/drivers/net/tap/tap_tcmsgs.h:40:0, from /var/lib/jenkins/jobs/dpdk-armv7/workspace/drivers/net/tap/tap_flow.c:44: /opt/gcc/br2-arm32-glibc-4.9.x/usr/arm-buildroot-linux-gnueabi/sysroot/usr/include/linux/pkt_cls.h:355:2: note: previous definition of ‘TCA_FLOWER_KEY_IPV6_DST’ was here TCA_FLOWER_KEY_IPV6_DST, /* struct in6_addr */ ^ /var/lib/jenkins/jobs/dpdk-armv7/workspace/drivers/net/tap/tap_flow.c:69:2: error: redeclaration of enumerator ‘TCA_FLOWER_KEY_IPV6_DST_MASK’ TCA_FLOWER_KEY_IPV6_DST_MASK, /* struct in6_addr */ ^ In file included from /var/lib/jenkins/jobs/dpdk-armv7/workspace/drivers/net/tap/tap_tcmsgs.h:40:0, from /var/lib/jenkins/jobs/dpdk-armv7/workspace/drivers/net/tap/tap_flow.c:44: /opt/gcc/br2-arm32-glibc-4.9.x/usr/arm-buildroot-linux-gnueabi/sysroot/usr/include/linux/pkt_cls.h:356:2: note: previous definition of ‘TCA_FLOWER_KEY_IPV6_DST_MASK’ was here TCA_FLOWER_KEY_IPV6_DST_MASK, /* struct in6_addr */ ^ /var/lib/jenkins/jobs/dpdk-armv7/workspace/drivers/net/tap/tap_flow.c:70:2: error: redeclaration of enumerator ‘TCA_FLOWER_KEY_TCP_SRC’ TCA_FLOWER_KEY_TCP_SRC, /* be16 */ ^ In file included from /var/lib/jenkins/jobs/dpdk-armv7/workspace/drivers/net/tap/tap_tcmsgs.h:40:0, from /var/lib/jenkins/jobs/dpdk-armv7/workspace/drivers/net/tap/tap_flow.c:44: /opt/gcc/br2-arm32-glibc-4.9.x/usr/arm-buildroot-linux-gnueabi/sysroot/usr/include/linux/pkt_cls.h:357:2: note: previous definition of ‘TCA_FLOWER_KEY_TCP_SRC’ was here TCA_FLOWER_KEY_TCP_SRC, /* be16 */ ^ /var/lib/jenkins/jobs/dpdk-armv7/workspace/drivers/net/tap/tap_flow.c:71:2: error: redeclaration of enumerator ‘TCA_FLOWER_KEY_TCP_DST’ TCA_FLOWER_KEY_TCP_DST, /* be16 */ ^ In file included from /var/lib/jenkins/jobs/dpdk-armv7/workspace/drivers/net/tap/tap_tcmsgs.h:40:0, from /var/lib/jenkins/jobs/dpdk-armv7/workspace/drivers/net/tap/tap_flow.c:44: /opt/gcc/br2-arm32-glibc-4.9.x/usr/arm-buildroot-linux-gnueabi/sysroot/usr/include/linux/pkt_cls.h:358:2: note: previous definition of ‘TCA_FLOWER_KEY_TCP_DST’ was here TCA_FLOWER_KEY_TCP_DST, /* be16 */ ^ /var/lib/jenkins/jobs/dpdk-armv7/workspace/drivers/net/tap/tap_flow.c:72:2: error: redeclaration of enumerator ‘TCA_FLOWER_KEY_UDP_SRC’ TCA_FLOWER_KEY_UDP_SRC, /* be16 */ ^ In file included from /var/lib/jenkins/jobs/dpdk-armv7/workspace/drivers/net/tap/tap_tcmsgs.h:40:0, from /var/lib/jenkins/jobs/dpdk-armv7/workspace/drivers/net/tap/tap_flow.c:44: /opt/gcc/br2-arm32-glibc-4.9.x/usr/arm-buildroot-linux-gnueabi/sysroot/usr/include/linux/pkt_cls.h:359:2: note: previous definition of ‘TCA_FLOWER_KEY_UDP_SRC’ was here TCA_FLOWER_KEY_UDP_SRC, /* be16 */ ^ /var/lib/jenkins/jobs/dpdk-armv7/workspace/drivers/net/tap/tap_flow.c:73:2: error: redeclaration of enumerator ‘TCA_FLOWER_KEY_UDP_DST’ TCA_FLOWER_KEY_UDP_DST, /* be16 */ ^ In file included from /var/lib/jenkins/jobs/dpdk-armv7/workspace/drivers/net/tap/tap_tcmsgs.h:40:0, from /var/lib/jenkins/jobs/dpdk-armv7/workspace/drivers/net/tap/tap_flow.c:44: /opt/gcc/br2-arm32-glibc-4.9.x/usr/arm-buildroot-linux-gnueabi/sysroot/usr/include/linux/pkt_cls.h:360:2: note: previous definition of ‘TCA_FLOWER_KEY_UDP_DST’ was here TCA_FLOWER_KEY_UDP_DST, /* be16 */ ^ make[4]: *** [tap_flow.o] Error 1 make[3]: *** [tap] Error 2 make[2]: *** [net] Error 2 make[1]: *** [drivers] Error 2 make: *** [all] Error 2 Finished: FAILURE Regards Jan Viktorin -- Jan Viktorin E-mail: vikto...@rehivetech.com System Architect Web:www.RehiveTech.com RehiveTech Brno, Czech Republic
Re: [dpdk-dev] dpdk-armv7: build failure since de96fe68ae9
On Fri, 7 Apr 2017 14:05:59 +0200
Pascal Mazon wrote:
> On Fri, 7 Apr 2017 13:13:13 +0200
> Jan Viktorin wrote:
>
> > Hello Pascal,
> >
> > my internal ARMv7 DPDK autobuilder is failing. I've bisected to the
> > source of the problem:
> >
> > commit de96fe68ae95990f5ce2cd4c8d9547ab62d2a810
> > Author: Pascal Mazon
> > Date: Thu Mar 23 09:33:57 2017 +0100
> >
> > net/tap: add basic flow API patterns and actions
> >
> >
> > Is it a know issue? Is there some patch for this already?
>
> Hello Jan,
>
> Well I'm quite surprised (and don't have a patch yet).
> In drivers/net/tap/Makefile, I'm using buildtools/auto-config-h.sh to
> determine whether the TCA_FLOWER_UNSPEC enum can be found when including
> linux/pkt_cls.h.
> In case it isn't found, I define it in tap_flow.c.
>
> What's weird in this case is that auto-config-h.sh apparently doesn't use the
> same linux/pkt_cls.h as during tap compilation time, or it would have found
> it...
>
> Can you run manually this command on the building system?
> VERBOSE=1 sh -- ./buildtools/auto-config-h.sh tap_autoconf.h HAVE_TC_FLOWER
> linux/pkt_cls.h enum TCA_FLOWER_UNSPEC
$ VERBOSE=1
CC=/opt/gcc/br2-arm32-glibc-4.9.x/usr/bin/arm-buildroot-linux-gnueabi-gcc \
sh -- ./buildtools/auto-config-h.sh tap_autoconf.h HAVE_TC_FLOWER
linux/pkt_cls.h enum TCA_FLOWER_UNSPEC
Looking for TCA_FLOWER_UNSPEC enum in linux/pkt_cls.h.
Defining HAVE_TC_FLOWER.
>
> It should define HAVE_TC_FLOWER in the generated tap_autoconf.h.
$ cat tap_autoconf.h
#ifndef HAVE_TC_FLOWER
#define HAVE_TC_FLOWER 1
#endif /* HAVE_TC_FLOWER */
$ grep -n TCA_FLOWER_UNSPEC
/opt/gcc/br2-arm32-glibc-4.9.x/usr/arm-buildroot-linux-gnueabi/sysroot/usr/include/linux/pkt_cls.h
339:TCA_FLOWER_UNSPEC,
>
> The auto-config-h.sh script uses the following for compiling:
> ${CC} ${CPPFLAGS} ${EXTRA_CPPFLAGS} ${CFLAGS} ${EXTRA_CFLAGS}
> ${AUTO_CONFIG_CFLAGS} \
> -c -o /dev/null "${temp}" 1>&${out} 2>&${err}
>
> If it does not use the same include folders as the standard compilation, then
> I guess we ought to fix the script.
I am not sure by this...
Jan
>
> Best regards,
> Pascal
>
> >
> > Error messages:
> >
> > /var/lib/jenkins/jobs/dpdk-armv7/workspace/drivers/net/tap/tap_flow.c:52:2:
> > error: redeclaration of enumerator ‘TCA_FLOWER_UNSPEC’
> > TCA_FLOWER_UNSPEC,
> > ^
> > In file included from
> > /var/lib/jenkins/jobs/dpdk-armv7/workspace/drivers/net/tap/tap_tcmsgs.h:40:0,
> > from
> > /var/lib/jenkins/jobs/dpdk-armv7/workspace/drivers/net/tap/tap_flow.c:44:
> > /opt/gcc/br2-arm32-glibc-4.9.x/usr/arm-buildroot-linux-gnueabi/sysroot/usr/include/linux/pkt_cls.h:339:2:
> > note: previous definition of ‘TCA_FLOWER_UNSPEC’ was here
> > TCA_FLOWER_UNSPEC,
> > ^
> > /var/lib/jenkins/jobs/dpdk-armv7/workspace/drivers/net/tap/tap_flow.c:53:2:
> > error: redeclaration of enumerator ‘TCA_FLOWER_CLASSID’
> > TCA_FLOWER_CLASSID,
> > ^
> > In file included from
> > /var/lib/jenkins/jobs/dpdk-armv7/workspace/drivers/net/tap/tap_tcmsgs.h:40:0,
> > from
> > /var/lib/jenkins/jobs/dpdk-armv7/workspace/drivers/net/tap/tap_flow.c:44:
> > /opt/gcc/br2-arm32-glibc-4.9.x/usr/arm-buildroot-linux-gnueabi/sysroot/usr/include/linux/pkt_cls.h:340:2:
> > note: previous definition of ‘TCA_FLOWER_CLASSID’ was here
> > TCA_FLOWER_CLASSID,
> > ^
> > /var/lib/jenkins/jobs/dpdk-armv7/workspace/drivers/net/tap/tap_flow.c:54:2:
> > error: redeclaration of enumerator ‘TCA_FLOWER_INDEV’
> > TCA_FLOWER_INDEV,
> > ^
> > In file included from
> > /var/lib/jenkins/jobs/dpdk-armv7/workspace/drivers/net/tap/tap_tcmsgs.h:40:0,
> > from
> > /var/lib/jenkins/jobs/dpdk-armv7/workspace/drivers/net/tap/tap_flow.c:44:
> > /opt/gcc/br2-arm32-glibc-4.9.x/usr/arm-buildroot-linux-gnueabi/sysroot/usr/include/linux/pkt_cls.h:341:2:
> > note: previous definition of ‘TCA_FLOWER_INDEV’ was here
> > TCA_FLOWER_INDEV,
> > ^
> > /var/lib/jenkins/jobs/dpdk-armv7/workspace/drivers/net/tap/tap_flow.c:55:2:
> > error: redeclaration of enumerator ‘TCA_FLOWER_ACT’
> > TCA_FLOWER_ACT,
> > ^
> > In file included from
> > /var/lib/jenkins/jobs/dpdk-armv7/workspace/drivers/net/tap/tap_tcmsgs.h:40:0,
> > from
> > /var/lib/jenkins/jobs/dpdk-armv7/workspace/drivers/net/tap/tap_flow.c:44:
> > /opt/gcc/br2-arm32-glibc-4.9.x/usr/arm-buildroot-linux-gnueabi/sysroot/usr/include/linux/pkt_cls.h:342:2:
> >
Re: [dpdk-dev] dpdk-armv7: build failure since de96fe68ae9
On Fri, 7 Apr 2017 15:27:16 +0200 Pascal Mazon wrote: > Hmmm. This is very strange. > From what you've given me, tap_flow.c should include a tap_autoconf.h with > HAVE_TC_FLOWER, avoiding the duplicated definition. > > Just to be sure, can you compile the tap driver with V=1 and look for the > following line? > Looking for TCA_FLOWER_UNSPEC enum in linux/pkt_cls.h. Defining > HAVE_TC_FLOWER. > > And maybe use the following patch to be able to compare variables during > standard compilation: > > diff --git a/drivers/net/tap/Makefile b/drivers/net/tap/Makefile > index c42a680555e9..740d77ed66b9 100644 > --- a/drivers/net/tap/Makefile > +++ b/drivers/net/tap/Makefile > @@ -70,6 +70,8 @@ export AUTO_CONFIG_CFLAGS = -Wno-error > > ifndef V > AUTOCONF_OUTPUT := >/dev/null > +else > +$(info tap_autoconf CC=$(CC) CFLAGS=$(CFLAGS) CPPFLAGS=$(CPPFLAGS) > EXTRA_CFLAGS=$(EXTRA_CFLAGS) EXTRA_CPPFLAGS=$(EXTRA_CPPFLAGS)) > endif > > tap_autoconf.h.new: FORCE > > > Prior to rebuilding, please make sure the tap_autoconf.h are removed from > build/build/drivers/net/tap/. Got it, gcc is failing inside the shell script: tap_autoconf CC=/opt/gcc/br2-arm32-glibc-4.9.x/usr/bin/arm-buildroot-linux-gnueabi-gcc CFLAGS=-marm -munaligned-access -pthread -march=armv7-a -mtune="cortex-a9" -mfpu=neon -DRTE_MACHINE_CPUFLAG_NEON -I/home/viktorin/dpdk/build/include -include /home/viktorin/dpdk/build/include/rte_config.h -O3 -I/home/viktorin/dpdk/drivers/net/tap -I. -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wold-style-definition -Wpointer-arith -Wcast-align -Wnested-externs -Wcast-qual -Wformat-nonliteral -Wformat-security -Wundef -Wwrite-strings -Werror -Wno-error=cast-align CPPFLAGS= EXTRA_CFLAGS=-I/home/viktorin/dpdk/dpdk-armv7-env/usr/local/include EXTRA_CPPFLAGS= rm -f -f -- 'tap_autoconf.h.new' VERBOSE=1 sh -- '/home/viktorin/dpdk/buildtools/auto-config-h.sh' 'tap_autoconf.h.new' \ HAVE_TC_FLOWER \ linux/pkt_cls.h \ enum TCA_FLOWER_UNSPEC \ Looking for TCA_FLOWER_UNSPEC enum in linux/pkt_cls.h. arm-buildroot-linux-gnueabi-gcc.br_real: error: unrecognized argument in option ‘-mtune="cortex-a9"’ arm-buildroot-linux-gnueabi-gcc.br_real: note: valid arguments to ‘-mtune=’ are: arm1020e arm1020t arm1022e arm1026ej-s arm10e arm10tdmi arm1136j-s arm1136jf-s arm1156t2-s arm1156t2f-s arm1176jz-s arm1176jzf-s arm2 arm250 arm3 arm6 arm60 arm600 arm610 arm620 arm7 arm70 arm700 arm700i arm710 arm7100 arm710c arm710t arm720 arm720t arm740t arm7500 arm7500fe arm7d arm7di arm7dm arm7dmi arm7m arm7tdmi arm7tdmi-s arm8 arm810 arm9 arm920 arm920t arm922t arm926ej-s arm940t arm946e-s arm966e-s arm968e-s arm9e arm9tdmi cortex-a12 cortex-a15 cortex-a15.cortex-a7 cortex-a5 cortex-a53 cortex-a57 cortex-a57.cortex-a53 cortex-a7 cortex-a8 cortex-a9 cortex-m0 cortex-m0plus cortex-m1 cortex-m3 cortex-m4 cortex-r4 cortex-r4f cortex-r5 cortex-r7 ep9312 fa526 fa606te fa626 fa626te fa726te fmp626 generic-armv7-a iwmmxt iwmmxt2 marvell-pj4 mpcore mpcorenovfp native strongarm strongarm110 strongarm1100 strongarm1110 xscale Not defining HAVE_TC_FLOWER. sh -- '/home/viktorin/dpdk/buildtools/auto-config-h.sh' 'tap_autoconf.h.new' \ HAVE_TC_VLAN_ID \ linux/pkt_cls.h \ enum TCA_FLOWER_KEY_VLAN_PRIO \ It seems like the -mtune="cortex-a9" has extra quotes (or they are misinterpreted in some way). Jan > > Thank you. > > Best regards, > Pascal > > On Fri, 7 Apr 2017 14:21:34 +0200 > Jan Viktorin wrote: > > > On Fri, 7 Apr 2017 14:05:59 +0200 > > Pascal Mazon wrote: > > > > > On Fri, 7 Apr 2017 13:13:13 +0200 > > > Jan Viktorin wrote: > > > > > > > Hello Pascal, > > > > > > > > my internal ARMv7 DPDK autobuilder is failing. I've bisected to the > > > > source of the problem: > > > > > > > > commit de96fe68ae95990f5ce2cd4c8d9547ab62d2a810 > > > > Author: Pascal Mazon > > > > Date: Thu Mar 23 09:33:57 2017 +0100 > > > > > > > > net/tap: add basic flow API patterns and actions > > > > > > > > > > > > Is it a know issue? Is there some patch for this already? > > > > > > Hello Jan, > > > > > > Well I'm quite surprised (and don't have a patch yet). > > > In drivers/net/tap/Makefile, I'm using buildtools/auto-config-h.sh to > > > determine whether the TCA_FLOWER_UNSPEC enum can be found when including > > > linux/pkt_cls.h. > > > In case it isn't found, I define it in tap_flow.c. > > > > > > W
Re: [dpdk-dev] [PATCH] mk: fix quoting for ARM mtune argument
On Mon, 10 Apr 2017 14:18:51 +0200
Pascal Mazon wrote:
> The mtune argument needs an unquoted argument, otherwise the compiler
> complains:
>
> arm-buildroot-linux-gnueabi-gcc.br_real: error:
> unrecognized argument in option ‘-mtune="cortex-a9"’
>
> Fixes: 02a8686263de ("mk: introduce ARMv7 architecture")
> Fixes: 4a7e4626975a ("mk: introduce NXP dpaa2 architecture based on armv8-a")
>
> Reported-by: Jan Viktorin
> Signed-off-by: Pascal Mazon
Tested-by: Jan Viktorin
> ---
>
> I couldn't test it though, as I don't have an ARM toolchain.
It works for me.
Jan
--
Jan Viktorin E-mail: vikto...@rehivetech.com
System Architect Web:www.RehiveTech.com
RehiveTech
Brno, Czech Republic
Re: [dpdk-dev] [PATCH 1/2] net: add arm64 neon version of CRC compute APIs
Hello Ashwin Sekhar,
some comments below...
On Thu, 27 Apr 2017 07:10:20 -0700
Ashwin Sekhar T K wrote:
> * Added CRC compute APIs for arm64 utilizing the pmull capability
> * Added new file net_crc_neon.h to hold the arm64 pmull CRC
> implementation
> * Added crypto capability in compilation of generic armv8 and
> thunderx targets
> * pmull CRC version is used only after checking the pmull capability
> at runtime
> * Verified the changes with crc_autotest unit test case
>
> Signed-off-by: Ashwin Sekhar T K
> ---
> MAINTAINERS | 1 +
> lib/librte_eal/common/include/arch/arm/rte_vect.h | 45 +++
> lib/librte_net/net_crc_neon.h | 357
> ++
> lib/librte_net/rte_net_crc.c | 32 +-
> lib/librte_net/rte_net_crc.h | 2 +
> mk/machine/armv8a/rte.vars.mk | 2 +-
> mk/machine/thunderx/rte.vars.mk | 2 +-
> mk/rte.cpuflags.mk| 3 +
> mk/toolchain/gcc/rte.toolchain-compat.mk | 1 +
> 9 files changed, 438 insertions(+), 7 deletions(-)
> create mode 100644 lib/librte_net/net_crc_neon.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 576d60a..283743e 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -149,6 +149,7 @@ F: lib/librte_lpm/rte_lpm_neon.h
> F: lib/librte_hash/rte*_arm64.h
> F: lib/librte_efd/rte*_arm64.h
> F: lib/librte_table/rte*_arm64.h
> +F: lib/librte_net/net_crc_neon.h
> F: drivers/net/ixgbe/ixgbe_rxtx_vec_neon.c
> F: drivers/net/i40e/i40e_rxtx_vec_neon.c
> F: drivers/net/virtio/virtio_rxtx_simple_neon.c
> diff --git a/lib/librte_eal/common/include/arch/arm/rte_vect.h
> b/lib/librte_eal/common/include/arch/arm/rte_vect.h
> index 4107c99..9a3dfdf 100644
> --- a/lib/librte_eal/common/include/arch/arm/rte_vect.h
> +++ b/lib/librte_eal/common/include/arch/arm/rte_vect.h
> @@ -34,9 +34,18 @@
> #define _RTE_VECT_ARM_H_
>
> #include
> +#include
> +
> #include "generic/rte_vect.h"
> #include "arm_neon.h"
>
> +#ifdef GCC_VERSION
> +#undef GCC_VERSION
> +#endif
Why are you doing this? What is wrong with GCC_VERSION?
> +
> +#define GCC_VERSION (__GNUC__ * 1 + __GNUC_MINOR__ * 100 \
> + + __GNUC_PATCHLEVEL__)
> +
If you have any specific requirements for testing GCC version then it
should be done in a more elegant way. However, I do not understand your
intention.
> #ifdef __cplusplus
> extern "C" {
> #endif
> @@ -78,6 +87,42 @@ vqtbl1q_u8(uint8x16_t a, uint8x16_t b)
> }
> #endif
>
> +#if (GCC_VERSION < 7)
Is this code is gcc-specific? In such case there should be check for
GCC compiler. We can also build e.g. by clang.
> +/*
> + * NEON intrinsic vreinterpretq_u64_p128() is not supported
> + * in GCC versions < 7
> + */
I'd be positive about those comments, like:
NEON intrinsic vreinterpretq_u64_p128() is supported since GCC 7.
> +static inline uint64x2_t
> +vreinterpretq_u64_p128(poly128_t x)
> +{
> + return (uint64x2_t)x;
> +}
> +
> +/*
> + * NEON intrinsic vreinterpretq_p64_u64() is not supported
> + * in GCC versions < 7
> + */
> +static inline poly64x2_t
> +vreinterpretq_p64_u64(uint64x2_t x)
> +{
> + return (poly64x2_t)x;
> +}
> +
> +/*
> + * NEON intrinsic vgetq_lane_p64() is not supported
> + * in GCC versions < 7
> + */
> +static inline poly64_t
> +vgetq_lane_p64(poly64x2_t x, const int lane)
> +{
> + assert(lane >= 0 && lane <= 1);
> +
> + poly64_t *p = (poly64_t *)&x;
> +
> + return p[lane];
> +}
> +#endif
> +
> #ifdef __cplusplus
> }
> #endif
> diff --git a/lib/librte_net/net_crc_neon.h b/lib/librte_net/net_crc_neon.h
[...]
> # CPU_LDFLAGS =
> # CPU_ASFLAGS =
>
> -MACHINE_CFLAGS += -march=armv8-a+crc
> +MACHINE_CFLAGS += -march=armv8-a+crc+crypto
> diff --git a/mk/machine/thunderx/rte.vars.mk b/mk/machine/thunderx/rte.vars.mk
> index ad5a379..6784105 100644
> --- a/mk/machine/thunderx/rte.vars.mk
> +++ b/mk/machine/thunderx/rte.vars.mk
> @@ -55,4 +55,4 @@
> # CPU_LDFLAGS =
> # CPU_ASFLAGS =
>
> -MACHINE_CFLAGS += -march=armv8-a+crc -mcpu=thunderx
> +MACHINE_CFLAGS += -march=armv8-a+crc+crypto -mcpu=thunderx
> diff --git a/mk/rte.cpuflags.mk b/mk/rte.cpuflags.mk
> index e634abc..6bbd742 100644
> --- a/mk/rte.cpuflags.mk
> +++ b/mk/rte.cpuflags.mk
> @@ -119,6 +119,9 @@ ifneq ($(filter $(AUTO_CPUFLAGS),__ARM_FEATURE_CRC32),)
> CPUFLAGS += CRC32
> endif
>
> +ifneq ($(filter $(AUTO_CPUFLAGS),__ARM_FEATURE_CRYPTO),)
> +CPUFLAGS += PMULL
> +endif
>
> MACHINE_CFLAGS += $(addprefix -DRTE_MACHINE_CPUFLAG_,$(CPUFLAGS))
>
> diff --git a/mk/toolchain/gcc/rte.toolchain-compat.mk
> b/mk/toolchain/gcc/rte.toolchain-compat.mk
> index 280dde2..01ac7e2 100644
> --- a/mk/toolchain/gcc/rte.toolchain-compat.mk
> +++ b/mk/toolchain/gcc/rte.toolchain-compat.mk
> @@ -60,6 +60,7 @@ else
> #
> ifeq ($(shell test $(GCC_VERSION) -le 49 && echo 1), 1)
> MACHINE_CFLAGS := $(patsubst
>
Re: [dpdk-dev] [PATCH 1/2] net: add arm64 neon version of CRC compute APIs
On Fri, 28 Apr 2017 10:19:20 +
"Sekhar, Ashwin" wrote:
> Hi Jan,
> Thanks for the comments. Please see my responses inline.
>
> On Friday 28 April 2017 03:25 PM, Jan Viktorin wrote:
> > Hello Ashwin Sekhar,
> >
> > some comments below...
> >
[...]
> >>
> >> #include
> >> +#include
> >> +
I'd prefer RTE_ASSERT (rte_debug.h) instead of this one.
> >> #include "generic/rte_vect.h"
> >> #include "arm_neon.h"
> >>
> >> +#ifdef GCC_VERSION
> >> +#undef GCC_VERSION
> >> +#endif
> >
> > Why are you doing this? What is wrong with GCC_VERSION?
> >
> This is just to avoid multiple definitions of GCC_VERSION. Not required
> really. Can be removed.
>
> >> +
> >> +#define GCC_VERSION (__GNUC__ * 1 + __GNUC_MINOR__ * 100 \
> >> + + __GNUC_PATCHLEVEL__)
> >> +
> >
> > If you have any specific requirements for testing GCC version then it
> > should be done in a more elegant way. However, I do not understand your
> > intention.
> >
> GCC version is checked so as to define wrappers for some neon intrinsics
> which are not available in GCC versions < 7.
>
> Similar checks of GCC_VERSION done in ./lib/librte_table/rte_lru.h.
> Followed the same template here.
> Also, this is the suggested approach by GCC. Please see below link.
> https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html
This is OK, I understand.
>
> Please advise on more elegant ways of gcc version detection.
I don't say that it is wrong. Just, it is quite a low-level definition
that might be solved once for all to avoid any further GCC_VERSION
definitions.
At least, I would go this way:
#ifdef __GNUC__
#define GCC_VERSION (__GNUC__ * 1 + __GNUC_MINOR__ * 100 +
__GNUC_PATCHLEVEL__)
#else
#define GCC_VERSION 0
#endif
To be better, this should be defined in some more general file
(rte_common.h, rte_compiler.h)? I don't have any strong opinion about
this. The rte_lru.h can be refactorized in the same way.
> >> #ifdef __cplusplus
> >> extern "C" {
> >> #endif
> >> @@ -78,6 +87,42 @@ vqtbl1q_u8(uint8x16_t a, uint8x16_t b)
> >> }
> >> #endif
> >>
> >> +#if (GCC_VERSION < 7)
> >
[...]
> >
> >> # CPU_LDFLAGS =
> >> # CPU_ASFLAGS =
> >>
> >> -MACHINE_CFLAGS += -march=armv8-a+crc
> >> +MACHINE_CFLAGS += -march=armv8-a+crc+crypto
> >> diff --git a/mk/machine/thunderx/rte.vars.mk
> >> b/mk/machine/thunderx/rte.vars.mk
> >> index ad5a379..6784105 100644
> >> --- a/mk/machine/thunderx/rte.vars.mk
> >> +++ b/mk/machine/thunderx/rte.vars.mk
> >> @@ -55,4 +55,4 @@
> >> # CPU_LDFLAGS =
> >> # CPU_ASFLAGS =
> >>
> >> -MACHINE_CFLAGS += -march=armv8-a+crc -mcpu=thunderx
> >> +MACHINE_CFLAGS += -march=armv8-a+crc+crypto -mcpu=thunderx
> >> diff --git a/mk/rte.cpuflags.mk b/mk/rte.cpuflags.mk
> >> index e634abc..6bbd742 100644
> >> --- a/mk/rte.cpuflags.mk
> >> +++ b/mk/rte.cpuflags.mk
> >> @@ -119,6 +119,9 @@ ifneq ($(filter $(AUTO_CPUFLAGS),__ARM_FEATURE_CRC32),)
> >> CPUFLAGS += CRC32
> >> endif
> >>
> >> +ifneq ($(filter $(AUTO_CPUFLAGS),__ARM_FEATURE_CRYPTO),)
> >> +CPUFLAGS += PMULL
> >> +endif
> >>
> >> MACHINE_CFLAGS += $(addprefix -DRTE_MACHINE_CPUFLAG_,$(CPUFLAGS))
> >>
> >> diff --git a/mk/toolchain/gcc/rte.toolchain-compat.mk
> >> b/mk/toolchain/gcc/rte.toolchain-compat.mk
> >> index 280dde2..01ac7e2 100644
> >> --- a/mk/toolchain/gcc/rte.toolchain-compat.mk
> >> +++ b/mk/toolchain/gcc/rte.toolchain-compat.mk
> >> @@ -60,6 +60,7 @@ else
> >> #
> >>ifeq ($(shell test $(GCC_VERSION) -le 49 && echo 1), 1)
> >>MACHINE_CFLAGS := $(patsubst
> >> -march=armv8-a+crc,-march=armv8-a+crc
> >> -D__ARM_FEATURE_CRC32=1,$(MACHINE_CFLAGS))
> >
> > The line above is to be dropped, isn't it?
> >
> No. It is not to be dropped. For targets like xgene1, crypto is not
> defined. Above line is required for the substitution to happen in such
> targets.
Yes, I understand...
> >> + MACHINE_CFLAGS := $(patsubst
> >> -march=armv8-a+crc+crypto,-march=armv8-a+crc+crypto
> >> -D__ARM_FEATURE_CRC32=1,$(MACHINE_CFLAGS))
> >
> > Please, split the "feature-detection" changes into a separate commit and
> > explain it. In the code, you test for GCC 7. Here you are ok with GCC
> > 4.9. It's likely to be correct but it is not clear.
> Sure. Will split the feature detection changes to separate commit.
> >
> > Also, please explain why is the "crypto" feature required.
> crypto feature is required for using the vmull_p64 intrinsic. More
> specifically the PMULL instruction.
> Will add this as part of the commit message.
OK.
Jan
> >
> > Regards
> > Jan
> >
> >>endif
> >>ifeq ($(shell test $(GCC_VERSION) -le 47 && echo 1), 1)
> >>MACHINE_CFLAGS := $(patsubst
> >> -march=core-avx-i,-march=corei7-avx,$(MACHINE_CFLAGS))
> >
> Thanks and Regards,
> Ashwin
>
--
Jan Viktorin E-mail: vikto...@rehivetech.com
System Architect Web:www.RehiveTech.com
RehiveTech
Brno, Czech Republic
Re: [dpdk-dev] [PATCH v3 1/4] mk: add crypto capability for generic armv8a and thunderx
On Wed, 3 May 2017 23:56:59 -0700 Ashwin Sekhar T K wrote: > armv8-a has optional CRYPTO extension which adds the > AES, PMULL, SHA1 and SHA2 capabilities. -march=armv8-a+crypto > enables code generation for the ARMv8-A architecture together > with the optional CRYPTO extensions. > > added the following flags to detect the corresponding > capability at compile time > * RTE_MACHINE_CPUFLAG_AES > * RTE_MACHINE_CPUFLAG_PMULL > * RTE_MACHINE_CPUFLAG_SHA1 > * RTE_MACHINE_CPUFLAG_SHA2 > > at run-time, the following flags can be used to detect these > capabilities > * RTE_CPUFLAG_AES > * RTE_CPUFLAG_PMULL > * RTE_CPUFLAG_SHA1 > * RTE_CPUFLAG_SHA2 > > Signed-off-by: Ashwin Sekhar T K Reviewed-by: Jan Viktorin
Re: [dpdk-dev] [PATCH v3 2/4] eal: move gcc version definition to common header
On Wed, 3 May 2017 23:57:00 -0700 Ashwin Sekhar T K wrote: > moved the definition of GCC_VERSION from lib/librte_table/rte_lru.h s/moved/Moved/ > to lib/librte_eal/common/include/rte_common.h dot after the sentence > > Tested compilation on arm64 with gcc > > Tested compilation on x86 with gcc and clang Tested compilation on: * arm64 with gcc * x86 with gcc and clang > > Signed-off-by: Ashwin Sekhar T K Reviewed-by: Jan Viktorin
Re: [dpdk-dev] Issue->Dpdk for arm cortex-a15 compilation
Hello Jimmy, On Tue, 16 May 2017 15:38:22 +0530 Jimmy Carter wrote: > Hi All > > I am using dpdk16.11.1 and want to use openwrt external toolchain so that I > can cross compile for arm cortex 15 > neon.(arm_cortex-a15+neon-vfpv4_gcc-5.4.0_musl_eabi) I've never built DPDK with musl-eabi. I don't think that your issue is related but just note that my builds have always been done with gnueabi. > My target board is Tp link archer C2600. > I am have assigned these env variables but still getting compilation error > > export > STAGING_DIR=/home/xav-101000739/ovslede/source/staging_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-5.4.0_musl_eabi > export > PATH=$PATH:/home/xav-101000739/ovslede/source/staging_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-5.4.0_musl_eabi/bin > > > export CROSS=arm-openwrt-linux- > export DPDK_TARGET=arm-armv7a-linuxapp-gcc > export DPDK_DIR=$PWD > export DPDK_BUILD=$DPDK_DIR/$DPDK_TARGET > export > CFLAGS+=-I/home/xav-101000739/ovslede/source/staging_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-5.4.0_musl_eabi > export RTE_SDK=$PWD > export RTE_TARGET=arm-armv7a-linuxapp-gcc > export DPDK_BUILD_DIR=arm-armv7a-linuxapp-gcc > There is a patch to Buildroot that can help you with the setup. See: https://patchwork.ozlabs.org/patch/611383/ > > Error:Attached file Your build fails on eal_memory.c:92: /home/xav-101000739/Downloads/dpdk/dpdk-stable-16.11.1/build/include/rte_lcore.h:56:10: error: unknown type name 'cpu_set_t' typedef cpu_set_t rte_cpuset_t; This looks like there is some issue with Linux Kernel headers. lib/librte_eal/common/include/rte_lcore.h: 53 #if defined(__linux__) 54 typedef cpu_set_t rte_cpuset_t; 55 #elif defined(__FreeBSD__) 56 #include 57 typedef cpuset_t rte_cpuset_t; 58 #endif Probably, you should set the RTE_KERNELDIR properly. > > Please advise > Does dpdk have support for openwrt (arm cortex a15) DPDK does not support OpenWRT because (as far as I know) nobody from the DPDK community is using it in this way. I build DPDK via Buildroot but this is unsupported by the DPDK upstream. I could build DPDK for Cortex-A7, Cortex-A9 and Cortex-A15 in the past. I run regular builds of the master branch and I can see no breakage for the arm-armv7a-linuxapp-gcc configuration. Regards Jan > > Thanks > Akshay
Re: [dpdk-dev] [dpdk-maintainers] Issue->Dpdk for arm cortex-a15 compilation
On Tue, 16 May 2017 13:22:19 +0200 Thomas Monjalon wrote: > 16/05/2017 12:51, Jan Viktorin: > > DPDK does not support OpenWRT because (as far as I know) nobody from > > the DPDK community is using it in this way. I build DPDK via Buildroot > > but this is unsupported by the DPDK upstream. > > Why means "unsupported upstream"? Are we missing some patches? I mean that DPDK does not contain anything related to Buildroot in its repositories and it is not related to it in any way... It does not mean whether it does or does not work. And also, I've never finished my Builroot integration into the Buildroot upstream. > Should we integrate Buildroot compilation in our CI? Well, I do it. If the support is upstreamed into the Buildroot master, I'd say yes, It would be a good idea to include it in the DPDK CI. This is about having somebody to do it... Regards Jan -- Jan Viktorin E-mail: vikto...@rehivetech.com System Architect Web:www.RehiveTech.com RehiveTech Brno, Czech Republic
Re: [dpdk-dev] Issue->Dpdk for arm cortex-a15 compilation
On Tue, 16 May 2017 07:44:59 -0400 Neil Horman wrote: > On Tue, May 16, 2017 at 12:51:40PM +0200, Jan Viktorin wrote: > > Hello Jimmy, > > > > On Tue, 16 May 2017 15:38:22 +0530 > > Jimmy Carter wrote: > > > > > Hi All > > > > > > I am using dpdk16.11.1 and want to use openwrt external toolchain so that > > > I > > > can cross compile for arm cortex 15 > > > neon.(arm_cortex-a15+neon-vfpv4_gcc-5.4.0_musl_eabi) > > > > I've never built DPDK with musl-eabi. I don't think that your issue is > > related but just note that my builds have always been done with gnueabi. > > > > > My target board is Tp link archer C2600. > > > I am have assigned these env variables but still getting compilation error > > > > > > export > > > STAGING_DIR=/home/xav-101000739/ovslede/source/staging_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-5.4.0_musl_eabi > > > export > > > PATH=$PATH:/home/xav-101000739/ovslede/source/staging_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-5.4.0_musl_eabi/bin > > > > > > > > > export CROSS=arm-openwrt-linux- > > > export DPDK_TARGET=arm-armv7a-linuxapp-gcc > > > export DPDK_DIR=$PWD > > > export DPDK_BUILD=$DPDK_DIR/$DPDK_TARGET > > > export > > > CFLAGS+=-I/home/xav-101000739/ovslede/source/staging_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-5.4.0_musl_eabi > > > export RTE_SDK=$PWD > > > export RTE_TARGET=arm-armv7a-linuxapp-gcc > > > export DPDK_BUILD_DIR=arm-armv7a-linuxapp-gcc > > > > > > > There is a patch to Buildroot that can help you with the setup. See: > > > > https://patchwork.ozlabs.org/patch/611383/ > > > > > > > > Error:Attached file > > > > Your build fails on > > > > eal_memory.c:92: > > /home/xav-101000739/Downloads/dpdk/dpdk-stable-16.11.1/build/include/rte_lcore.h:56:10: > > error: unknown type name 'cpu_set_t' > > typedef cpu_set_t rte_cpuset_t; > > > > This looks like there is some issue with Linux Kernel headers. > > > > lib/librte_eal/common/include/rte_lcore.h: > > > > 53 #if defined(__linux__) > > 54 typedef cpu_set_t rte_cpuset_t; > > 55 #elif defined(__FreeBSD__) > > 56 #include > > 57 typedef cpuset_t rte_cpuset_t; > > 58 #endif > > > > Probably, you should set the RTE_KERNELDIR properly. > > > I don't think so. cpu_set_t is most recently defined in > /usr/include/bits/shced.h, which is a glibc header. What version of glibc are > you building with? So, in that case, it can be related to the musl libc (no glibc at all) as I pointed above... Jan > > Neil > > > > > > > Please advise > > > Does dpdk have support for openwrt (arm cortex a15) > > > > DPDK does not support OpenWRT because (as far as I know) nobody from > > the DPDK community is using it in this way. I build DPDK via Buildroot > > but this is unsupported by the DPDK upstream. > > > > I could build DPDK for Cortex-A7, Cortex-A9 and Cortex-A15 in the past. > > > > I run regular builds of the master branch and I can see no breakage > > for the arm-armv7a-linuxapp-gcc configuration. > > > > Regards > > Jan > > > > > > > > Thanks > > > Akshay > > -- Jan Viktorin E-mail: vikto...@rehivetech.com System Architect Web:www.RehiveTech.com RehiveTech Brno, Czech Republic
Re: [dpdk-dev] Issue->Dpdk for arm cortex-a15 compilation
On Tue, 16 May 2017 17:25:20 +0530 Jimmy Carter wrote: > Hi All > > Attached is the complete env variables file > I have added RTE_KERNELDIR too > Also I am now using gnu-eabi version 5.4.0 > [arm-openwrt-linux-muslgnueabi-gcc (LEDE GCC 5.4.0 r3909-6411a12) 5.4.0] > But I am still getting the same error > > Currently I am not using buildroot > Is there any step by step available guide for cross compiling dpdk using > buildroot for target arm cortex-a15 using some external toolchain. > I found this http://dpdk.org/ml/archives/announce/2015-October/66.html This short tutorial points to some older version of the Buildroot support. That was before the ARM support has been merged into DPDK. I've just pushed the branch dpdk-support-v5 (d25ddaadf2) into the RehiveTech repository. It contains the latest patch sent to the Buildroot mailing list [1] and some more. By the way, it cleanly applies to the latest Buildroot master as well. This branch assumes DPDK 16.04 which is quite old but if you drop the 0001-mk-do-not-enforce-any-specific-ARM-ABI.patch, it might work for newer DPDK as well. Steps: $ git clone https://github.com/RehiveTech/buildroot $ cd buildroot $ make qemu_arm_vexpress_defconfig $ make menuconfig * set libc library to glibc * enable DPDK in Target packages/Libraries/Networking/DPDK $ make linux-menuconfig * enable UIO, PCI and MSI-X (if applicable) $ make I didn't test it myself recently but I belive that it should work well. Instead of qemu_arm_vexpress_defconfig, you should select your target board, if applicable. I hope, it would help you. Regards Jan [1] https://patchwork.ozlabs.org/patch/611383/ > > > Please advise > > > > Thanks > > On Tue, May 16, 2017 at 5:14 PM, Neil Horman wrote: > > > On Tue, May 16, 2017 at 12:51:40PM +0200, Jan Viktorin wrote: > > > Hello Jimmy, > > > > > > On Tue, 16 May 2017 15:38:22 +0530 > > > Jimmy Carter wrote: > > > > > > > Hi All > > > > > > > > I am using dpdk16.11.1 and want to use openwrt external toolchain so > > that I > > > > can cross compile for arm cortex 15 > > > > neon.(arm_cortex-a15+neon-vfpv4_gcc-5.4.0_musl_eabi) > > > > > > I've never built DPDK with musl-eabi. I don't think that your issue is > > > related but just note that my builds have always been done with gnueabi. > > > > > > > My target board is Tp link archer C2600. > > > > I am have assigned these env variables but still getting compilation > > error > > > > > > > > export > > > > STAGING_DIR=/home/xav-101000739/ovslede/source/ > > staging_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-5.4.0_musl_eabi > > > > export > > > > PATH=$PATH:/home/xav-101000739/ovslede/source/ > > staging_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-5.4.0_musl_eabi/bin > > > > > > > > > > > > export CROSS=arm-openwrt-linux- > > > > export DPDK_TARGET=arm-armv7a-linuxapp-gcc > > > > export DPDK_DIR=$PWD > > > > export DPDK_BUILD=$DPDK_DIR/$DPDK_TARGET > > > > export > > > > CFLAGS+=-I/home/xav-101000739/ovslede/source/staging_dir/ > > toolchain-arm_cortex-a15+neon-vfpv4_gcc-5.4.0_musl_eabi > > > > export RTE_SDK=$PWD > > > > export RTE_TARGET=arm-armv7a-linuxapp-gcc > > > > export DPDK_BUILD_DIR=arm-armv7a-linuxapp-gcc > > > > > > > > > > There is a patch to Buildroot that can help you with the setup. See: > > > > > > https://patchwork.ozlabs.org/patch/611383/ > > > > > > > > > > > Error:Attached file > > > > > > Your build fails on > > > > > > eal_memory.c:92: > > > /home/xav-101000739/Downloads/dpdk/dpdk-stable-16.11.1/ > > build/include/rte_lcore.h:56:10: error: unknown type name 'cpu_set_t' > > > typedef cpu_set_t rte_cpuset_t; > > > > > > This looks like there is some issue with Linux Kernel headers. > > > > > > lib/librte_eal/common/include/rte_lcore.h: > > > > > > 53 #if defined(__linux__) > > > 54 typedef cpu_set_t rte_cpuset_t; > > > 55 #elif defined(__FreeBSD__) > > > 56 #include > > > 57 typedef cpuset_t rte_cpuset_t; > > > 58 #endif > > > > > > Probably, you should set the RTE_KERNELDIR properly. > > > > > I don't think so. cpu_set_t is most recently defined in > > /usr/include/bits/shced.h, which is a glibc header. What version of gl
Re: [dpdk-dev] Issue->Dpdk for arm cortex-a15 compilation
On Tue, 16 May 2017 18:57:41 +0530 Jimmy Carter wrote: > I assume after git clone https://github.com/RehiveTech/buildroot > I need to git checkout dpdk-support-v5 Yes, I forgot to mention... > I get legacy error on running make > root@xav101000739:~/Downloads/dpdk/newbuildroot/buildroot# *make * > *Makefile.legacy:12: *** "You have legacy configuration in your .config! > Please check your configuration.". Stop.* This is very strange. Did you use qemu_arm_vexpress_defconfig or some other? I didn't have any issue during the build except of a mismatch in the SHA256 checksum of the dpdk-16.04.tar.gz which is strange. After fixing: diff --git a/package/dpdk/dpdk.hash b/package/dpdk/dpdk.hash index 3780c665b..c0158e477 100644 --- a/package/dpdk/dpdk.hash +++ b/package/dpdk/dpdk.hash @@ -1,2 +1,2 @@ # Locally calculated -sha256 d631495bc6e8d4c4aec72999ac03c3ce213bb996cb88f3bf14bb980dad1d3f7b dpdk-16.04.tar.gz +sha256 f917875b1432adaaebb2761c154623bb101e0308153aa011f06a69bd1e9e98fb dpdk-16.04.tar.gz it works. $ ls output/images/ rootfs.ext2 vexpress-v2p-ca9.dtb zImage Regards Jan > > > Thanks > > On Tue, May 16, 2017 at 5:58 PM, Jan Viktorin > wrote: > > > On Tue, 16 May 2017 17:25:20 +0530 > > Jimmy Carter wrote: > > > > > Hi All > > > > > > Attached is the complete env variables file > > > I have added RTE_KERNELDIR too > > > Also I am now using gnu-eabi version 5.4.0 > > > [arm-openwrt-linux-muslgnueabi-gcc (LEDE GCC 5.4.0 r3909-6411a12) 5.4.0] > > > But I am still getting the same error > > > > > > Currently I am not using buildroot > > > Is there any step by step available guide for cross compiling dpdk using > > > buildroot for target arm cortex-a15 using some external toolchain. > > > I found this http://dpdk.org/ml/archives/announce/2015-October/66. > > html > > > > This short tutorial points to some older version of the Buildroot > > support. That was before the ARM support has been merged into DPDK. > > > > I've just pushed the branch dpdk-support-v5 (d25ddaadf2) into > > the RehiveTech repository. It contains the latest patch sent to the > > Buildroot mailing list [1] and some more. By the way, it cleanly > > applies to the latest Buildroot master as well. > > > > This branch assumes DPDK 16.04 which is quite old but if you drop the > > 0001-mk-do-not-enforce-any-specific-ARM-ABI.patch, it might work for newer > > DPDK as well. > > > > Steps: > > > > $ git clone https://github.com/RehiveTech/buildroot > > $ cd buildroot > > $ make qemu_arm_vexpress_defconfig > > $ make menuconfig > > > > * set libc library to glibc > > * enable DPDK in Target packages/Libraries/Networking/DPDK > > > > $ make linux-menuconfig > > > > * enable UIO, PCI and MSI-X (if applicable) > > > > $ make > > > > I didn't test it myself recently but I belive that it should work well. > > Instead of qemu_arm_vexpress_defconfig, you should select your target > > board, if applicable. > > > > I hope, it would help you. > > > > Regards > > Jan > > > > [1] https://patchwork.ozlabs.org/patch/611383/ > > > > > > > > > > > Please advise > > > > > > > > > > > > Thanks > > > > > > On Tue, May 16, 2017 at 5:14 PM, Neil Horman > > wrote: > > > > > > > On Tue, May 16, 2017 at 12:51:40PM +0200, Jan Viktorin wrote: > > > > > Hello Jimmy, > > > > > > > > > > On Tue, 16 May 2017 15:38:22 +0530 > > > > > Jimmy Carter wrote: > > > > > > > > > > > Hi All > > > > > > > > > > > > I am using dpdk16.11.1 and want to use openwrt external toolchain > > so > > > > that I > > > > > > can cross compile for arm cortex 15 > > > > > > neon.(arm_cortex-a15+neon-vfpv4_gcc-5.4.0_musl_eabi) > > > > > > > > > > I've never built DPDK with musl-eabi. I don't think that your issue > > is > > > > > related but just note that my builds have always been done with > > gnueabi. > > > > > > > > > > > My target board is Tp link archer C2600. > > > > > > I am have assigned these env variables but still getting > > compilation > > > > error > > > > > > > > > > > > export > > > > > > STAGING_DIR=/home/x
Re: [dpdk-dev] [PATCH 2/6] eal/arm32: rte pause implementation for arm32
On Thu, 11 May 2017 15:40:42 +0530 Jerin Jacob wrote: > The patch does not provide any functional change for ARM32 > with respect to existing rte_pause() definition. > > CC: Jan Viktorin > CC: Jianbo Liu > Signed-off-by: Jerin Jacob Acked-by: Jan Viktorin
[dpdk-dev] [PATCH 1/4] eal/arm: use RTE_ARM_EAL_RDTSC_USE_PMU in rte_cycle_32.h
Hello Jianbo,
thank you for this fix. I had the feeling this works the same like in the Linux
Kernel where the CONFIG_ prefix is be used. My bad. I recommend to make
this patch separate. I can't see any relation to the rest of the series.
Regards
Jan
On Tue, 1 Dec 2015 13:41:13 -0500
Jianbo Liu wrote:
> CONFIG_* from config files can not be used in code.
>
> Signed-off-by: Jianbo Liu
> ---
> lib/librte_eal/common/include/arch/arm/rte_cycles_32.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/librte_eal/common/include/arch/arm/rte_cycles_32.h
> b/lib/librte_eal/common/include/arch/arm/rte_cycles_32.h
> index 6c6098e..9c1be71 100644
> --- a/lib/librte_eal/common/include/arch/arm/rte_cycles_32.h
> +++ b/lib/librte_eal/common/include/arch/arm/rte_cycles_32.h
> @@ -54,7 +54,7 @@ extern "C" {
> * @return
> * The time base for this lcore.
> */
> -#ifndef CONFIG_RTE_ARM_EAL_RDTSC_USE_PMU
> +#ifndef RTE_ARM_EAL_RDTSC_USE_PMU
>
> /**
> * This call is easily portable to any ARM architecture, however,
--
Jan Viktorin E-mail: Viktorin at RehiveTech.com
System Architect Web:www.RehiveTech.com
RehiveTech
Brno, Czech Republic
[dpdk-dev] [PATCH 1/4] eal/arm: use RTE_ARM_EAL_RDTSC_USE_PMU in rte_cycle_32.h
On Tue, 1 Dec 2015 13:41:13 -0500 Jianbo Liu wrote: > CONFIG_* from config files can not be used in code. > > Signed-off-by: Jianbo Liu > --- Acked-by: Jan Viktorin -- Jan Viktorin E-mail: Viktorin at RehiveTech.com System Architect Web:www.RehiveTech.com RehiveTech Brno, Czech Republic
[dpdk-dev] [PATCH 0/4] support acl/lpm/table/pipeline libs for armv7 and armv8
On Tue, 1 Dec 2015 13:41:12 -0500 Jianbo Liu wrote: > Hi, > I'm from Linaro.org, and will work on DPDK to make it better > runing on different ARM Platforms. > > This patchset includes a small fix in rte_cycle_32.h, > and enables acl/lpm/table/pipeline libs for armv7 and armv8. > Please apply it after [PATCH v4 0/2] disable CONFIG_RTE_SCHED_VECTOR for arm. Would it avoid some merge conflicts or is there some other dependency? Jan > > Thanks! > Jianbo > > > Jianbo Liu (4): > eal/arm: use RTE_ARM_EAL_RDTSC_USE_PMU in rte_cycle_32.h > eal/acl: enable acl for armv7-a > eal/arm: Enable lpm/table/pipeline libs > maintainers: claim resposibility for ARMv7 and ARMv8 > > MAINTAINERS| 2 + > config/defconfig_arm-armv7a-linuxapp-gcc | 4 -- > config/defconfig_arm64-armv8a-linuxapp-gcc | 3 - > lib/librte_acl/Makefile| 2 +- > lib/librte_acl/rte_acl.c | 2 +- > .../common/include/arch/arm/rte_cycles_32.h| 2 +- > lib/librte_eal/common/include/arch/arm/rte_vect.h | 51 > lib/librte_lpm/rte_lpm.h | 68 > ++++++++-- > 8 files changed, 105 insertions(+), 29 deletions(-) > -- Jan Viktorin E-mail: Viktorin at RehiveTech.com System Architect Web:www.RehiveTech.com RehiveTech Brno, Czech Republic
[dpdk-dev] [PATCH 2/4] eal/acl: enable acl for armv7-a
On Tue, 1 Dec 2015 20:13:49 +0530 Jerin Jacob wrote: > > enum rte_acl_classify_alg alg = RTE_ACL_CLASSIFY_DEFAULT; > > > > -#ifdef RTE_ARCH_ARM64 > > +#if defined(RTE_ARCH_ARM) || defined(RTE_ARCH_ARM64) > > alg = RTE_ACL_CLASSIFY_NEON; > > I believe SIMD is optional in armv7. If true, select alg as > RTE_ACL_CLASSIFY_NEON only when cpufeature NEON enabled. Yes. Or, probably, we can be happy with #if defined(__ARM_NEON_FP) ... #endif as it is currently done in rte_memcpy_32.h. Regards Jan
[dpdk-dev] [PATCH 3/4] eal/arm: Enable lpm/table/pipeline libs
On Tue, 1 Dec 2015 22:11:42 +0530 Jerin Jacob wrote: > On Tue, Dec 01, 2015 at 01:41:15PM -0500, Jianbo Liu wrote: > > Adds ARM NEON support for lpm. > > And enables table/pipeline libraries which depend on lpm. > > I already sent the patch on the same yesterday. > We can converge the patches after the discussion. > Please check "[dpdk-dev] [PATCH 0/3] add lpm support for NEON" on ml I've missed that too. Did you CC me? Jan -- Jan Viktorin E-mail: Viktorin at RehiveTech.com System Architect Web:www.RehiveTech.com RehiveTech Brno, Czech Republic
[dpdk-dev] [PATCH 3/4] eal/arm: Enable lpm/table/pipeline libs
On Wed, 2 Dec 2015 16:09:06 +0530 Jerin Jacob wrote: > > > [snip] > > > IMO, it's not always good to emulate GCC defined intrinsics of > > > other architecture. What if a legacy DPDK application has such mappings > > > then BOOM, multiple definition, which one is correct? which one > > > to comment it out? Integration pain starts for DPDK library consumer:-( > > > > > They can include rte_vect.h in build/include directly, which is linked > > correctly > > to the one for that ARCH, so there is no need to worry about. > > I think you missed the point,I was trying to say that > legacy DPDK application and third party stacks uses SSE2NEON kind of > libraries > for quick integration, for example, something like this > https://github.com/jratcliff63367/sse2neon/blob/master/SSE2NEON.h > > AND they include "rte_lpm.h"(it internally includes rte_vect.h) > that lead to multiple definition and its not good. > > > > > > > >> > > > >> > IMO, it makes sense to not emulate the SSE intrinsics with NEON > > >> > Let's create the rte_vect_* as required. look at the existing patch. > > >> > > > >> I thought of creating a layer of SIMD over all the platforms before. > > >> But can't you see it make things complicated, considering there are > > >> only few simple intrinsic to implement? > > > > > > Not true, There were, a lot of SSE intrinsics needs be to emulated for > > > ACL NEON > > > implementation if I were to take this approach and emulation comes with > > > the cost. > > > > > No, I will not re-implement all the intrinsic like that . > > I only do with the simple intrinsic, such as load/store, as you said below. > > > > but you forced to add _mm_and_si128 also to the list and emulated > _mm_and_si128 intrinsic. Am just saying no emulation. > Guys, do we want emulate x86 on ARM? I hope we don't ;). I think, as more platforms might come into DPDK, there will be a need for a proper abstract vector operations API. Yes, we have to describe this API to people. However, otherwise, the ARM guys must learn SSE and write for ARM platform something that looks quite odd. And if there are some "neon emulations" as shown above, it's definitely an argue to have the API that can hide those approachs. Regards Jan
[dpdk-dev] [PATCH 3/4] eal/arm: Enable lpm/table/pipeline libs
On Wed, 2 Dec 2015 16:18:13 +0530 Jerin Jacob wrote: > > > [snip] > > > > My preference would also be to put architecture dependent implementation > > into different files. > > Might be create lib/librte_lpm/arch/(arm|x86)/... here? > > Konstantin > > +1 > > my existing patch creates lib/librte_lpm/rte_lpm_neon.h instead > of lib/librte_lpm/arch/arm/rte_lpm_neon.h like > lib/librte_hash/rte_cmp_x86.h > > I am OK for changing the directory structure as proposed in my next revision > of patch. > Let me know if anyone has any objections/concerns. > > Jerin I don't like the idea to have arch/... directory structure inside libraries. I would delay such decision until there are really a big number of different optimized implementations. However, the rte_lpm_neon.h approach is OK from my point of view. Jan > > [snip]
[dpdk-dev] [PATCH 0/3] add lpm support for NEON
Hello Jerin, thank you for this patch series. Please CC me next time when doing an ARM-related changes. It took me a while to find the related e-mails on the mail server. On Mon, 30 Nov 2015 22:54:10 +0530 Jerin Jacob wrote: > - Introduce new rte_vect_* abstractions in eal > - This patch set has the changes required for optimised pm library usage in > arm64 perspective > - Tested on Juno and Thunder boards > - Tested and verified the changes with following DPDK unit test cases > --lpm_autotest > --lpm6_autotest > - This patch set has dependency on [dpdk-dev] [PATCH v4 0/2] disable > CONFIG_RTE_SCHED_VECTOR for arm What kind of dependency is it? Functional? > - With these changes, arm64 platform supports all DPDK libraries(in feature > wise) Is there some ARMv8 specific NEON instruction? > > Jerin Jacob (3): > eal: introduce rte_vect_* abstractions > lpm: add support for NEON > maintainers: claim responsibility for arm64 specific files of hash and > lpm > > MAINTAINERS | 3 + > app/test/test_lpm.c | 10 +- > config/defconfig_arm64-armv8a-linuxapp-gcc| 3 - > lib/librte_eal/common/include/arch/arm/rte_vect.h | 17 ++- > lib/librte_eal/common/include/arch/x86/rte_vect.h | 8 + > lib/librte_lpm/Makefile | 3 + > lib/librte_lpm/rte_lpm.h | 5 + > lib/librte_lpm/rte_lpm_neon.h | 172 > ++ > 8 files changed, 212 insertions(+), 9 deletions(-) > create mode 100644 lib/librte_lpm/rte_lpm_neon.h > > -- > 2.1.0 > -- Jan Viktorin E-mail: Viktorin at RehiveTech.com System Architect Web:www.RehiveTech.com RehiveTech Brno, Czech Republic
[dpdk-dev] [PATCH 1/3] eal: introduce rte_vect_* abstractions
On Mon, 30 Nov 2015 22:54:11 +0530
Jerin Jacob wrote:
> introduce rte_vect_* abstractions to remove SSE/AVX specific
> code in the common code(i.e the test applications)
>
> The patch does not provide any functional change for IA, the goal is to
Does IA mean Intel Architecture?
> have infrastructure to reuse the common vector-based test code across
> all the architectures.
>
> Signed-off-by: Jerin Jacob
> ---
> lib/librte_eal/common/include/arch/arm/rte_vect.h | 17 -
> lib/librte_eal/common/include/arch/x86/rte_vect.h | 8
> 2 files changed, 24 insertions(+), 1 deletion(-)
>
> diff --git a/lib/librte_eal/common/include/arch/arm/rte_vect.h
> b/lib/librte_eal/common/include/arch/arm/rte_vect.h
> index 21cdb4d..d300951 100644
> --- a/lib/librte_eal/common/include/arch/arm/rte_vect.h
> +++ b/lib/librte_eal/common/include/arch/arm/rte_vect.h
> @@ -33,13 +33,14 @@
> #ifndef _RTE_VECT_ARM_H_
> #define _RTE_VECT_ARM_H_
>
> -#include "arm_neon.h"
> +#include
>
> #ifdef __cplusplus
> extern "C" {
> #endif
>
> typedef int32x4_t xmm_t;
> +typedef int32x4_t __m128i;
As Jianbo pointed out recently, the __m128i type should be refactored in
a general rte_vect API too. If we do something like
#if SSE
typedef __m128i rte_128i;
#elif NEON
typedef int32x4_y rte_128i;
#endif
does it make somebody angry? I am afraid that it will influence a lot of
code. However, from the ABI point of view, it is OK, isn't it?
>
> #define XMM_SIZE(sizeof(xmm_t))
> #define XMM_MASK(XMM_SIZE - 1)
> @@ -53,6 +54,20 @@ typedef union rte_xmm {
> double pd[XMM_SIZE / sizeof(double)];
> } __attribute__((aligned(16))) rte_xmm_t;
>
> +/* rte_vect_* abstraction implementation using NEON */
> +
> +/* loads the __m128i value from address p(does not need to be 16-byte
> aligned)*/
> +#define rte_vect_loadu_sil128(p) vld1q_s32((const int32_t *)p)
> +
> +/* sets the 4 signed 32-bit integer values and returns the __m128i variable
> */
> +static inline __m128i __attribute__((always_inline))
> +rte_vect_set_epi32(int i3, int i2, int i1, int i0)
> +{
> + int32_t data[4] = {i0, i1, i2, i3};
> +
> + return vld1q_s32(data);
> +}
> +
> #ifdef __cplusplus
> }
> #endif
> diff --git a/lib/librte_eal/common/include/arch/x86/rte_vect.h
> b/lib/librte_eal/common/include/arch/x86/rte_vect.h
> index b698797..91c6523 100644
> --- a/lib/librte_eal/common/include/arch/x86/rte_vect.h
> +++ b/lib/librte_eal/common/include/arch/x86/rte_vect.h
> @@ -125,6 +125,14 @@ typedef union rte_ymm {
> })
> #endif /* (defined(__ICC) && __ICC < 1210) */
>
> +/* rte_vect_* abstraction implementation using SSE */
> +
> +/* loads the __m128i value from address p(does not need to be 16-byte
> aligned)*/
> +#define rte_vect_loadu_sil128(p) _mm_loadu_si128(p)
> +
> +/* sets the 4 signed 32-bit integer values and returns the __m128i variable
> */
> +#define rte_vect_set_epi32(i3, i2, i1, i0) _mm_set_epi32(i3, i2, i1, i0)
> +
> #ifdef __cplusplus
> }
> #endif
I like this approach. It is a question whether to inherit names from
SSE. However, why to reinvent the wheel...
We probably need other people to give their ideas about such
generalization of the API.
I think, there should be an autotest of the rte_vect API. Is it
possible to create one?
Regards
Jan
--
Jan Viktorin E-mail: Viktorin at RehiveTech.com
System Architect Web:www.RehiveTech.com
RehiveTech
Brno, Czech Republic
[dpdk-dev] [PATCH 2/3] lpm: add support for NEON
On Mon, 30 Nov 2015 22:54:12 +0530 Jerin Jacob wrote: > enabled CONFIG_RTE_LIBRTE_LPM, CONFIG_RTE_LIBRTE_TABLE, > CONFIG_RTE_LIBRTE_PIPELINE libraries for arm64. > > TABLE, PIPELINE libraries were disabled due to LPM library dependency. > > Signed-off-by: Jerin Jacob > --- > app/test/test_lpm.c| 10 +- > config/defconfig_arm64-armv8a-linuxapp-gcc | 3 - > lib/librte_lpm/Makefile| 3 + > lib/librte_lpm/rte_lpm.h | 5 + > lib/librte_lpm/rte_lpm_neon.h | 172 > + > 5 files changed, 185 insertions(+), 8 deletions(-) > create mode 100644 lib/librte_lpm/rte_lpm_neon.h > > [snip] > > # this lib needs eal > DEPDIRS-$(CONFIG_RTE_LIBRTE_LPM) += lib/librte_eal > diff --git a/lib/librte_lpm/rte_lpm.h b/lib/librte_lpm/rte_lpm.h > index c299ce2..12b75ce 100644 > --- a/lib/librte_lpm/rte_lpm.h > +++ b/lib/librte_lpm/rte_lpm.h > @@ -361,6 +361,9 @@ rte_lpm_lookup_bulk_func(const struct rte_lpm *lpm, const > uint32_t * ips, > /* Mask four results. */ > #define RTE_LPM_MASKX4_RES UINT64_C(0x00ff00ff00ff00ff) > > +#if defined(RTE_ARCH_ARM64) > +#include "rte_lpm_neon.h" > +#else > /** > * Lookup four IP addresses in an LPM table. > * > @@ -473,6 +476,8 @@ rte_lpm_lookupx4(const struct rte_lpm *lpm, __m128i ip, > uint16_t hop[4], > hop[3] = (tbl[3] & RTE_LPM_LOOKUP_SUCCESS) ? (uint8_t)tbl[3] : defv; > } > > +#endif > + I would separate the SSE implementation into its own file as well. Otherwise, I like this patch. I hope to be able to test it soon. > [snip] -- Jan Viktorin E-mail: Viktorin at RehiveTech.com System Architect Web:www.RehiveTech.com RehiveTech Brno, Czech Republic
[dpdk-dev] [PATCH 3/3] maintainers: claim responsibility for arm64 specific files of hash and lpm
On Mon, 30 Nov 2015 22:54:13 +0530 Jerin Jacob wrote: > Signed-off-by: Jerin Jacob > --- > MAINTAINERS | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 4478862..dc8f80a 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -130,6 +130,9 @@ ARM v8 > M: Jerin Jacob > F: lib/librte_eal/common/include/arch/arm/*_64.h > F: lib/librte_acl/acl_run_neon.* > +F: lib/librte_lpm/rte_lpm_neon.h > +F: lib/librte_hash/rte_crc_arm64.h > +F: lib/librte_hash/rte_cmp_arm64.h I can't see the librte_hash/* files in the patch set. Is it by mistake? > > EZchip TILE-Gx > M: Zhigang Lu -- Jan Viktorin E-mail: Viktorin at RehiveTech.com System Architect Web:www.RehiveTech.com RehiveTech Brno, Czech Republic
[dpdk-dev] [PATCH 2/3] lpm: add support for NEON
On Wed, 2 Dec 2015 20:26:08 +0530 Jerin Jacob wrote: > > [snip] > > I would separate the SSE implementation into its own file as well. > > make sense. planning to make it as lib/librte_lpm/rte_lpm_sse.h > and lib/librte_lpm/rte_lpm_neon.h. OK ? > > I can fix it in next revision. Yes, please. Jan
[dpdk-dev] [PATCH v2 2/3] eal/acl: enable acl for armv7-a
? P?vodn? zpr?va ? Od: Thomas Monjalon Odesl?no: ?ter?, 8. prosince 2015 11:04 Komu: Jianbo Liu Kopie: dev at dpdk.org; Jan Viktorin; Jerin Jacob P?edm?t: Re: [dpdk-dev] [PATCH v2 2/3] eal/acl: enable acl for armv7-a 2015-12-08 15:56, Jianbo Liu: > On 8 December 2015 at 10:23, Thomas Monjalon > wrote: > > 2015-12-08 09:50, Jianbo Liu: > >> On 8 December 2015 at 09:18, Thomas Monjalon >> 6wind.com> wrote: > >> > 2015-12-03 23:02, Jianbo Liu: > >> >> -ifeq ($(CONFIG_RTE_ARCH_ARM64),y) > >> >> +ifneq ($(filter y,$(CONFIG_RTE_ARCH_ARM) $(CONFIG_RTE_ARCH_ARM64)),) > >> > [...] > >> >> +#ifdef RTE_ARCH_ARM > >> >> +/* NEON intrinsic vqtbl1q_u8() is not supported in ARMv7-A(AArch32) */ > >> > > >> > I'm convinced there is a good reason why ARMv8 is also called ARCH_ARM64, > >> > and ARMv7 may be called AArch32 or ARCH_ARM. But I don't know why? > >> > > >> https://lkml.org/lkml/2012/7/15/133 > >> > >> > Is ARCH_ARM32 or ARCH_ARMv7 too simple? > >> > Is it possible to have a 32-bit ARMv8? > >> Yes, ARMv8-R/M > > > > So what does mean CONFIG_RTE_ARCH_ARM? > > ARMv7? ARM32? > > Please consider a renaming. > > I'd rather not renaming becase it can be both ARMv7 and AARCH32, which > are ISA compatibility. > If further differentiation is needed, CONFIG_RTE_ARCH_ARMv7 is added > in the config, just like Jan Viktorin did. >> I don't understand. >> You say CONFIG_RTE_ARCH_ARM is for ARMv7 and AARCH32, right? >> Both are 32-bit right? >> Why not rename it to CONFIG_RTE_ARCH_ARM32? Hello, CONFIG_RTE_ARCH_ARMv7 entry specifies the certain architecture, subset of CONFIG_RTE_ARCH_ARM (which is 32b). For ARM64 we can differentiate among architectures v8, v9, ..., v64 :) as well. However, I doubt somebody will use dpdk on ARMv6. IMO, the major options should be CONFIG_RTE_ARCH_ARM and CONFIG_RTE_ARCH_ARM64. Jan Viktorin RehiveTech Sent from a mobile device? ?
[dpdk-dev] DPDK Community Call - ARM Support
Hello, I'd like to see the presentation as well. Another point. Last time, I was confused a bit by who is talking as the gotomeeting system doesn't show it always and if it does it hides very quickly. The topic was not very clear sometimes. Could we agree on some rules? Could somebody be a moderator? There is the chat that can be used for this... Finally, some conclusion should be sent into the mailing list. Regards Jan?Viktorin RehiveTech Sent?from?a?mobile?device ? P?vodn? zpr?va ? Od: Bob Monkman Odesl?no: ?ter?, 8. prosince 2015 1:55 Komu: O'Driscoll, Tim; dev at dpdk.org Kopie: Prasun.Kapoor at caviumnetworks.com; Liu, Kin-Yip P?edm?t: Re: [dpdk-dev] DPDK Community Call - ARM Support Tim, Yes, and I have been meaning to ask Venky to send out the presentation again. This was asked at the meeting and it fell through the cracks. I had wanted to ping some of the ARM SoC folks to read it and come prepared to discuss. As it stands, I will send a note anyways and see if I can get some interested stakeholders there. I recall some of the Cavium folks were online last time. Regards, Bob Robert (Bob) Monkman Enterprise Segment Marketing Manager 150 Rose Orchard Way San Jose, Ca 95134 M: +1.510.676.5490 -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of O'Driscoll, Tim Sent: Friday, December 04, 2015 9:51 AM To: dev at dpdk.org Subject: [dpdk-dev] DPDK Community Call - ARM Support I missed Tuesday's call as I was travelling, but I believe one of the outcomes was to hold another call at the same time on Tuesday 8th to further discuss the External Mempool Manager. Here are the details: When: Tue, Dec 8, 2015 15:00 - 16:00 GMT Tue, Dec 8, 2015 07:00 - 08:00 PST Tue, Dec 8, 2015 10:00 - 11:00 EST Tue, Dec 8, 2015 16:00 - 17:00 CET How to join: You can join from your computer, tablet or smartphone: https://global.gotomeeting.com/join/704010829 You can also dial in using your phone. Access Code: 704-010-829 Phone numbers United States : +1 (786) 358-5410 Australia : +61 2 9087 3604 Austria : +43 7 2088 0034 Belgium : +32 (0) 28 93 7018 Canada : +1 (647) 497-9350 Denmark : +45 69 91 88 62 Finland : +358 (0) 942 41 5778 France : +33 (0) 182 880 456 Germany : +49 (0) 692 5736 7211 Ireland : +353 (0) 15 290 180 Italy : +39 0 699 36 98 80 Netherlands : +31 (0) 208 908 267 New Zealand : +64 9 442 7358 Norway : +47 21 54 32 44 Spain : +34 911 23 0850 Sweden : +46 (0) 853 527 835 Switzerland : +41 (0) 435 0006 96 United Kingdom : +44 (0) 20 3713 5028 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
[dpdk-dev] [PATCH v2 2/3] eal/acl: enable acl for armv7-a
On Tue, 08 Dec 2015 11:38:46 +0100 Thomas Monjalon wrote: > 2015-12-08 18:21, Jianbo Liu: > > On 8 December 2015 at 18:03, Thomas Monjalon > > wrote: > > > 2015-12-08 15:56, Jianbo Liu: > > >> On 8 December 2015 at 10:23, Thomas Monjalon > >> 6wind.com> wrote: > > >> > 2015-12-08 09:50, Jianbo Liu: > > >> >> On 8 December 2015 at 09:18, Thomas Monjalon > >> >> 6wind.com> wrote: > > >> >> > 2015-12-03 23:02, Jianbo Liu: > > >> >> >> -ifeq ($(CONFIG_RTE_ARCH_ARM64),y) > > >> >> >> +ifneq ($(filter y,$(CONFIG_RTE_ARCH_ARM) > > >> >> >> $(CONFIG_RTE_ARCH_ARM64)),) > > >> >> > [...] > > >> >> >> +#ifdef RTE_ARCH_ARM > > >> >> >> +/* NEON intrinsic vqtbl1q_u8() is not supported in > > >> >> >> ARMv7-A(AArch32) */ > > >> >> > > > >> >> > I'm convinced there is a good reason why ARMv8 is also called > > >> >> > ARCH_ARM64, > > >> >> > and ARMv7 may be called AArch32 or ARCH_ARM. But I don't know why? > > >> >> > > > >> >> https://lkml.org/lkml/2012/7/15/133 > > >> >> > > >> >> > Is ARCH_ARM32 or ARCH_ARMv7 too simple? > > >> >> > Is it possible to have a 32-bit ARMv8? > > >> >> Yes, ARMv8-R/M > > >> > > > >> > So what does mean CONFIG_RTE_ARCH_ARM? > > >> > ARMv7? ARM32? > > >> > Please consider a renaming. > > >> > > >> I'd rather not renaming becase it can be both ARMv7 and AARCH32, which > > >> are ISA compatibility. > > >> If further differentiation is needed, CONFIG_RTE_ARCH_ARMv7 is added > > >> in the config, just like Jan Viktorin did. > > > > > > I don't understand. > > > You say CONFIG_RTE_ARCH_ARM is for ARMv7 and AARCH32, right? > > > Both are 32-bit right? > > > Why not rename it to CONFIG_RTE_ARCH_ARM32? > > > > I understand that you want to make the naming more clear. > > But arm/arm64 are used in Linux kernel, I think it's better to stay the > > same. > > Linux supports ARM for a very long time. Doing a rename now is costly. > The DPDK support is recent. Keeping a bad naming scheme because an > old project follows this scheme is insane. I think, the idea about having CONFIG_RTE_ARCH_ARM32 is not bad. We should do it soon, however. Regards Jan
[dpdk-dev] [[RFC PATCH]] lib/ether: fix 16-bit unaligned access
Hello,
I was looking at some warnings generated during ARM build. I can see
53 warnings for my build based on v2.2.0-rc3, spread among:
app/test-pmd/{flowgen,icmpecho,txonly}.c
app/test/{packet_burst_generator,test_hash_functions,test_thash}.c
lib/librte_ether/rte_ether.h
drivers/net/bonding/rte_eth_bond_pmd.c
lib/librte_acl/{acl_gen,acl_run}.c
lib/librte_eal/linuxapp/eal/{eal_interrupts,eal_pci_vfio_mp_sync}.c
lib/librte_hash/rte_cuckoo_hash.c
lib/librte_ip_frag/rte_ipv4_reassembly.c
lib/librte_sched/{rte_bitmap.h,rte_sched.c}
I think, some of them are false-positives. In this RFC patch I tried to fix
only the rte_ether.h which uses the unaligned_uint16_t data type. I didn't
test it as it is just the first kick to solve more of those warns.
Regards
Jan
(I considered to not add the cover-letter as this is just a single small patch.
I hope it does not matter a lot. Is there any convention how to do this?)
---
This commit removes warning reported when building for ARMv7 target.
Signed-off-by: Jan Viktorin
---
lib/librte_ether/rte_ether.h | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/lib/librte_ether/rte_ether.h b/lib/librte_ether/rte_ether.h
index 07c17d7..ba8a80a 100644
--- a/lib/librte_ether/rte_ether.h
+++ b/lib/librte_ether/rte_ether.h
@@ -175,10 +175,9 @@ static inline int is_multicast_ether_addr(const struct
ether_addr *ea)
*/
static inline int is_broadcast_ether_addr(const struct ether_addr *ea)
{
- const unaligned_uint16_t *ea_words = (const unaligned_uint16_t *)ea;
+ const uint32_t *ea_words = (const uint32_t *)ea;
- return (ea_words[0] == 0x && ea_words[1] == 0x &&
- ea_words[2] == 0x);
+ return ea_words[0] == 0x && (ea_words[1] & 0x0) == 0x0;
}
/**
--
2.6.3
[dpdk-dev] [[RFC PATCH]] lib/ether: fix 16-bit unaligned access
On Tue, 8 Dec 2015 12:02:54 -0800
Stephen Hemminger wrote:
> On Tue, 8 Dec 2015 20:29:53 +0100
> Jan Viktorin wrote:
>
> > Hello,
> >
> > I was looking at some warnings generated during ARM build. I can see
> > 53 warnings for my build based on v2.2.0-rc3, spread among:
> >
> > app/test-pmd/{flowgen,icmpecho,txonly}.c
> > app/test/{packet_burst_generator,test_hash_functions,test_thash}.c
> > lib/librte_ether/rte_ether.h
> > drivers/net/bonding/rte_eth_bond_pmd.c
> > lib/librte_acl/{acl_gen,acl_run}.c
> > lib/librte_eal/linuxapp/eal/{eal_interrupts,eal_pci_vfio_mp_sync}.c
> > lib/librte_hash/rte_cuckoo_hash.c
> > lib/librte_ip_frag/rte_ipv4_reassembly.c
> > lib/librte_sched/{rte_bitmap.h,rte_sched.c}
> >
> > I think, some of them are false-positives. In this RFC patch I tried to fix
> > only the rte_ether.h which uses the unaligned_uint16_t data type. I didn't
> > test it as it is just the first kick to solve more of those warns.
> >
> > Regards
> > Jan
> >
> > (I considered to not add the cover-letter as this is just a single small
> > patch.
> > I hope it does not matter a lot. Is there any convention how to do this?)
> > ---
> > This commit removes warning reported when building for ARMv7 target.
> >
> > Signed-off-by: Jan Viktorin
> > ---
> > lib/librte_ether/rte_ether.h | 5 ++---
> > 1 file changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/lib/librte_ether/rte_ether.h b/lib/librte_ether/rte_ether.h
> > index 07c17d7..ba8a80a 100644
> > --- a/lib/librte_ether/rte_ether.h
> > +++ b/lib/librte_ether/rte_ether.h
> > @@ -175,10 +175,9 @@ static inline int is_multicast_ether_addr(const struct
> > ether_addr *ea)
> > */
> > static inline int is_broadcast_ether_addr(const struct ether_addr *ea)
> > {
> > - const unaligned_uint16_t *ea_words = (const unaligned_uint16_t *)ea;
> > + const uint32_t *ea_words = (const uint32_t *)ea;
> >
> > - return (ea_words[0] == 0x && ea_words[1] == 0x &&
> > - ea_words[2] == 0x);
> > + return ea_words[0] == 0x && (ea_words[1] & 0x0) == 0x0;
> >
>
> The problem with that is that it assumes little-endian.
Well, true. But there is another issue that I considered just after
left for home today :). The ether_addr can be unaligned in memory easily
(as it comes in the Ethernet frame). Another false-positive... So the
original code is correct. The fix would be to mute the compiler here.
The solution is probably to enable RTE_ARCH_STRICT_ALIGN in the
defconfig_arm-armv7a-linuxapp-gcc. This will probably solve more unaligned
false-positives.
Regards
Jan
--
Jan ViktorinE-mail: Viktorin at RehiveTech.com
System ArchitectWeb:www.RehiveTech.com
RehiveTech
Brno, Czech Republic
[dpdk-dev] [[RFC PATCH]] lib/ether: fix 16-bit unaligned access
On Tue, 08 Dec 2015 21:30:03 +0100 Thomas Monjalon wrote: > 2015-12-08 20:29, Jan Viktorin: > > (I considered to not add the cover-letter as this is just a single small > > patch. > > I hope it does not matter a lot. Is there any convention how to do this?) > > The main interest of splitting patches or adding a cover letter it to have > a place to explain the changes. When you have several changes, they deserve > several patches to provide an accurate explanation. In such case, you may > need a cover letter to describe the global idea of the series. A cover letter > is also helpful for mail threading and acking all the series. > When you have only one change, one email is enough. That's good. Should there be a way how to separate the "inline-cover" and the commit? > > John, should we add this explanation in the contributing guide? -- Jan ViktorinE-mail: Viktorin at RehiveTech.com System ArchitectWeb:www.RehiveTech.com RehiveTech Brno, Czech Republic
[dpdk-dev] [[RFC PATCH]] lib/ether: fix 16-bit unaligned access
On Tue, 08 Dec 2015 21:57:33 +0100 Thomas Monjalon wrote: > 2015-12-08 21:55, Jan Viktorin: > > On Tue, 08 Dec 2015 21:30:03 +0100 > > Thomas Monjalon wrote: > > > > > 2015-12-08 20:29, Jan Viktorin: > > > > (I considered to not add the cover-letter as this is just a single > > > > small patch. > > > > I hope it does not matter a lot. Is there any convention how to do > > > > this?) > > > > > > The main interest of splitting patches or adding a cover letter it to have > > > a place to explain the changes. When you have several changes, they > > > deserve > > > several patches to provide an accurate explanation. In such case, you may > > > need a cover letter to describe the global idea of the series. A cover > > > letter > > > is also helpful for mail threading and acking all the series. > > > When you have only one change, one email is enough. > > > > That's good. Should there be a way how to separate the "inline-cover" > > and the commit? > > Do you mean how add a comment which won't be in the git tree? > You can put whatever between the 3 dashes and the diff. > Exactly. When I was writing this message, I decided to put the "cover" first and the commit log after the 3 dashes. It was more logical to me...
[dpdk-dev] Buildroot support for DPDK 2.2.0-rc3
Hello, I've posted a new patch set with DPDK support into the Buildroot project: http://lists.busybox.net/pipermail/buildroot/2015-December/146564.html Patchwork: https://patchwork.ozlabs.org/patch/554673/ https://patchwork.ozlabs.org/patch/554674/ https://patchwork.ozlabs.org/patch/554675/ After I integrate the new DPDK install rules and fix some minor issues, I assume that it will be accepted upstream there. Buildroot is useful at least for cross toolchain generation. Regards Jan -- Jan Viktorin E-mail: Viktorin at RehiveTech.com System Architect Web:www.RehiveTech.com RehiveTech Brno, Czech Republic
[dpdk-dev] Buildroot support for DPDK 2.2.0-rc3
On Wed, 9 Dec 2015 20:17:44 +0530 Santosh Shukla wrote: > Its encouraging. > > Could you pl. post buildroot how-to patch to dpdk-dev mailing list, after > your work gets accepted in buildroot. Yes. What exactly do you mean by "how-to patch"? > > Thanks > > On Wed, Dec 9, 2015 at 8:10 PM, Jan Viktorin > wrote: > > > Hello, > > > > I've posted a new patch set with DPDK support into the Buildroot project: > > > > http://lists.busybox.net/pipermail/buildroot/2015-December/146564.html > > > > Patchwork: > > > > https://patchwork.ozlabs.org/patch/554673/ > > https://patchwork.ozlabs.org/patch/554674/ > > https://patchwork.ozlabs.org/patch/554675/ > > > > After I integrate the new DPDK install rules and fix some minor issues, > > I assume that it will be accepted upstream there. Buildroot is useful > > at least for cross toolchain generation. > > > > Regards > > Jan > > > > -- > >Jan Viktorin E-mail: Viktorin at RehiveTech.com > >System Architect Web:www.RehiveTech.com > >RehiveTech > >Brno, Czech Republic > > -- Jan Viktorin E-mail: Viktorin at RehiveTech.com System Architect Web:www.RehiveTech.com RehiveTech Brno, Czech Republic
[dpdk-dev] [PATCH 1/1] arm: set CONFIG_RTE_ARCH_STRICT_ALIGN=y for armv7 target
This patch reduces number of warnings from 53 to 40. It removes the usual false positives utilizing unaligned_uint*_t data types. Signed-off-by: Jan Viktorin --- As far as I know, only a 64-bit unaligned access can be a problem for ARMv7. I found only one such occurence: 118 struct rte_mbuf * 119 rte_ipv4_frag_reassemble_packet(struct rte_ip_frag_tbl *tbl, 120 struct rte_ip_frag_death_row *dr, struct rte_mbuf *mb, uint64_t tms, 121 struct ipv4_hdr *ip_hdr) ... 133 psd = (unaligned_uint64_t *)&ip_hdr->src_addr; 134 /* use first 8 bytes only */ 135 key.src_dst[0] = psd[0]; 136 key.id = ip_hdr->packet_id; 137 key.key_len = IPV4_KEYLEN Is this a real issue? --- config/defconfig_arm-armv7a-linuxapp-gcc | 1 + 1 file changed, 1 insertion(+) diff --git a/config/defconfig_arm-armv7a-linuxapp-gcc b/config/defconfig_arm-armv7a-linuxapp-gcc index cbebd64..2482d91 100644 --- a/config/defconfig_arm-armv7a-linuxapp-gcc +++ b/config/defconfig_arm-armv7a-linuxapp-gcc @@ -39,6 +39,7 @@ CONFIG_RTE_ARCH_ARM_TUNE="cortex-a9" CONFIG_RTE_ARCH_ARM_NEON=y CONFIG_RTE_FORCE_INTRINSICS=y +CONFIG_RTE_ARCH_STRICT_ALIGN=y CONFIG_RTE_TOOLCHAIN="gcc" CONFIG_RTE_TOOLCHAIN_GCC=y -- 2.6.3
[dpdk-dev] [PATCH 5/6] linuxapp: eal: arm: Always return 0 for rte_eal_iopl_init()
On Fri, 4 Dec 2015 23:05:18 +0530 Santosh Shukla wrote: > iopl() syscall not supported in linux-arm/arm64 so always return 0 value. > > Signed-off-by: Santosh Shukla > --- Acked-by: Jan Viktorin
[dpdk-dev] VFIO no-iommu
Hello, I am not involved in the vfio very much, however, I was watching some vfio-related code in last few weeks. It looks promising to me and IMHO it seems to the best way to bring a support of integrated Ethernet MACs into DPDK (related to many SoCs). Unfortunately, the ARMv7 SoCs (I know) lacks of an IOMMU... The only protection there is the TrustZone technology but I have no idea of its support in the kernel. It's also far from being a replacement of an IOMMU. When using FPGAs, it is possible to put an IOMMU engine there (I've got such a prototype somewhere in my VHDL library) but nobody will probably do use because of saving on-chip resources. The X-Gene SoC (ARM 64) contains 2x 10 Gbps EMACs on the chip. I have no idea about IOMMUs there. Thus, this platform can probably benefit of such driver as well. The question is whether there is some interest to have this kind of support in DPDK. Thus, I'd like to have the vfio/no-iommu to support the ARMv7 (otherwise it would be effectively dead in DPDK). Unfortunately, it's not my primary job at the moment. Regards Jan Note: as far as I know, it is discouraged to refer to lkml.org as it is often very slow - my case today :). On Fri, 11 Dec 2015 17:28:43 +0100 Thomas Monjalon wrote: > Recently there were some discussions to have an upstream replacement > for our igb_uio module. > Several solutions were discussed (new uio driver, uio_pci_generic, vfio): > https://lkml.org/lkml/2015/10/16/700 > > Alex Williamson (maintainer of VFIO driver), submitted a solution > and was waiting some feedback. Unfortunately, nobody caught it and > he has reverted his work: > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ae5515d > > It is an important challenge to remove our out-of-tree modules and > especially igb_uio. It is a long way to have a standard solution integrated > in every distributions. > The current cooking Linux kernel is 4.4 and will have a long term maintenance: > https://kernel.org/releases.html > So it is a pity to miss this opportunity. > > Stephen has fixed a bug to use the IOMMU group zero: > http://dpdk.org/browse/dpdk/commit/?id=22215f141b1 > > Is there someone interested to work on VFIO no-iommu and provide > some feedbacks? > We also need to prepare a documentation patch to explain its usage > compared to the standard VFIO mode. > > Thanks
[dpdk-dev] [ [PATCH v2] 00/13] Add virtio support in arm/arm64
LIBRTE_VIRTIO_PMD > linuxapp: eal: arm: Always return 0 for rte_eal_iopl_init() > rte_io: x86: Remove sys/io.h ifdef x86 clutter > igb_uio: ioport: map iopci region for armv7/v8 > include/exec-env: ioport: add rte_virt_ioport header file > virtio_ioport: armv7/v8: mmap virtio iopci bar region > virtio_ethdev: use virtio_ioport api at device init/close > virtio_ethdev : fix format specifier error for 64bit addr case > > config/common_linuxapp |1 + > config/defconfig_arm-armv7a-linuxapp-gcc |6 +- > config/defconfig_arm64-armv8a-linuxapp-gcc |6 +- > config/defconfig_i686-native-linuxapp-gcc |1 + > config/defconfig_i686-native-linuxapp-icc |1 + > drivers/net/virtio/Makefile|3 +- > drivers/net/virtio/virtio_ethdev.c | 10 +- > drivers/net/virtio/virtio_ioport.c | 163 > > drivers/net/virtio/virtio_ioport.h | 42 + > drivers/net/virtio/virtio_pci.h|6 +- > drivers/net/virtio/virtio_rxtx.c |7 + > lib/librte_eal/common/Makefile |1 + > lib/librte_eal/common/include/arch/arm/rte_io.h| 60 +++ > lib/librte_eal/common/include/arch/arm/rte_io_32.h | 155 +++ > lib/librte_eal/common/include/arch/arm/rte_io_64.h | 155 +++ > lib/librte_eal/common/include/arch/x86/rte_io.h| 42 + > lib/librte_eal/common/include/generic/rte_io.h | 81 ++ > lib/librte_eal/linuxapp/eal/Makefile |2 +- > lib/librte_eal/linuxapp/eal/eal.c |7 +- > .../eal/include/exec-env/rte_virt_ioport.h | 81 ++ > lib/librte_eal/linuxapp/igb_uio/igb_uio.c |8 +- > .../linuxapp/igb_uio/igbuio_ioport_misc.h | 133 > 22 files changed, 957 insertions(+), 14 deletions(-) > create mode 100644 drivers/net/virtio/virtio_ioport.c > create mode 100644 drivers/net/virtio/virtio_ioport.h > create mode 100644 lib/librte_eal/common/include/arch/arm/rte_io.h > create mode 100644 lib/librte_eal/common/include/arch/arm/rte_io_32.h > create mode 100644 lib/librte_eal/common/include/arch/arm/rte_io_64.h > create mode 100644 lib/librte_eal/common/include/arch/x86/rte_io.h > create mode 100644 lib/librte_eal/common/include/generic/rte_io.h > create mode 100644 > lib/librte_eal/linuxapp/eal/include/exec-env/rte_virt_ioport.h > create mode 100644 lib/librte_eal/linuxapp/igb_uio/igbuio_ioport_misc.h > -- Jan Viktorin E-mail: Viktorin at RehiveTech.com System Architect Web:www.RehiveTech.com RehiveTech Brno, Czech Republic
[dpdk-dev] [ [PATCH v2] 07/13] linuxapp: eal: arm: Always return 0 for rte_eal_iopl_init()
I believe, I've already acked this patch. I can see no change here so I assume it's still the same. On Mon, 14 Dec 2015 18:30:26 +0530 Santosh Shukla wrote: > iopl() syscall not supported in linux-arm/arm64 so always return 0 value. > > Signed-off-by: Santosh Shukla Acked-by: Jan Viktorin
[dpdk-dev] [PATCH] doc: announce ABI change for link speed
On Tue, 15 Dec 2015 08:21:14 +0100 Thomas Monjalon wrote: > A rework was prepared by Marc Sune: > http://dpdk.org/ml/archives/dev/2015-October/026037.html > The goal is to retrieve the supported link speed of a device > and to allow 100G devices while having a consistent API. > > Signed-off-by: Thomas Monjalon Acked-by: Jan Viktorin
[dpdk-dev] Urgent - Fwd: [PATCH] doc: announce ABI change for link speed
Matej is aware of those changes (towards 100G) and we were discussing this extension already. Great to see that this topic is moving on. Jan On Tue, 15 Dec 2015 11:56:47 +0100 Viktor Pu? wrote: > CCing to Jan in case Matej is offline today - can you ack this? > > Best, > Viktor > > > On 15 Dec 2015, at 11:42, Thomas Monjalon > > wrote: > > > > Please, are you available to allow 100G in next DPDK release? > > It must be accepted before releasing 2.2 (today). > > Thanks > > > > 2015-12-15 08:31, Thomas Monjalon: > >> Please ack ASAP to reach 3 acks before the release (in the coming hours). > >> Thanks a lot > >> > >> --- > >> > >> Objet : [PATCH] doc: announce ABI change for link speed > >> Date : mardi 15 d?cembre 2015, 08:21:14 > >> De : Thomas Monjalon > >> ? : dev at dpdk.org > >> CC : Marc Sune , Olga Shern >> mellanox.com>, Matej Vido > >> > >> A rework was prepared by Marc Sune: > >> http://dpdk.org/ml/archives/dev/2015-October/026037.html > >> The goal is to retrieve the supported link speed of a device > >> and to allow 100G devices while having a consistent API. > >> > >> Signed-off-by: Thomas Monjalon > >> --- > >> doc/guides/rel_notes/deprecation.rst | 3 +++ > >> 1 file changed, 3 insertions(+) > >> > >> diff --git a/doc/guides/rel_notes/deprecation.rst > >> b/doc/guides/rel_notes/deprecation.rst > >> index a4abb08..f8a41dd 100644 > >> --- a/doc/guides/rel_notes/deprecation.rst > >> +++ b/doc/guides/rel_notes/deprecation.rst > >> @@ -12,6 +12,9 @@ Deprecation Notices > >> ibadcrc, ibadlen, imcasts, fdirmatch, fdirmiss, > >> tx_pause_xon, rx_pause_xon, tx_pause_xoff, rx_pause_xoff > >> > >> +* The ethdev structures rte_eth_link, rte_eth_dev_info and rte_eth_conf > >> + must be updated to support 100G link and to have a cleaner link speed > >> API. > >> + > >> * ABI changes is planned for the reta field in struct > >> rte_eth_rss_reta_entry64 > >> which handles at most 256 entries (8 bits) while newer NICs support > >> larger > >> tables (512 entries). > >> > -- Jan ViktorinE-mail: Viktorin at RehiveTech.com System ArchitectWeb:www.RehiveTech.com RehiveTech Brno, Czech Republic
[dpdk-dev] VFIO no-iommu
On Thu, 17 Dec 2015 11:09:23 +0100 Thomas Monjalon wrote: > Hi, > > 2015-12-17 09:52, Burakov, Anatoly: > > > > > > On Tue, Dec 15, 2015 at 09:53:18AM -0700, Alex Williamson wrote: > > > > > > So it works. Is it acceptable? Useful? Sufficiently complete? > > > > > > Does it imply deprecating the uio interface? I believe the > > > > > > feature that started this discussion was support for MSI/X > > > > > > interrupts so that VFs can support some kind of interrupt (uio > > > > > > only supports INTx since it doesn't allow DMA). Implementing that > > > > > > would be the ultimate test of whether this provides dpdk with not > > > > > > only a more consistent interface, but the feature dpdk wants > > > > > > that's missing in uio. Thanks, > > > > > > > > Ferruh has done a great job so far testing Alex's patch, very few > > > > changes > > > from DPDK side seem to be required as far as existing functionality goes > > > (not > > > sure about VF interrupts mentioned by Alex). However, one thing that > > > concerns me is usability. While it is true that no-IOMMU mode in VFIO > > > would > > > mean uio interfaces could be deprecated in time, the no-iommu mode is way > > > more hassle than using igb_uio/uio_pci_generic because it will require a > > > kernel recompile as opposed to simply compiling and insmod'ding an out-of- > > > tree driver. So, in essence, if you don't want an IOMMU, it's becoming > > > that > > > much harder to use DPDK. Would that be something DPDK is willing to live > > > with in the absence of uio interfaces? > > > > > > Excuse me if I missed something obvious. > > > Why a kernel compilation is needed? > > > > Well, not really full kernel compilation, but in the default configuration, > > VFIO driver would not support NOIOMMU mode. I.e. it's not compiled by > > default. Support for no-iommu should be enabled in kernel config and > > compiled in. So, whoever is going to use DPDK with VFIO-no-iommu will have > > to download kernel tree and recompile the VFIO module and install it. > > That's obviously way more hassle than simply compiling an out-of-tree > > driver that's already included and works with an out-of-the-box kernel. > > The "out-of-the-box kernel" is configured by your distribution. > So we don't know yet what will be their choice. > If the distribution supports DPDK, it should be enabled. I have a question as I am not involved in all possible DPDK configurations, platforms, etc. and not yet very involved in vfio. What are the devices which do not have IOMMU? If I have, say, DPDK 2.3 with vfio-noiommu, which platforms (or computer systems) I am targeting? Would it be an Intel-based system? Would it be PPC8, ARM? If it is ARMv7... I would say that the fact I have to explicitly enable the no-IOMMU feature and rebuild the kernel (or whatever) is just OK. As for such systems, it is common to have a quite customized OS. Well, the big distributions are able to run on those devices, that's true... However, in such case, the users are usually skilled enough to take care of having their own special Linux kernel. So, is the fact the distributions would not support the no-IOMMU setup in their default configuration really an issue? Will some very common Intel/DPDK-based box need this? Regards Jan
[dpdk-dev] [PATCH 2/6] lib: use SPDX tag for RehiveTech copyright files
Replace the BSD license header with the SPDX tag for files with only an RehiveTech copyright on them. Signed-off-by: Jan Viktorin --- .../common/include/arch/arm/rte_atomic.h | 32 ++ .../common/include/arch/arm/rte_atomic_32.h| 32 ++ .../common/include/arch/arm/rte_byteorder.h| 32 ++ .../common/include/arch/arm/rte_cpuflags.h | 32 ++ .../common/include/arch/arm/rte_cpuflags_32.h | 32 ++ .../common/include/arch/arm/rte_cycles.h | 32 ++ .../common/include/arch/arm/rte_cycles_32.h| 32 ++ .../common/include/arch/arm/rte_memcpy.h | 32 ++ .../common/include/arch/arm/rte_memcpy_32.h| 32 ++ .../common/include/arch/arm/rte_prefetch.h | 32 ++ .../common/include/arch/arm/rte_prefetch_32.h | 32 ++ .../common/include/arch/arm/rte_spinlock.h | 32 ++ 12 files changed, 24 insertions(+), 360 deletions(-) diff --git a/lib/librte_eal/common/include/arch/arm/rte_atomic.h b/lib/librte_eal/common/include/arch/arm/rte_atomic.h index f3f3b6e31..40e14e56f 100644 --- a/lib/librte_eal/common/include/arch/arm/rte_atomic.h +++ b/lib/librte_eal/common/include/arch/arm/rte_atomic.h @@ -1,33 +1,5 @@ -/*- - * BSD LICENSE - * - * Copyright(c) 2015 RehiveTech. All rights reserved. - * - * Redistribution and use in source and binary forms, with or without - * modification, are permitted provided that the following conditions - * are met: - * - * * Redistributions of source code must retain the above copyright - * notice, this list of conditions and the following disclaimer. - * * Redistributions in binary form must reproduce the above copyright - * notice, this list of conditions and the following disclaimer in - * the documentation and/or other materials provided with the - * distribution. - * * Neither the name of RehiveTech nor the names of its - * contributors may be used to endorse or promote products derived - * from this software without specific prior written permission. - * - * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS - * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT - * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR - * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT - * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, - * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT - * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, - * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY - * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE - * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. +/* SPDX-License-Identifier: BSD-3-Clause + * Copyright(c) 2015 RehiveTech. All rights reserved. */ #ifndef _RTE_ATOMIC_ARM_H_ diff --git a/lib/librte_eal/common/include/arch/arm/rte_atomic_32.h b/lib/librte_eal/common/include/arch/arm/rte_atomic_32.h index d2b7fa20f..859562e59 100644 --- a/lib/librte_eal/common/include/arch/arm/rte_atomic_32.h +++ b/lib/librte_eal/common/include/arch/arm/rte_atomic_32.h @@ -1,33 +1,5 @@ -/*- - * BSD LICENSE - * - * Copyright(c) 2015 RehiveTech. All rights reserved. - * - * Redistribution and use in source and binary forms, with or without - * modification, are permitted provided that the following conditions - * are met: - * - * * Redistributions of source code must retain the above copyright - * notice, this list of conditions and the following disclaimer. - * * Redistributions in binary form must reproduce the above copyright - * notice, this list of conditions and the following disclaimer in - * the documentation and/or other materials provided with the - * distribution. - * * Neither the name of RehiveTech nor the names of its - * contributors may be used to endorse or promote products derived - * from this software without specific prior written permission. - * - * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS - * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT - * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR - * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT - * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, - * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT - * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, - * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEV
[dpdk-dev] [PATCH 1/6] mk: use SPDX tag for RehiveTech copyright files
Replace the BSD license header with the SPDX tag for files with only an RehiveTech copyright on them. Signed-off-by: Jan Viktorin --- mk/arch/arm/rte.vars.mk | 32 ++-- mk/machine/armv7a/rte.vars.mk | 31 ++- 2 files changed, 4 insertions(+), 59 deletions(-) diff --git a/mk/arch/arm/rte.vars.mk b/mk/arch/arm/rte.vars.mk index 2f8cf7cb9..27b114761 100644 --- a/mk/arch/arm/rte.vars.mk +++ b/mk/arch/arm/rte.vars.mk @@ -1,33 +1,5 @@ -# BSD LICENSE -# -# Copyright (C) 2015 RehiveTech. All rights reserved. -# -# Redistribution and use in source and binary forms, with or without -# modification, are permitted provided that the following conditions -# are met: -# -# * Redistributions of source code must retain the above copyright -# notice, this list of conditions and the following disclaimer. -# * Redistributions in binary form must reproduce the above copyright -# notice, this list of conditions and the following disclaimer in -# the documentation and/or other materials provided with the -# distribution. -# * Neither the name of RehiveTech nor the names of its -# contributors may be used to endorse or promote products derived -# from this software without specific prior written permission. -# -# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS -# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT -# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR -# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT -# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, -# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT -# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, -# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY -# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT -# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE -# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - +# SPDX-License-Identifier: BSD-3-Clause +# Copyright (C) 2015 RehiveTech. All rights reserved. ARCH ?= arm CROSS ?= diff --git a/mk/machine/armv7a/rte.vars.mk b/mk/machine/armv7a/rte.vars.mk index 41c4c4082..44ebd68da 100644 --- a/mk/machine/armv7a/rte.vars.mk +++ b/mk/machine/armv7a/rte.vars.mk @@ -1,32 +1,5 @@ -# BSD LICENSE -# -# Copyright (C) 2015 RehiveTech. All rights reserved. -# -# Redistribution and use in source and binary forms, with or without -# modification, are permitted provided that the following conditions -# are met: -# -# * Redistributions of source code must retain the above copyright -# notice, this list of conditions and the following disclaimer. -# * Redistributions in binary form must reproduce the above copyright -# notice, this list of conditions and the following disclaimer in -# the documentation and/or other materials provided with the -# distribution. -# * Neither the name of RehiveTech nor the names of its -# contributors may be used to endorse or promote products derived -# from this software without specific prior written permission. -# -# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS -# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT -# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR -# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT -# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, -# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT -# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, -# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY -# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT -# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE -# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. +# SPDX-License-Identifier: BSD-3-Clause +# Copyright (C) 2015 RehiveTech. All rights reserved. # # machine: -- 2.16.2
[dpdk-dev] [PATCH 0/6] Use SPDX identifier of RehiveTech code
Hi all, I've updated all relevant code to SPDX license. The last commit also updates the Cavium copyright, I've separated it for clarity otherwise it can be squashed into 02. Jan Jan Viktorin (6): mk: use SPDX tag for RehiveTech copyright files lib: use SPDX tag for RehiveTech copyright files drivers: use SPDX tag for RehiveTech copyright files test: use SPDX tag for RehiveTech copyright files config: use SPDX tag for RehiveTech copyright files lib: use SPDX tag for Cavium & RehiveTech copyright files config/defconfig_arm-armv7a-linuxapp-gcc | 31 ++-- drivers/bus/vdev/rte_bus_vdev.h| 32 ++-- drivers/bus/vdev/vdev.c| 32 ++-- lib/librte_eal/common/arch/arm/rte_cpuflags.c | 34 ++ .../common/include/arch/arm/rte_atomic.h | 32 ++-- .../common/include/arch/arm/rte_atomic_32.h| 32 ++-- .../common/include/arch/arm/rte_byteorder.h| 32 ++-- .../common/include/arch/arm/rte_cpuflags.h | 32 ++-- .../common/include/arch/arm/rte_cpuflags_32.h | 32 ++-- .../common/include/arch/arm/rte_cycles.h | 32 ++-- .../common/include/arch/arm/rte_cycles_32.h| 32 ++-- .../common/include/arch/arm/rte_memcpy.h | 32 ++-- .../common/include/arch/arm/rte_memcpy_32.h| 32 ++-- .../common/include/arch/arm/rte_prefetch.h | 32 ++-- .../common/include/arch/arm/rte_prefetch_32.h | 32 ++-- .../common/include/arch/arm/rte_spinlock.h | 32 ++-- mk/arch/arm/rte.vars.mk| 32 ++-- mk/machine/armv7a/rte.vars.mk | 31 ++-- test/test/resource.c | 33 ++--- test/test/resource.h | 33 ++--- test/test/test_resource.c | 33 ++--- 21 files changed, 43 insertions(+), 632 deletions(-) -- 2.16.2
[dpdk-dev] [PATCH 3/6] drivers: use SPDX tag for RehiveTech copyright files
Replace the BSD license header with the SPDX tag for files with only an RehiveTech copyright on them. Signed-off-by: Jan Viktorin --- drivers/bus/vdev/rte_bus_vdev.h | 32 ++-- drivers/bus/vdev/vdev.c | 32 ++-- 2 files changed, 4 insertions(+), 60 deletions(-) diff --git a/drivers/bus/vdev/rte_bus_vdev.h b/drivers/bus/vdev/rte_bus_vdev.h index f9d8a2383..646d6c090 100644 --- a/drivers/bus/vdev/rte_bus_vdev.h +++ b/drivers/bus/vdev/rte_bus_vdev.h @@ -1,33 +1,5 @@ -/*- - * BSD LICENSE - * - * Copyright(c) 2016 RehiveTech. All rights reserved. - * - * Redistribution and use in source and binary forms, with or without - * modification, are permitted provided that the following conditions - * are met: - * - * * Redistributions of source code must retain the above copyright - * notice, this list of conditions and the following disclaimer. - * * Redistributions in binary form must reproduce the above copyright - * notice, this list of conditions and the following disclaimer in - * the documentation and/or other materials provided with the - * distribution. - * * Neither the name of RehiveTech nor the names of its - * contributors may be used to endorse or promote products derived - * from this software without specific prior written permission. - * - * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS - * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT - * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR - * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT - * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, - * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT - * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, - * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY - * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE - * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. +/* SPDX-License-Identifier: BSD-3-Clause + * Copyright(c) 2016 RehiveTech. All rights reserved. */ #ifndef RTE_VDEV_H diff --git a/drivers/bus/vdev/vdev.c b/drivers/bus/vdev/vdev.c index 7eae319cb..f8dd1f5e6 100644 --- a/drivers/bus/vdev/vdev.c +++ b/drivers/bus/vdev/vdev.c @@ -1,33 +1,5 @@ -/*- - * BSD LICENSE - * - * Copyright(c) 2016 RehiveTech. All rights reserved. - * - * Redistribution and use in source and binary forms, with or without - * modification, are permitted provided that the following conditions - * are met: - * - * * Redistributions of source code must retain the above copyright - * notice, this list of conditions and the following disclaimer. - * * Redistributions in binary form must reproduce the above copyright - * notice, this list of conditions and the following disclaimer in - * the documentation and/or other materials provided with the - * distribution. - * * Neither the name of RehiveTech nor the names of its - * contributors may be used to endorse or promote products derived - * from this software without specific prior written permission. - * - * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS - * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT - * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR - * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT - * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, - * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT - * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, - * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY - * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE - * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. +/* SPDX-License-Identifier: BSD-3-Clause + * Copyright(c) 2016 RehiveTech. All rights reserved. */ #include -- 2.16.2
[dpdk-dev] [PATCH 6/6] lib: use SPDX tag for Cavium & RehiveTech copyright files
Replace the BSD license header with the SPDX tag for files with a RehiveTech and Cavium copyright on them. Signed-off-by: Jan Viktorin --- lib/librte_eal/common/arch/arm/rte_cpuflags.c | 34 +++ 1 file changed, 3 insertions(+), 31 deletions(-) diff --git a/lib/librte_eal/common/arch/arm/rte_cpuflags.c b/lib/librte_eal/common/arch/arm/rte_cpuflags.c index 88f1cbe37..390a19a26 100644 --- a/lib/librte_eal/common/arch/arm/rte_cpuflags.c +++ b/lib/librte_eal/common/arch/arm/rte_cpuflags.c @@ -1,34 +1,6 @@ -/* - * BSD LICENSE - * - * Copyright (C) Cavium, Inc. 2015. - * Copyright(c) 2015 RehiveTech. All rights reserved. - * - * Redistribution and use in source and binary forms, with or without - * modification, are permitted provided that the following conditions - * are met: - * - * * Redistributions of source code must retain the above copyright - * notice, this list of conditions and the following disclaimer. - * * Redistributions in binary form must reproduce the above copyright - * notice, this list of conditions and the following disclaimer in - * the documentation and/or other materials provided with the - * distribution. - * * Neither the name of Cavium, Inc nor the names of its - * contributors may be used to endorse or promote products derived - * from this software without specific prior written permission. - * - * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS - * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT - * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR - * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT - * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, - * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT - * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, - * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY - * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE - * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. +/* SPDX-License-Identifier: BSD-3-Clause + * Copyright (C) Cavium, Inc. 2015. + * Copyright(c) 2015 RehiveTech. All rights reserved. */ #include "rte_cpuflags.h" -- 2.16.2
[dpdk-dev] [PATCH 4/6] test: use SPDX tag for RehiveTech copyright files
Replace the BSD license header with the SPDX tag for files with only an RehiveTech copyright on them. Signed-off-by: Jan Viktorin --- test/test/resource.c | 33 ++--- test/test/resource.h | 33 ++--- test/test/test_resource.c | 33 ++--- 3 files changed, 6 insertions(+), 93 deletions(-) diff --git a/test/test/resource.c b/test/test/resource.c index 0e2b62cd8..34465f166 100644 --- a/test/test/resource.c +++ b/test/test/resource.c @@ -1,34 +1,5 @@ -/*- - * BSD LICENSE - * - * Copyright(c) 2016 RehiveTech. All rights reserved. - * All rights reserved. - * - * Redistribution and use in source and binary forms, with or without - * modification, are permitted provided that the following conditions - * are met: - * - * * Redistributions of source code must retain the above copyright - * notice, this list of conditions and the following disclaimer. - * * Redistributions in binary form must reproduce the above copyright - * notice, this list of conditions and the following disclaimer in - * the documentation and/or other materials provided with the - * distribution. - * * Neither the name of RehiveTech nor the names of its - * contributors may be used to endorse or promote products derived - * from this software without specific prior written permission. - * - * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS - * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT - * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR - * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT - * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, - * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT - * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, - * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY - * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE - * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. +/* SPDX-License-Identifier: BSD-3-Clause + * Copyright(c) 2016 RehiveTech. All rights reserved. */ #include diff --git a/test/test/resource.h b/test/test/resource.h index 1e9612213..223fa22ae 100644 --- a/test/test/resource.h +++ b/test/test/resource.h @@ -1,34 +1,5 @@ -/*- - * BSD LICENSE - * - * Copyright(c) 2016 RehiveTech. All rights reserved. - * All rights reserved. - * - * Redistribution and use in source and binary forms, with or without - * modification, are permitted provided that the following conditions - * are met: - * - * * Redistributions of source code must retain the above copyright - * notice, this list of conditions and the following disclaimer. - * * Redistributions in binary form must reproduce the above copyright - * notice, this list of conditions and the following disclaimer in - * the documentation and/or other materials provided with the - * distribution. - * * Neither the name of RehiveTech nor the names of its - * contributors may be used to endorse or promote products derived - * from this software without specific prior written permission. - * - * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS - * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT - * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR - * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT - * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, - * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT - * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, - * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY - * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE - * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. +/* SPDX-License-Identifier: BSD-3-Clause + * Copyright(c) 2016 RehiveTech. All rights reserved. */ #ifndef _RESOURCE_H_ diff --git a/test/test/test_resource.c b/test/test/test_resource.c index a3a82f13a..8f41e3bab 100644 --- a/test/test/test_resource.c +++ b/test/test/test_resource.c @@ -1,34 +1,5 @@ -/*- - * BSD LICENSE - * - * Copyright(c) 2016 RehiveTech. All rights reserved. - * All rights reserved. - * - * Redistribution and use in source and binary forms, with or without - * modification, are permitted provided that the following conditions - * are met: - * - * * Redistributions of source code must retain the above copyright - * notice, this list of conditions and the following disclaimer. - * * Redis
[dpdk-dev] [PATCH 5/6] config: use SPDX tag for RehiveTech copyright files
Replace the BSD license header with the SPDX tag for files with only an RehiveTech copyright on them. Signed-off-by: Jan Viktorin --- config/defconfig_arm-armv7a-linuxapp-gcc | 31 ++- 1 file changed, 2 insertions(+), 29 deletions(-) diff --git a/config/defconfig_arm-armv7a-linuxapp-gcc b/config/defconfig_arm-armv7a-linuxapp-gcc index a20b7a85f..13be308d8 100644 --- a/config/defconfig_arm-armv7a-linuxapp-gcc +++ b/config/defconfig_arm-armv7a-linuxapp-gcc @@ -1,32 +1,5 @@ -# BSD LICENSE -# -# Copyright (C) 2015 RehiveTech. All right reserved. -# -# Redistribution and use in source and binary forms, with or without -# modification, are permitted provided that the following conditions -# are met: -# -# * Redistributions of source code must retain the above copyright -# notice, this list of conditions and the following disclaimer. -# * Redistributions in binary form must reproduce the above copyright -# notice, this list of conditions and the following disclaimer in -# the documentation and/or other materials provided with the -# distribution. -# * Neither the name of RehiveTech nor the names of its -# contributors may be used to endorse or promote products derived -# from this software without specific prior written permission. -# -# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS -# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT -# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR -# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT -# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, -# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT -# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, -# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY -# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT -# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE -# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. +# SPDX-License-Identifier: BSD-3-Clause +# Copyright (C) 2015 RehiveTech. All right reserved. #include "common_linuxapp" -- 2.16.2
Re: [dpdk-dev] [PATCH v4 04/41] bus/dpaa: add OF parser for device scanning
On Tue, 19 Sep 2017 22:01:23 +0200 Thomas Monjalon wrote: > 19/09/2017 16:15, Ferruh Yigit: > > On 9/19/2017 2:37 PM, Shreyansh Jain wrote: > > > On Monday 18 September 2017 08:19 PM, Ferruh Yigit wrote: > > >> On 9/9/2017 12:20 PM, Shreyansh Jain wrote: > > >>> This layer is used by Bus driver's scan function. Devices are parsed > > >>> using OF parser and added to DPAA device list. > > >> > > >> So this is device tree parser in DPDK. Do we really want this, and as > > >> long as DPDK target the bare metal why not get device information from > > >> Linux, as done in other cases? > > > As of now I don't prefer to modify the internal framework as much as > > > possible as this is stable DPDK DPAA driver. > > > There is indeed a planned transition from OF to /sys/ parsing, but it is > > > still in pipeline. > > > > > > You see a blocking issue if we go incremental here? > > > That would be probably more of replacing this file with another /sys > > > parser without much changes to the DPDK glue code. > > > > OF parser in DPDK looks weird to me, OS will do this for us already. > > > > If replacing this is in the roadmap, I think this is not showstopper, > > added Thomas in case he thinks otherwise. > > I agree with Ferruh. > > I am interested to know if there are cases where a device tree parser > would be relevant in DPDK. > Cc Jan who already worked on this idea. Hello, I don't know the details here. In general, I think it is better to always use /sys. However, there might be information in the device tree which are not exposed via /sys. This highly depends on the used driver. I was trying to use some generic driver (uio) which is very limited in many ways. I was also dealing with a specific HW configuration for FPGA where the NIC was divided into separate DMA and EMAC components. For DPDK, these would be two separate devices with not information how they are connected to each other. Such information was accessible only via the device tree. Finally, I also needed to control the PHY from DPDK. Again, information about PHY is unavailable via /sys. Regards Jan -- Jan ViktorinE-mail: vikto...@rehivetech.com System ArchitectWeb:www.RehiveTech.com RehiveTech Brno, Czech Republic
Re: [dpdk-dev] [PATCH] librte_eal: fix wrong assert for arm and ppc
On Thu, 21 Sep 2017 15:04:04 +0200
Lukasz Majczak wrote:
> The assertion of return value from the open() function is done against
> 0, while it is a correct value - open() returns -1 in case of an error.
> It causes problems while trying to run as a daemon, in which case, this
> call to open() will return 0 as a valid descriptor.
Good catch! Please add also:
Fixes: b94e5c9406b5 ("eal/arm: add CPU flags for ARMv7")
Fixes: 97523f822ba9 ("eal/arm: add CPU flags for ARMv8")
Fixes: 9ae155385686 ("eal/ppc: cpu flag checks for IBM Power")
>
> Signed-off-by: Lukasz Majczak
Acked-by: Jan Viktorin
Re: [dpdk-dev] [PATCH v2] librte_eal: fix wrong assert for arm and ppc
On Thu, 21 Sep 2017 17:59:53 +0200
Lukasz Majczak wrote:
> The assertion of return value from the open() function is done against
> 0, while it is a correct value - open() returns -1 in case of an error.
> It causes problems while trying to run as a daemon, in which case, this
> call to open() will return 0 as a valid descriptor.
I'd put an empty line here...
> Fixes: b94e5c9406b5 ("eal/arm: add CPU flags for ARMv7")
> Fixes: 97523f822ba9 ("eal/arm: add CPU flags for ARMv8")
> Fixes: 9ae155385686 ("eal/ppc: cpu flag checks for IBM Power")
>
> Signed-off-by: Lukasz Majczak
Acked-by: Jan Viktorin
[dpdk-dev] [PATCH 1/1] arm: set CONFIG_RTE_ARCH_STRICT_ALIGN=y for armv7 target
On Mon, 29 Feb 2016 16:14:58 +0100 Thomas Monjalon wrote: > 2015-12-09 16:16, Jan Viktorin: > > This patch reduces number of warnings from 53 to 40. It removes the usual > > false > > positives utilizing unaligned_uint*_t data types. > > > > Signed-off-by: Jan Viktorin > > Applied, thanks > > Jan, what is the problem with the other ARM alignment warnings? > Can they be fixed? This is the full list of warnings I can see on the current origin/master for ARMv7 (42 occurences) including examples (+10 more). The origin of all of them is: cast increases required alignment of target type [-Wcast-align] After skimming through the list, you can see that they are mostly casts to uint32_t * or something similar. I believe that all of them are OK. However, I don't know how to persuade GCC to not be angry... Probably, we can add some explicit alignment of certain structures. app/test/test_thash.c 116 rte_convert_rss_key((uint32_t *)&default_rss_key, 117 (uint32_t *)rss_key_be, RTE_DIM(default_rss_key)); build/include/test_thash.h 179 *((uint32_t *)targ->v6.src_addr + i) = 180 rte_be_to_cpu_32(*((const uint32_t *)orig->src_addr + i)); 181 *((uint32_t *)targ->v6.dst_addr + i) = 182 rte_be_to_cpu_32(*((const uint32_t *)orig->dst_addr + i)); 207 ret ^= rte_cpu_to_be_32(((const uint32_t *)rss_key)[j]) << i | 208 (uint32_t)((uint64_t)(rte_cpu_to_be_32(((const uint32_t *)rss_key)[j + 1])) >> 238 ret ^= ((const uint32_t *)rss_key)[j] << i | 239 (uint32_t)((uint64_t)(((const uint32_t *)rss_key)[j + 1]) >> (32 - i)); examples-sdk/usr/local/share/dpdk/arm-armv7a-linuxapp-gcc/include/rte_mbuf.h 1617 ((t)((char *)(m)->buf_addr + (m)->data_off + (o))) examples/l3fwd-acl/main.c 1074 next = (struct rte_acl_rule *)(route_rules + 1079 next = (struct rte_acl_rule *)(acl_rules + 1115 *pacl_base = (struct rte_acl_rule *)acl_rules; 1117 *proute_base = (struct rte_acl_rule *)route_rules; netmap_user.h 65 #define NETMAP_IF(b, o) (struct netmap_if *)((char *)(b) + (o)) 68 ((struct netmap_ring *)((char *)(nifp) + \ 72 ((struct netmap_ring *)((char *)(nifp) + \ examples/vhost/main.c 121 #define MBUF_HEADROOM_UINT32(mbuf) (*(uint32_t *)((uint8_t *)(mbuf) \ 945 return ((*(uint64_t *)ea ^ *(uint64_t *)eb) & MAC_ADDR_CMP) == 0; lib/librte_acl/acl_gen.c 391 qtrp = (uint32_t *)node->transitions; lib/librte_acl/acl_run.h 46 (*((const int32_t *)((prm)[(idx)].data + *(prm)[idx].data_index++))) lib/librte_eal/linuxapp/eal/eal_interrupts.c 150 irq_set = (struct vfio_irq_set *) irq_set_buf; 156 fd_ptr = (int *) &irq_set->data; 196 irq_set = (struct vfio_irq_set *) irq_set_buf; 239 irq_set = (struct vfio_irq_set *) irq_set_buf; 245 fd_ptr = (int *) &irq_set->data; 267 irq_set = (struct vfio_irq_set *) irq_set_buf; 293 irq_set = (struct vfio_irq_set *) irq_set_buf; 304 fd_ptr = (int *) &irq_set->data; 330 irq_set = (struct vfio_irq_set *) irq_set_buf; lib/librte_eal/linuxapp/eal/eal_pci_vfio_mp_sync.c 176 chdr = (struct cmsghdr *) chdr_buf; 209 chdr = (struct cmsghdr *) chdr_buf; 595 k = (struct rte_hash_key *) ((char *)keys + 615 k = (struct rte_hash_key *) ((char *)keys + 726 k = (struct rte_hash_key *) ((char *)keys + 749 k = (struct rte_hash_key *) ((char *)keys + 841 k = (struct rte_hash_key *) ((char *)keys + 864 k = (struct rte_hash_key *) ((char *)keys + 959 *key_slot = (const struct rte_hash_key *) ((const char *)keys + 1233 next_key = (struct rte_hash_key *) ((char *)h->key_store + lib/librte_sched/rte_bitmap.h 262 bmp = (struct rte_bitmap *) mem; 264 bmp->array1 = (uint64_t *) &mem[array1_byte_offset]; 266 bmp->array2 = (uint64_t *) &mem[array2_byte_offset]; lib/librte_sched/rte_sched.c 684 port->subport = (struct rte_sched_subport *) 687 port->pipe = (struct rte_sched_pipe *) 690 port->queue = (struct rte_sched_queue *) 693 port->queue_extra = (struct rte_sched_queue_extra *) 696 port->pipe_profiles = (struct rte_sched_pipe_profile *) 701 port->queue_array = (struct rte_mbuf **) lib/librte_vhost/vhost_user/virtio-net-user.c 433 rarp = (struct ether_arp *)(eth_hdr + 1); 527 ifr = (struct ifreq *)ifc.ifc_buf; Regards Jan
[dpdk-dev] [PATCH 1/1] arm: set CONFIG_RTE_ARCH_STRICT_ALIGN=y for armv7 target
On Mon, 29 Feb 2016 16:55:38 +0100 Jan Viktorin wrote: > On Mon, 29 Feb 2016 16:14:58 +0100 > Thomas Monjalon wrote: > > > 2015-12-09 16:16, Jan Viktorin: > > > This patch reduces number of warnings from 53 to 40. It removes the usual > > > false > > > positives utilizing unaligned_uint*_t data types. > > > > > > Signed-off-by: Jan Viktorin > > > > Applied, thanks > > > > Jan, what is the problem with the other ARM alignment warnings? > > Can they be fixed? > > This is the full list of warnings I can see on the current origin/master > for ARMv7 (42 occurences) including examples (+10 more). The origin of > all of them is: > > cast increases required alignment of target type [-Wcast-align] > > After skimming through the list, you can see that they are mostly casts > to uint32_t * or something similar. I believe that all of them are OK. > However, I don't know how to persuade GCC to not be angry... > > Probably, we can add some explicit alignment of certain structures. > [snip] > > lib/librte_vhost/vhost_user/virtio-net-user.c > 433 rarp = (struct ether_arp *)(eth_hdr + 1); > 527 ifr = (struct ifreq *)ifc.ifc_buf; Fixed recently in http://dpdk.org/browse/dpdk/commit/?id=bb66588304632a7e4a043d2921d06709d40f9ed4 > > Regards > Jan
[dpdk-dev] [RFC 1/7] eal/common: define rte_soc_* related common interface
Introduce the interface to SoC device infrastructure. A SoC device
here means a device integrated on the chip via a (simple) bus
that lacks of auto-discovery and other properties which are common
for PCI. A counterpart in the Linux Kernel would be a platform_device
(but this is not necessarily 1:1 mapping).
Systems without auto-discovery properties are described by a (Flat)
Device Tree. Device Tree is usually available on embedded systems
in /proc/device-tree. Every device has a unique path in the Device
Tree and so it identifies every such device. This path is used
to identify a device in rte_soc_addr.
Binding of drivers to devices in the Linux Kernel is often done
by matching the compatible entry in the Device Tree. As there is
no standard/generic way to read information like vendor, model, etc.
from each SoC device, we match devices by the compatible entry too.
The rte_soc_id contains an array of compatible strings telling what
each device is compatible with.
There are no DPDK-specific OS drivers for SoC devices at the moment
and unfortunately we cannot use the PCI-related ones as they contain
too much PCI-specific logic.
Whitelisting and blacklisting of devices is based on the Device Tree
identifier (rte_soc_addr) to mimic the PCI behaviour.
Signed-off-by: Jan Viktorin
---
lib/librte_eal/common/Makefile | 2 +-
lib/librte_eal/common/eal_common_devargs.c | 6 +
lib/librte_eal/common/include/rte_devargs.h | 7 +
lib/librte_eal/common/include/rte_soc.h | 210
4 files changed, 224 insertions(+), 1 deletion(-)
create mode 100644 lib/librte_eal/common/include/rte_soc.h
diff --git a/lib/librte_eal/common/Makefile b/lib/librte_eal/common/Makefile
index f5ea0ee..21326d7 100644
--- a/lib/librte_eal/common/Makefile
+++ b/lib/librte_eal/common/Makefile
@@ -33,7 +33,7 @@ include $(RTE_SDK)/mk/rte.vars.mk
INC := rte_branch_prediction.h rte_common.h
INC += rte_debug.h rte_eal.h rte_errno.h rte_launch.h rte_lcore.h
-INC += rte_log.h rte_memory.h rte_memzone.h rte_pci.h
+INC += rte_log.h rte_memory.h rte_memzone.h rte_pci.h rte_soc.h
INC += rte_pci_dev_ids.h rte_per_lcore.h rte_random.h
INC += rte_tailq.h rte_interrupts.h rte_alarm.h
INC += rte_string_fns.h rte_version.h
diff --git a/lib/librte_eal/common/eal_common_devargs.c
b/lib/librte_eal/common/eal_common_devargs.c
index 5d075d0..201f298 100644
--- a/lib/librte_eal/common/eal_common_devargs.c
+++ b/lib/librte_eal/common/eal_common_devargs.c
@@ -105,6 +105,12 @@ rte_eal_devargs_add(enum rte_devtype devtype, const char
*devargs_str)
goto fail;
break;
+ case RTE_DEVTYPE_WHITELISTED_SOC:
+ case RTE_DEVTYPE_BLACKLISTED_SOC:
+ strncpy(devargs->soc.addr.devtree_path,
+ buf, PATH_MAX);
+ /* TODO: test file exists? */
+ break;
case RTE_DEVTYPE_VIRTUAL:
/* save driver name */
ret = snprintf(devargs->virt.drv_name,
diff --git a/lib/librte_eal/common/include/rte_devargs.h
b/lib/librte_eal/common/include/rte_devargs.h
index 53c59f5..f69a553 100644
--- a/lib/librte_eal/common/include/rte_devargs.h
+++ b/lib/librte_eal/common/include/rte_devargs.h
@@ -51,6 +51,7 @@ extern "C" {
#include
#include
#include
+#include
/**
* Type of generic device
@@ -58,6 +59,8 @@ extern "C" {
enum rte_devtype {
RTE_DEVTYPE_WHITELISTED_PCI,
RTE_DEVTYPE_BLACKLISTED_PCI,
+ RTE_DEVTYPE_WHITELISTED_SOC,
+ RTE_DEVTYPE_BLACKLISTED_SOC,
RTE_DEVTYPE_VIRTUAL,
};
@@ -82,6 +85,10 @@ struct rte_devargs {
/** PCI location. */
struct rte_pci_addr addr;
} pci;
+ struct {
+ /** SoC location. */
+ struct rte_soc_addr addr;
+ } soc;
/** Used if type is RTE_DEVTYPE_VIRTUAL. */
struct {
/** Driver name. */
diff --git a/lib/librte_eal/common/include/rte_soc.h
b/lib/librte_eal/common/include/rte_soc.h
new file mode 100644
index 000..7c279b1
--- /dev/null
+++ b/lib/librte_eal/common/include/rte_soc.h
@@ -0,0 +1,210 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2016 RehiveTech. All rights reserved.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ * * Neither the name of Intel Corpor
[dpdk-dev] [RFC 2/7] eal: introduce --no-soc option
This option has the same meaning for the SoC infra as the --no-pci
for the PCI infra.
Signed-off-by: Jan Viktorin
---
lib/librte_eal/common/eal_common_options.c | 5 +
lib/librte_eal/common/eal_internal_cfg.h | 1 +
lib/librte_eal/common/eal_options.h| 2 ++
3 files changed, 8 insertions(+)
diff --git a/lib/librte_eal/common/eal_common_options.c
b/lib/librte_eal/common/eal_common_options.c
index 29942ea..c9e294c 100644
--- a/lib/librte_eal/common/eal_common_options.c
+++ b/lib/librte_eal/common/eal_common_options.c
@@ -85,6 +85,7 @@ eal_long_options[] = {
{OPT_NO_HPET, 0, NULL, OPT_NO_HPET_NUM },
{OPT_NO_HUGE, 0, NULL, OPT_NO_HUGE_NUM },
{OPT_NO_PCI,0, NULL, OPT_NO_PCI_NUM },
+ {OPT_NO_SOC,0, NULL, OPT_NO_SOC_NUM },
{OPT_NO_SHCONF, 0, NULL, OPT_NO_SHCONF_NUM},
{OPT_PCI_BLACKLIST, 1, NULL, OPT_PCI_BLACKLIST_NUM},
{OPT_PCI_WHITELIST, 1, NULL, OPT_PCI_WHITELIST_NUM},
@@ -838,6 +839,10 @@ eal_parse_common_option(int opt, const char *optarg,
conf->no_pci = 1;
break;
+ case OPT_NO_SOC_NUM:
+ conf->no_soc = 1;
+ break;
+
case OPT_NO_HPET_NUM:
conf->no_hpet = 1;
break;
diff --git a/lib/librte_eal/common/eal_internal_cfg.h
b/lib/librte_eal/common/eal_internal_cfg.h
index 5f1367e..3a98e94 100644
--- a/lib/librte_eal/common/eal_internal_cfg.h
+++ b/lib/librte_eal/common/eal_internal_cfg.h
@@ -67,6 +67,7 @@ struct internal_config {
unsigned hugepage_unlink; /**< true to unlink backing files */
volatile unsigned xen_dom0_support; /**< support app running on Xen
Dom0*/
volatile unsigned no_pci; /**< true to disable PCI */
+ volatile unsigned no_soc; /**< true to disable SoC */
volatile unsigned no_hpet;/**< true to disable HPET */
volatile unsigned vmware_tsc_map; /**< true to use VMware TSC mapping
* instead of native TSC */
diff --git a/lib/librte_eal/common/eal_options.h
b/lib/librte_eal/common/eal_options.h
index a881c62..ba1e704 100644
--- a/lib/librte_eal/common/eal_options.h
+++ b/lib/librte_eal/common/eal_options.h
@@ -69,6 +69,8 @@ enum {
OPT_NO_HUGE_NUM,
#define OPT_NO_PCI"no-pci"
OPT_NO_PCI_NUM,
+#define OPT_NO_SOC"no-soc"
+ OPT_NO_SOC_NUM,
#define OPT_NO_SHCONF "no-shconf"
OPT_NO_SHCONF_NUM,
#define OPT_SOCKET_MEM"socket-mem"
--
2.6.3
[dpdk-dev] [RFC 3/7] eal: add common part of the SoC infra
Probing and detaching of devices. The code is heavily based on the PCI infra.
Signed-off-by: Jan Viktorin
---
lib/librte_eal/common/eal_common_soc.c | 367 +
lib/librte_eal/common/eal_private.h| 12 ++
lib/librte_eal/linuxapp/eal/Makefile | 1 +
3 files changed, 380 insertions(+)
create mode 100644 lib/librte_eal/common/eal_common_soc.c
diff --git a/lib/librte_eal/common/eal_common_soc.c
b/lib/librte_eal/common/eal_common_soc.c
new file mode 100644
index 000..8a0edf3
--- /dev/null
+++ b/lib/librte_eal/common/eal_common_soc.c
@@ -0,0 +1,367 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2016 RehiveTech. All rights reserved.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "eal_private.h"
+
+struct soc_driver_list soc_driver_list;
+struct soc_device_list soc_device_list;
+
+static struct rte_devargs *soc_devargs_lookup(struct rte_soc_device *dev)
+{
+ struct rte_devargs *devargs;
+
+ TAILQ_FOREACH(devargs, &devargs_list, next) {
+ if (devargs->type != RTE_DEVTYPE_BLACKLISTED_SOC
+ && devargs->type != RTE_DEVTYPE_WHITELISTED_SOC)
+ continue;
+
+ if (!rte_eal_compare_soc_addr(&dev->addr, &devargs->soc.addr))
+ return devargs;
+ }
+
+ return NULL;
+}
+
+/* TODO: generalize and merge with PCI version */
+void *
+soc_map_resource(void *requested_addr, int fd, off_t offset, size_t size,
+ int additional_flags)
+{
+ void *mapaddr;
+
+ mapaddr = mmap(requested_addr, size, PROT_READ | PROT_WRITE,
+ MAP_SHARED | additional_flags, fd, offset);
+ if (mapaddr == MAP_FAILED) {
+ RTE_LOG(ERR, EAL, "%s(): cannot mmap(%d, %p, 0x%lx, 0x%lx): %s
(%p)\n",
+ __func__, fd, requested_addr,
+ (unsigned long)size, (unsigned long)offset,
+ strerror(errno), mapaddr);
+ } else
+ RTE_LOG(DEBUG, EAL, " SoC memory mapped at %p\n", mapaddr);
+
+ return mapaddr;
+}
+
+/* TODO: generalize and merge with PCI version */
+void
+soc_unmap_resource(void *requested_addr, size_t size)
+{
+ if (requested_addr == NULL)
+ return;
+
+ if (munmap(requested_addr, size)) {
+ RTE_LOG(ERR, EAL, "%s(): cannot munmap(%p, 0x%lx): %s\n",
+ __func__, requested_addr, (unsigned long)size,
+ strerror(errno));
+ } else
+ RTE_LOG(DEBUG, EAL, " SoC memory unmapped at %p\n",
+ requested_addr);
+}
+
+static int
+rte_eal_soc_id_match(const struct rte_soc_id *dr, const struct rte_soc_id *dev)
+{
+ int i;
+
+ if (dr == NULL || dev == NULL)
+ return 0;
+
+ if (dr->compatible == NULL || dev->compatible == NULL)
+ return 0;
+
+ for (i = 0; dr->compatible[i]; ++i) {
+ int j;
+
+ for (j = 0; dev->compatible[j]; ++j) {
+ if (!strcmp(dr->compatible[i], de
[dpdk-dev] [RFC 6/7] eal/soc: make SoC infra testable on any platform
The hardcoded constant paths to sysfs and device-tree locations
makes the SoC infra difficult to test. With this code, it is
possible to override the default path by setting the appropriate
environment variables.
A test can provide a fake sysfs and device-tree hierarchy of devices.
Signed-off-by: Jan Viktorin
---
lib/librte_eal/common/include/rte_soc.h | 6 --
lib/librte_eal/linuxapp/eal/eal_soc.c | 15 +++
2 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/lib/librte_eal/common/include/rte_soc.h
b/lib/librte_eal/common/include/rte_soc.h
index 7c279b1..d7d6827 100644
--- a/lib/librte_eal/common/include/rte_soc.h
+++ b/lib/librte_eal/common/include/rte_soc.h
@@ -56,9 +56,11 @@ extern struct soc_device_list soc_device_list;
extern struct soc_driver_list soc_driver_list;
/* Path to detect platform devices (in architecture-specific bus systems). */
-#define SYSFS_SOC_DEVICES "/sys/bus/platform/devices"
+#define SYSFS_SOC_DEVICES __sysfs_soc_devices
+extern const char *__sysfs_soc_devices;
/* Flat Device Tree location in the system. */
-#define FDT_ROOT "/proc/device-tree"
+#define FDT_ROOT __fdt_root
+extern const char *__fdt_root;
struct rte_soc_resource {
uint64_t phys_addr; /**< Physical address, 0 if no resource. */
diff --git a/lib/librte_eal/linuxapp/eal/eal_soc.c
b/lib/librte_eal/linuxapp/eal/eal_soc.c
index be0e44d..aafb9c3 100644
--- a/lib/librte_eal/linuxapp/eal/eal_soc.c
+++ b/lib/librte_eal/linuxapp/eal/eal_soc.c
@@ -46,6 +46,9 @@
#include "eal_private.h"
#include "eal_pci_init.h"
+const char *__sysfs_soc_devices = "/sys/bus/platform/devices";
+const char *__fdt_root = "/proc/device-tree";
+
int
soc_map_device(struct rte_soc_device *dev)
{
@@ -378,12 +381,24 @@ error:
int
rte_eal_soc_init(void)
{
+ char *tmp;
+
TAILQ_INIT(&soc_driver_list);
TAILQ_INIT(&soc_device_list);
if (internal_config.no_soc)
return 0;
+ if ((tmp = getenv("SYSFS_SOC_DEVICES")))
+ __sysfs_soc_devices = tmp;
+ else
+ __sysfs_soc_devices = "/sys/bus/platform/devices";
+
+ if ((tmp = getenv("FDT_ROOT")))
+ __fdt_root = tmp;
+ else
+ __fdt_root = "/proc/device-tree";
+
if (rte_eal_soc_scan() < 0) {
RTE_LOG(ERR, EAL, "%s(): Failed to scan for SoC devices\n",
__func__);
--
2.6.3
[dpdk-dev] [RFC 5/7] eal: init SoC infra on rte_eal_init
Signed-off-by: Jan Viktorin
---
lib/librte_eal/linuxapp/eal/eal.c | 4
1 file changed, 4 insertions(+)
diff --git a/lib/librte_eal/linuxapp/eal/eal.c
b/lib/librte_eal/linuxapp/eal/eal.c
index 635ec36..8a6691d 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -69,6 +69,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -785,6 +786,9 @@ rte_eal_init(int argc, char **argv)
if (rte_eal_pci_init() < 0)
rte_panic("Cannot init PCI\n");
+ if (rte_eal_soc_init() < 0)
+ rte_panic("Cannot init SoC\n");
+
#ifdef RTE_LIBRTE_IVSHMEM
if (rte_eal_ivshmem_init() < 0)
rte_panic("Cannot init IVSHMEM\n");
--
2.6.3
[dpdk-dev] [RFC 4/7] eal/linuxapp: support SoC infra in linuxapp
Provide Linux-specific discovery routines. The discovery reads the
/sys/bus/platform/devices/*/uevent file for each device. If the uevent
file contains OF_FULLNAME entry (path in the Device Tree) and a list of
OF_COMPATIBLE_# entries, it is considered as a SoC device and inserted
into the soc_device_list.
We do not care about the mem_resources at the moment. We need a proper
Linux Kernel driver to support this. Gathering of the resource information
could be done by parsing reg properties in the Device Tree.
There is a possible pitfall here, if there is a device depending on another
device (eg. an EMAC with a separate DMA engine), we cannot treat it as a
single device as the relation between whose might not be described in a
standardized way. So the drivers of the particular devices must take care of
this themselfs.
Signed-off-by: Jan Viktorin
---
lib/librte_eal/linuxapp/eal/Makefile | 2 +
lib/librte_eal/linuxapp/eal/eal_soc.c | 394 ++
2 files changed, 396 insertions(+)
create mode 100644 lib/librte_eal/linuxapp/eal/eal_soc.c
diff --git a/lib/librte_eal/linuxapp/eal/Makefile
b/lib/librte_eal/linuxapp/eal/Makefile
index f2ed696..11e2dc8 100644
--- a/lib/librte_eal/linuxapp/eal/Makefile
+++ b/lib/librte_eal/linuxapp/eal/Makefile
@@ -60,6 +60,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_EAL_LINUXAPP) += eal_pci.c
SRCS-$(CONFIG_RTE_LIBRTE_EAL_LINUXAPP) += eal_pci_uio.c
SRCS-$(CONFIG_RTE_LIBRTE_EAL_LINUXAPP) += eal_pci_vfio.c
SRCS-$(CONFIG_RTE_LIBRTE_EAL_LINUXAPP) += eal_pci_vfio_mp_sync.c
+SRCS-$(CONFIG_RTE_LIBRTE_EAL_LINUXAPP) += eal_soc.c
SRCS-$(CONFIG_RTE_LIBRTE_EAL_LINUXAPP) += eal_debug.c
SRCS-$(CONFIG_RTE_LIBRTE_EAL_LINUXAPP) += eal_lcore.c
SRCS-$(CONFIG_RTE_LIBRTE_EAL_LINUXAPP) += eal_timer.c
@@ -105,6 +106,7 @@ CFLAGS_eal_hugepage_info.o := -D_GNU_SOURCE
CFLAGS_eal_pci.o := -D_GNU_SOURCE
CFLAGS_eal_pci_uio.o := -D_GNU_SOURCE
CFLAGS_eal_pci_vfio.o := -D_GNU_SOURCE
+CFLAGS_eal_soc.o := -D_GNU_SOURCE
CFLAGS_eal_common_whitelist.o := -D_GNU_SOURCE
CFLAGS_eal_common_options.o := -D_GNU_SOURCE
CFLAGS_eal_common_thread.o := -D_GNU_SOURCE
diff --git a/lib/librte_eal/linuxapp/eal/eal_soc.c
b/lib/librte_eal/linuxapp/eal/eal_soc.c
new file mode 100644
index 000..be0e44d
--- /dev/null
+++ b/lib/librte_eal/linuxapp/eal/eal_soc.c
@@ -0,0 +1,394 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2016 RehiveTech. All rights reserved.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "eal_filesystem.h"
+#include "eal_private.h"
+#include "eal_pci_init.h"
+
+int
+soc_map_device(struct rte_soc_device *dev)
+{
+ int rc = -1;
+
+ switch (dev->kdrv) {
+ case RTE_SOC_KDRV_NONE:
+ rc = 0;
+ break;
+ default:
+ RTE_LOG(DEBUG, EAL,
+ " Not managed by a supported kernel driver,
skipped\n");
+ rc = 1;
+ break;
+ }
+
+ return rc;
+}
+
+void
+soc_unmap_device(struct rte_soc_device *dev)
+{
+ switch (dev->kdrv) {
+ case RTE_SOC_KDRV_NONE:
+ break;
+ default:
+ RTE_LOG(DEBUG, EAL,
+ " Not managed by a supported kernel driver,
skipped\n");
+ break;
