RE: [PATCH v1 0/5] Direct re-arming of buffers on receive side
> From: Konstantin Ananyev [mailto:konstantin.v.anan...@yandex.ru] > Sent: Saturday, 4 June 2022 01.32 > > > > >>> > > [konstantin.v.anan...@yandex.ru appears similar to someone who > previously sent you email, but may not be that person. Learn why > this > could be a risk at https://aka.ms/LearnAboutSenderIdentification.] > > 16/05/2022 07:10, Feifei Wang пишет: > > > >>> Currently, the transmit side frees the buffers into the lcore > >>> cache and the receive side allocates buffers from the lcore > cache. > >>> The transmit side typically frees 32 buffers resulting in > >>> 32*8=256B of stores to lcore cache. The receive side allocates > 32 > >>> buffers and stores them in the receive side software ring, > >>> resulting in 32*8=256B of stores and 256B of load from the > lcore cache. > >>> > >>> This patch proposes a mechanism to avoid freeing to/allocating > >>> from the lcore cache. i.e. the receive side will free the > buffers > >>> from transmit side directly into it's software ring. This will > >>> avoid the 256B of loads and stores introduced by the lcore > cache. > >>> It also frees up the cache lines used by the lcore cache. > >>> > >>> However, this solution poses several constraints: > >>> > >>> 1)The receive queue needs to know which transmit queue it > should > >>> take the buffers from. The application logic decides which > >>> transmit port to use to send out the packets. In many use cases > >>> the NIC might have a single port ([1], [2], [3]), in which case > a > >>> given transmit queue is always mapped to a single receive queue > >>> (1:1 Rx queue: Tx queue). This is easy to configure. > >>> > >>> If the NIC has 2 ports (there are several references), then we > >>> will have > >>> 1:2 (RX queue: TX queue) mapping which is still easy to > configure. > >>> However, if this is generalized to 'N' ports, the configuration > >>> can be long. More over the PMD would have to scan a list of > >>> transmit queues to pull the buffers from. > > > >> Just to re-iterate some generic concerns about this proposal: > >> - We effectively link RX and TX queues - when this feature > is enabled, > >> user can't stop TX queue without stopping linked RX queue > first. > >> Right now user is free to start/stop any queues at his > will. > >> If that feature will allow to link queues from different > ports, > >> then even ports will become dependent and user will have > to pay extra > >> care when managing such ports. > > > > [Feifei] When direct rearm enabled, there are two path for thread > to > > choose. If there are enough Tx freed buffers, Rx can put buffers > > from Tx. > > Otherwise, Rx will put buffers from mempool as usual. Thus, users > do > > not need to pay much attention managing ports. > > What I am talking about: right now different port or different > queues > of the same port can be treated as independent entities: > in general user is free to start/stop (and even reconfigure in > some > cases) one entity without need to stop other entity. > I.E user can stop and re-configure TX queue while keep receiving > packets from RX queue. > With direct re-arm enabled, I think it wouldn't be possible any > more: > before stopping/reconfiguring TX queue user would have make sure > that > corresponding RX queue wouldn't be used by datapath. > >>> I am trying to understand the problem better. For the TX queue to > be stopped, > >> the user must have blocked the data plane from accessing the TX > queue. > >> > >> Surely it is user responsibility tnot to call tx_burst() for > stopped/released queue. > >> The problem is that while TX for that queue is stopped, RX for > related queue still > >> can continue. > >> So rx_burst() will try to read/modify TX queue data, that might be > already freed, > >> or simultaneously modified by control path. > > Understood, agree on the issue > > > >> > >> Again, it all can be mitigated by carefully re-designing and > modifying control and > >> data-path inside user app - by doing extra checks and > synchronizations, etc. > >> But from practical point - I presume most of users simply would > avoid using this > >> feature due all potential problems it might cause. > > That is subjective, it all depends on the performance improvements > users see in their application. > > IMO, the performance improvement seen with this patch is worth few > changes. > > Yes, it is subjective till some extent, though my feeling > that it might end-up being sort of synthetic improvement used only > by some show-case benchmarks. I believe that one specific important use case has already been mentioned, so I don't think this is a benchmark only feature. > From my perspective, it would be much more plausible, > if w
[PATCH] test/hash: avoid out of bound access
rwc_non_lf_results->multi_rw, rwc_lf_results->multi_rw, and
rwc_perf_results->multi_rw are accessed at indexes
[0..NUM_TEST-1][0..1][0..NUMTEST-1]. Currently the first index
overflows the array size in struct rwc_perf.
Fixes: c7eb0972e74b ("test/test/test_hash_readwrite_lf.c")
Cc: Dharmik Thakkar
Cc: sta...@dpdk.org
Signed-off-by: Heinrich Schuchardt
---
app/test/test_hash_readwrite_lf_perf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/app/test/test_hash_readwrite_lf_perf.c
b/app/test/test_hash_readwrite_lf_perf.c
index 8120cf43be..32f9ec9250 100644
--- a/app/test/test_hash_readwrite_lf_perf.c
+++ b/app/test/test_hash_readwrite_lf_perf.c
@@ -59,7 +59,7 @@ struct rwc_perf {
uint32_t w_ks_r_hit_nsp[2][NUM_TEST];
uint32_t w_ks_r_hit_sp[2][NUM_TEST];
uint32_t w_ks_r_miss[2][NUM_TEST];
- uint32_t multi_rw[NUM_TEST - 1][2][NUM_TEST];
+ uint32_t multi_rw[NUM_TEST][2][NUM_TEST];
uint32_t w_ks_r_hit_extbkt[2][NUM_TEST];
uint32_t writer_add_del[NUM_TEST];
};
--
2.36.1
Optimizations are not features
I would like the DPDK community to change its view on compile time options. Here is why: Application specific performance micro-optimizations like "fast mbuf free" and "mbuf direct re-arm" are being added to DPDK and presented as features. They are not features, but optimizations, and I don't understand the need for them to be available at run-time! Instead of adding a bunch of exotic exceptions to the fast path of the PMDs, they should be compile time options. This will improve performance by avoiding branches in the fast path, both for the applications using them, and for generic applications (where the exotic code is omitted). Please note that I am only talking about the performance optimizations that are limited to application specific use cases. I think it makes sense to require that performance optimizing an application also requires recompiling the performance critical libraries used by it. Allowing compile time options for application specific performance optimizations in DPDK would also open a path for other optimizations, which can only be achieved at compile time, such as "no fragmented packets", "no attached mbufs" and "single mbuf pool". And even more exotic optimizations, such as the "indexed mempool cache", which was rejected due to ABI violations - they could be marked as "risky and untested" or similar, but still be part of the DPDK main repository. Med venlig hilsen / Kind regards, -Morten Brørup
Re: Optimizations are not features
On Sat, Jun 4, 2022 at 2:39 PM Morten Brørup wrote: > > I would like the DPDK community to change its view on compile time options. > Here is why: > > > > Application specific performance micro-optimizations like “fast mbuf free” > and “mbuf direct re-arm” are being added to DPDK and presented as features. > > > > They are not features, but optimizations, and I don’t understand the need for > them to be available at run-time! > > > > Instead of adding a bunch of exotic exceptions to the fast path of the PMDs, > they should be compile time options. This will improve performance by > avoiding branches in the fast path, both for the applications using them, and > for generic applications (where the exotic code is omitted). Agree. I think, keeping the best of both worlds would be -Enable the feature/optimization as runtime -Have a compile-time option to disable the feature/optimization as an override. > > > > Please note that I am only talking about the performance optimizations that > are limited to application specific use cases. I think it makes sense to > require that performance optimizing an application also requires recompiling > the performance critical libraries used by it. > > > > Allowing compile time options for application specific performance > optimizations in DPDK would also open a path for other optimizations, which > can only be achieved at compile time, such as “no fragmented packets”, “no > attached mbufs” and “single mbuf pool”. And even more exotic optimizations, > such as the “indexed mempool cache”, which was rejected due to ABI violations > – they could be marked as “risky and untested” or similar, but still be part > of the DPDK main repository. > > > > > > Med venlig hilsen / Kind regards, > > -Morten Brørup > >
Re: RFC: adapter instance get api proposal
On Fri, Jun 3, 2022 at 9:47 PM Kundapura, Ganapati wrote: > > Hi dpdk-dev, > >I would like to submit adapter instance get api to retrieve the Rx/Tx > adapter instance id for for a Rx/Tx queue > > > > int > > rte_event_eth_rx_adapter_queue_instance_get(uint16_t eth_dev_id, > > uint16_t rx_queue_id, uint8_t > *instance_id) > > > > and > > > > int > > rte_event_eth_tx_adapter_queue_instance_get(uint16_t eth_dev_id, > > uint16_t tx_queue_id, uint8_t > *instance_id) > > > > When application creates multiple adapter instances and adds queues to > different adapter instances, > > It’s difficult to maintain which queue belongs to which adapter instance. > > > > With this api, application need not manage the instance id’s for the queues. > It can query the > > Instance id for the specified queue. > > > > I look forward feedback on this proposal to submit patch for the review. I hope it will be a common code that all PMD can use. You may reduce the length of function as rte_event_eth_tx_adapter_instance_get() IMO, Rest looks good > > > > Thanks, > > Ganapati
Re: Optimizations are not features
On 6/4/22 12:33, Jerin Jacob wrote: On Sat, Jun 4, 2022 at 2:39 PM Morten Brørup wrote: I would like the DPDK community to change its view on compile time options. Here is why: Application specific performance micro-optimizations like “fast mbuf free” and “mbuf direct re-arm” are being added to DPDK and presented as features. They are not features, but optimizations, and I don’t understand the need for them to be available at run-time! Instead of adding a bunch of exotic exceptions to the fast path of the PMDs, they should be compile time options. This will improve performance by avoiding branches in the fast path, both for the applications using them, and for generic applications (where the exotic code is omitted). Agree. I think, keeping the best of both worlds would be -Enable the feature/optimization as runtime -Have a compile-time option to disable the feature/optimization as an override. It is hard to find the right balance, but in general compile time options are a nightmare for maintenance. Number of required builds will grow as an exponent. Of course, we can limit number of checked combinations, but it will result in flow of patches to fix build in other cases. Also compile time options tend to make code less readable which makes all aspects of the development harder. Yes, compile time is nice for micro optimizations, but I have great concerns that it is a right way to go. Please note that I am only talking about the performance optimizations that are limited to application specific use cases. I think it makes sense to require that performance optimizing an application also requires recompiling the performance critical libraries used by it. Allowing compile time options for application specific performance optimizations in DPDK would also open a path for other optimizations, which can only be achieved at compile time, such as “no fragmented packets”, “no attached mbufs” and “single mbuf pool”. And even more exotic optimizations, such as the “indexed mempool cache”, which was rejected due to ABI violations – they could be marked as “risky and untested” or similar, but still be part of the DPDK main repository. Med venlig hilsen / Kind regards, -Morten Brørup
Re: Optimizations are not features
On Sat, Jun 4, 2022 at 3:30 PM Andrew Rybchenko
wrote:
>
> On 6/4/22 12:33, Jerin Jacob wrote:
> > On Sat, Jun 4, 2022 at 2:39 PM Morten Brørup
> > wrote:
> >>
> >> I would like the DPDK community to change its view on compile time
> >> options. Here is why:
> >>
> >>
> >>
> >> Application specific performance micro-optimizations like “fast mbuf free”
> >> and “mbuf direct re-arm” are being added to DPDK and presented as features.
> >>
> >>
> >>
> >> They are not features, but optimizations, and I don’t understand the need
> >> for them to be available at run-time!
> >>
> >>
> >>
> >> Instead of adding a bunch of exotic exceptions to the fast path of the
> >> PMDs, they should be compile time options. This will improve performance
> >> by avoiding branches in the fast path, both for the applications using
> >> them, and for generic applications (where the exotic code is omitted).
> >
> > Agree. I think, keeping the best of both worlds would be
> >
> > -Enable the feature/optimization as runtime
> > -Have a compile-time option to disable the feature/optimization as an
> > override.
>
> It is hard to find the right balance, but in general compile
> time options are a nightmare for maintenance. Number of
> required builds will grow as an exponent. Of course, we can
> limit number of checked combinations, but it will result in
> flow of patches to fix build in other cases.
The build breakage can be fixed if we use (2) vs (1)
1)
#ifdef ...
My feature
#endif
2)
static __rte_always_inline int
rte_has_xyz_feature(void)
{
#ifdef RTE_LIBRTE_XYZ_FEATURE
return RTE_LIBRTE_XYZ_FEATURE;
#else
return 0;
#endif
}
if(rte_has_xyz_feature())) {
My feature code
}
> Also compile time options tend to make code less readable
> which makes all aspects of the development harder.
>
> Yes, compile time is nice for micro optimizations, but
> I have great concerns that it is a right way to go.
>
> >> Please note that I am only talking about the performance optimizations
> >> that are limited to application specific use cases. I think it makes sense
> >> to require that performance optimizing an application also requires
> >> recompiling the performance critical libraries used by it.
> >>
> >>
> >>
> >> Allowing compile time options for application specific performance
> >> optimizations in DPDK would also open a path for other optimizations,
> >> which can only be achieved at compile time, such as “no fragmented
> >> packets”, “no attached mbufs” and “single mbuf pool”. And even more exotic
> >> optimizations, such as the “indexed mempool cache”, which was rejected due
> >> to ABI violations – they could be marked as “risky and untested” or
> >> similar, but still be part of the DPDK main repository.
> >>
> >>
> >>
> >>
> >>
> >> Med venlig hilsen / Kind regards,
> >>
> >> -Morten Brørup
> >>
> >>
>
Re: [PATCH] ip_frag: add IPv4 fast fragment switch and test data
04/06/2022 03:19, Huichao Cai пишет: I've seen some applications that have to rewrite fragment functions themselves in order to use MBUF_FAST_FREE features, such as iQiYi's DPVS. I am not sure that it will really help to improve performance, as if you have a lot of packets to fragment, you'll probably spend more time copying them. Might be it will help somehow if you'll have very rare occurrence of such packets. Also please keep in mind, that ip_frag is not the only one that does use indirect mbufs and refcnt. As another example - GSO implementation. So application writer has to be extremely careful when enabling MBUF_FAST_FREE. My personal advice - just don't use it, though I am quite conservative here. Anyway, as I said before, if there is a real use-case for it - I am ok to introduce new function that would do copying while fragmenting. Konstantin
RE: Optimizations are not features
> From: Jerin Jacob [mailto:jerinjac...@gmail.com]
> Sent: Saturday, 4 June 2022 13.10
>
> On Sat, Jun 4, 2022 at 3:30 PM Andrew Rybchenko
> wrote:
> >
> > On 6/4/22 12:33, Jerin Jacob wrote:
> > > On Sat, Jun 4, 2022 at 2:39 PM Morten Brørup
> wrote:
> > >>
> > >> I would like the DPDK community to change its view on compile time
> options. Here is why:
> > >>
> > >>
> > >>
> > >> Application specific performance micro-optimizations like “fast
> mbuf free” and “mbuf direct re-arm” are being added to DPDK and
> presented as features.
> > >>
> > >>
> > >>
> > >> They are not features, but optimizations, and I don’t understand
> the need for them to be available at run-time!
> > >>
> > >>
> > >>
> > >> Instead of adding a bunch of exotic exceptions to the fast path of
> the PMDs, they should be compile time options. This will improve
> performance by avoiding branches in the fast path, both for the
> applications using them, and for generic applications (where the exotic
> code is omitted).
> > >
> > > Agree. I think, keeping the best of both worlds would be
> > >
> > > -Enable the feature/optimization as runtime
> > > -Have a compile-time option to disable the feature/optimization as
> an override.
> >
> > It is hard to find the right balance, but in general compile
> > time options are a nightmare for maintenance. Number of
> > required builds will grow as an exponent.
Test combinations are exponential for N features, regardless if N are runtime
or compile time options.
> > Of course, we can
> > limit number of checked combinations, but it will result in
> > flow of patches to fix build in other cases.
>
> The build breakage can be fixed if we use (2) vs (1)
>
> 1)
> #ifdef ...
> My feature
> #endif
>
> 2)
> static __rte_always_inline int
> rte_has_xyz_feature(void)
> {
> #ifdef RTE_LIBRTE_XYZ_FEATURE
> return RTE_LIBRTE_XYZ_FEATURE;
> #else
> return 0;
> #endif
> }
>
> if(rte_has_xyz_feature())) {
> My feature code
>
> }
>
I'm not sure all the features can be covered by that, e.g. added fields in
structures.
Also, I would consider such features "opt in" at compile time only. As such,
they could be allowed to break the ABI/API.
>
>
> > Also compile time options tend to make code less readable
> > which makes all aspects of the development harder.
> >
> > Yes, compile time is nice for micro optimizations, but
> > I have great concerns that it is a right way to go.
> >
> > >> Please note that I am only talking about the performance
> optimizations that are limited to application specific use cases. I
> think it makes sense to require that performance optimizing an
> application also requires recompiling the performance critical
> libraries used by it.
> > >>
> > >>
> > >>
> > >> Allowing compile time options for application specific performance
> optimizations in DPDK would also open a path for other optimizations,
> which can only be achieved at compile time, such as “no fragmented
> packets”, “no attached mbufs” and “single mbuf pool”. And even more
> exotic optimizations, such as the “indexed mempool cache”, which was
> rejected due to ABI violations – they could be marked as “risky and
> untested” or similar, but still be part of the DPDK main repository.
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> Med venlig hilsen / Kind regards,
> > >>
> > >> -Morten Brørup
> > >>
> > >>
> >
Re: [PATCH v4 3/7] ethdev: introduce Rx queue based fill threshold
On 6/3/22 15:48, Spike Du wrote:
Fill threshold describes the fullness of a Rx queue. If the Rx
queue fullness is above the threshold, the device will trigger the event
RTE_ETH_EVENT_RX_FILL_THRESH.
Sorry, I'm not sure that I understand. As far as I know the process to
add more Rx buffers to Rx queue is called 'refill' in many drivers. So
fill level is a number (or percentage) of free buffers in an Rx queue.
If so, fill threashold should be a minimum fill level and below the
level we should generate an event.
However reading the first paragraph of the descrition it looks like you
mean oposite thing - a number (or percentage) of ready Rx buffers with
received packets.
I think that the term "fill threshold" is suggested by me, but I did it
with mine understanding of the added feature. Now I'm confused.
Moreover, I don't understand how "fill threshold" could be in terms of
ready Rx buffers. HW simply don't really know when ready Rx buffers are
processed by SW. So, HW can't say for sure how many ready Rx buffers are
pending. It could be calculated as Rx queue size minus number of free Rx
buffers, but it is imprecise. First of all not all Rx descriptors could
be used. Second, HW ring size could differ queue size specified in SW.
Queue size specified in SW could just limit maximum nubmer of free Rx
buffers provided by the driver.
Fill threshold is defined as a percentage of Rx queue size with valid
value of [0,99].
Setting fill threshold to 0 means disable it, which is the default.
Add fill threshold configuration and query driver callbacks in eth_dev_ops.
Add command line options to support fill_thresh per-rxq configure.
- Command syntax:
set port rxq fill_thresh
- Example commands:
To configure fill_thresh as 30% of rxq size on port 1 rxq 0:
testpmd> set port 1 rxq 0 fill_thresh 30
To disable fill_thresh on port 1 rxq 0:
testpmd> set port 1 rxq 0 fill_thresh 0
Signed-off-by: Spike Du
---
app/test-pmd/cmdline.c | 68 +++
app/test-pmd/config.c | 21 ++
app/test-pmd/testpmd.c | 18
app/test-pmd/testpmd.h | 2 ++
lib/ethdev/ethdev_driver.h | 22 ++
lib/ethdev/rte_ethdev.c| 52 +
lib/ethdev/rte_ethdev.h| 72 ++
lib/ethdev/version.map | 2 ++
8 files changed, 257 insertions(+)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 0410bad..918581e 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -17823,6 +17823,73 @@ struct cmd_show_port_flow_transfer_proxy_result {
}
};
+/* *** SET FILL THRESHOLD FOR A RXQ OF A PORT *** */
+struct cmd_rxq_fill_thresh_result {
+ cmdline_fixed_string_t set;
+ cmdline_fixed_string_t port;
+ uint16_t port_num;
+ cmdline_fixed_string_t rxq;
+ uint16_t rxq_num;
+ cmdline_fixed_string_t fill_thresh;
+ uint16_t fill_thresh_num;
uint8_t to be consistent with ethdev
+};
+
+static void cmd_rxq_fill_thresh_parsed(void *parsed_result,
+ __rte_unused struct cmdline *cl,
+ __rte_unused void *data)
+{
+ struct cmd_rxq_fill_thresh_result *res = parsed_result;
+ int ret = 0;
+
+ if ((strcmp(res->set, "set") == 0) && (strcmp(res->port, "port") == 0)
+ && (strcmp(res->rxq, "rxq") == 0)
+ && (strcmp(res->fill_thresh, "fill_thresh") == 0))
+ ret = set_rxq_fill_thresh(res->port_num, res->rxq_num,
+ res->fill_thresh_num);
+ if (ret < 0)
+ printf("rxq_fill_thresh_cmd error: (%s)\n", strerror(-ret));
+
+}
+
+cmdline_parse_token_string_t cmd_rxq_fill_thresh_set =
+ TOKEN_STRING_INITIALIZER(struct cmd_rxq_fill_thresh_result,
+ set, "set");
+cmdline_parse_token_string_t cmd_rxq_fill_thresh_port =
+ TOKEN_STRING_INITIALIZER(struct cmd_rxq_fill_thresh_result,
+ port, "port");
+cmdline_parse_token_num_t cmd_rxq_fill_thresh_portnum =
+ TOKEN_NUM_INITIALIZER(struct cmd_rxq_fill_thresh_result,
+ port_num, RTE_UINT16);
+cmdline_parse_token_string_t cmd_rxq_fill_thresh_rxq =
+ TOKEN_STRING_INITIALIZER(struct cmd_rxq_fill_thresh_result,
+ rxq, "rxq");
+cmdline_parse_token_num_t cmd_rxq_fill_thresh_rxqnum =
+ TOKEN_NUM_INITIALIZER(struct cmd_rxq_fill_thresh_result,
+ rxq_num, RTE_UINT8);
RTE_UINT16 since it is an Rx queue ID
+cmdline_parse_token_string_t cmd_rxq_fill_thresh_fill_thresh =
+ TOKEN_STRING_INITIALIZER(struct cmd_rxq_fill_thresh_result,
+ fill_thresh, "fill_thresh");
+cmdline_parse_token_num_t cmd_rxq_fill_thresh_fill_threshnum =
+ TOKEN_NUM_INITIALIZER(struct cmd_rxq_fill_thresh_result,
+ fill_thresh_num, RTE_UINT16);
RTE_UIN
Re: Optimizations are not features
On 6/4/22 15:19, Morten Brørup wrote:
From: Jerin Jacob [mailto:jerinjac...@gmail.com]
Sent: Saturday, 4 June 2022 13.10
On Sat, Jun 4, 2022 at 3:30 PM Andrew Rybchenko
wrote:
On 6/4/22 12:33, Jerin Jacob wrote:
On Sat, Jun 4, 2022 at 2:39 PM Morten Brørup
wrote:
I would like the DPDK community to change its view on compile time
options. Here is why:
Application specific performance micro-optimizations like “fast
mbuf free” and “mbuf direct re-arm” are being added to DPDK and
presented as features.
They are not features, but optimizations, and I don’t understand
the need for them to be available at run-time!
Instead of adding a bunch of exotic exceptions to the fast path of
the PMDs, they should be compile time options. This will improve
performance by avoiding branches in the fast path, both for the
applications using them, and for generic applications (where the exotic
code is omitted).
Agree. I think, keeping the best of both worlds would be
-Enable the feature/optimization as runtime
-Have a compile-time option to disable the feature/optimization as
an override.
It is hard to find the right balance, but in general compile
time options are a nightmare for maintenance. Number of
required builds will grow as an exponent.
Test combinations are exponential for N features, regardless if N are runtime
or compile time options.
But since I'm talking about build checks I don't care about exponential
grows in run time. Yes, testing should care, but it is a separate story.
Of course, we can
limit number of checked combinations, but it will result in
flow of patches to fix build in other cases.
The build breakage can be fixed if we use (2) vs (1)
1)
#ifdef ...
My feature
#endif
2)
static __rte_always_inline int
rte_has_xyz_feature(void)
{
#ifdef RTE_LIBRTE_XYZ_FEATURE
return RTE_LIBRTE_XYZ_FEATURE;
#else
return 0;
#endif
}
if(rte_has_xyz_feature())) {
My feature code
}
Jerin, thanks, very good example.
I'm not sure all the features can be covered by that, e.g. added fields in
structures.
+1
Also, I would consider such features "opt in" at compile time only. As such,
they could be allowed to break the ABI/API.
Also compile time options tend to make code less readable
which makes all aspects of the development harder.
Yes, compile time is nice for micro optimizations, but
I have great concerns that it is a right way to go.
Please note that I am only talking about the performance
optimizations that are limited to application specific use cases. I
think it makes sense to require that performance optimizing an
application also requires recompiling the performance critical
libraries used by it.
Allowing compile time options for application specific performance
optimizations in DPDK would also open a path for other optimizations,
which can only be achieved at compile time, such as “no fragmented
packets”, “no attached mbufs” and “single mbuf pool”. And even more
exotic optimizations, such as the “indexed mempool cache”, which was
rejected due to ABI violations – they could be marked as “risky and
untested” or similar, but still be part of the DPDK main repository.
Med venlig hilsen / Kind regards,
-Morten Brørup
Re: ixgbevf in dpdk doesn't seems to work (dpdk-stable-19.11.5)
Hi, I am blocked for almost 2 weeks now, I have browsed ixgbevf driver code but couldn't get any clue. kindly help me with this issue. Regards,Mohan On Friday, 3 June, 2022, 02:29:58 pm IST, Bruce Richardson wrote: + ixgbe maintainers on CC On Fri, Jun 03, 2022 at 08:14:00AM +, Mohan Gyara wrote: > Hi Team, > In our application we use 2 interfaces one to communicate towards gNB > and another to communicate with higher layers in a UE simulator NR > stack. Now we use a PCI whose driver is i40e and is bind to dpdk > vfio-pci driver and this works perfectly towards higher layer, but the > other interface PCI whose is ixgbe driver is bind to vfio-pci dpdk > driver and has some issues. > The issues are: > 1. Application crashes when "rte_eth_dev_mac_addr_add" function is > called when return with -1. > "on a 82599 VF, adding again the same MAC addr is not an idempotent > operation..." this is a comment, but the function ixgbevf_add_mac_addr > return -1 when memcmp(hw->mac.perm_addr, mac_addr) == 0) is true. > But above I commented the "return -1" and just returned from it, so > crash is not seen. > 2. After above 1, application is started successfully but then I do not > see any messages coming on this interface. This is the problem? > Could you guide me what is the issue? I see only issue with ixgbvf but > not for i40evf. > I am using dpdk-stable-19.11.5 version. > Kindly help me here. > Regards, > Mohan
[PATCH] raw/cnxk_gpio: allow controlling existing GPIO
Controlling existing GPIO should be normally frowned upon because
we want to avoid situation where multiple contenders modify GPIO
state simultaneously.
Still there might be situations where this is actually needed.
Restarting killed application being an example here.
So relax current restrictions and respect user needs.
Signed-off-by: Tomasz Duszynski
---
drivers/raw/cnxk_gpio/cnxk_gpio.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/raw/cnxk_gpio/cnxk_gpio.c
b/drivers/raw/cnxk_gpio/cnxk_gpio.c
index 9577753851..d759ed82d4 100644
--- a/drivers/raw/cnxk_gpio/cnxk_gpio.c
+++ b/drivers/raw/cnxk_gpio/cnxk_gpio.c
@@ -4,6 +4,7 @@
#include
#include
+#include
#include
#include
@@ -277,6 +278,17 @@ cnxk_gpio_lookup(struct cnxk_gpiochip *gpiochip, uint16_t
queue)
return gpiochip->gpios[gpio];
}
+static bool
+cnxk_gpio_exists(int num)
+{
+ char buf[CNXK_GPIO_BUFSZ];
+ struct stat st;
+
+ snprintf(buf, sizeof(buf), "%s/gpio%d", CNXK_GPIO_CLASS_PATH, num);
+
+ return !stat(buf, &st);
+}
+
static int
cnxk_gpio_queue_setup(struct rte_rawdev *dev, uint16_t queue_id,
rte_rawdev_obj_t queue_conf, size_t queue_conf_size)
@@ -304,11 +316,15 @@ cnxk_gpio_queue_setup(struct rte_rawdev *dev, uint16_t
queue_id,
gpio->num = num + gpiochip->base;
gpio->gpiochip = gpiochip;
- snprintf(buf, sizeof(buf), "%s/export", CNXK_GPIO_CLASS_PATH);
- ret = cnxk_gpio_write_attr_int(buf, gpio->num);
- if (ret) {
- rte_free(gpio);
- return ret;
+ if (!cnxk_gpio_exists(gpio->num)) {
+ snprintf(buf, sizeof(buf), "%s/export", CNXK_GPIO_CLASS_PATH);
+ ret = cnxk_gpio_write_attr_int(buf, gpio->num);
+ if (ret) {
+ rte_free(gpio);
+ return ret;
+ }
+ } else {
+ RTE_LOG(WARNING, PMD, "using existing gpio%d\n", gpio->num);
}
gpiochip->gpios[num] = gpio;
--
2.25.1
Re: [PATCH v8 1/3] ethdev: introduce protocol hdr based buffer split
On 6/3/22 19:30, Ding, Xuan wrote:
Hi Andrew,
-Original Message-
From: Andrew Rybchenko
Sent: Thursday, June 2, 2022 9:21 PM
To: Wu, WenxuanX ; tho...@monjalon.net; Li,
Xiaoyun ; ferruh.yi...@xilinx.com; Singh, Aman Deep
; dev@dpdk.org; Zhang, Yuying
; Zhang, Qi Z ;
jerinjac...@gmail.com
Cc: step...@networkplumber.org; Ding, Xuan ;
Wang, YuanX ; Ray Kinsella
Subject: Re: [PATCH v8 1/3] ethdev: introduce protocol hdr based buffer split
Is it the right one since it is listed in patchwork?
Yes, it is.
On 6/1/22 16:50, wenxuanx...@intel.com wrote:
From: Wenxuan Wu
Currently, Rx buffer split supports length based split. With Rx queue
offload RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT enabled and Rx packet
segment
configured, PMD will be able to split the received packets into
multiple segments.
However, length based buffer split is not suitable for NICs that do
split based on protocol headers. Given a arbitrarily variable length
in Rx packet
a -> an
Thanks for your catch, will fix it in next version.
segment, it is almost impossible to pass a fixed protocol header to PMD.
Besides, the existence of tunneling results in the composition of a
packet is various, which makes the situation even worse.
This patch extends current buffer split to support protocol header
based buffer split. A new proto_hdr field is introduced in the
reserved field of rte_eth_rxseg_split structure to specify protocol
header. The proto_hdr field defines the split position of packet,
splitting will always happens after the protocol header defined in the
Rx packet segment. When Rx queue offload
RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT is enabled and corresponding
protocol
header is configured, PMD will split the ingress packets into multiple
segments.
struct rte_eth_rxseg_split {
struct rte_mempool *mp; /* memory pools to allocate segment from
*/
uint16_t length; /* segment maximal data length,
configures "split point" */
uint16_t offset; /* data offset from beginning
of mbuf data buffer */
uint32_t proto_hdr; /* inner/outer L2/L3/L4 protocol header,
configures "split point" */
};
Both inner and outer L2/L3/L4 level protocol header split can be supported.
Corresponding protocol header capability is RTE_PTYPE_L2_ETHER,
RTE_PTYPE_L3_IPV4, RTE_PTYPE_L3_IPV6, RTE_PTYPE_L4_TCP,
RTE_PTYPE_L4_UDP, RTE_PTYPE_L4_SCTP, RTE_PTYPE_INNER_L2_ETHER,
RTE_PTYPE_INNER_L3_IPV4, RTE_PTYPE_INNER_L3_IPV6,
RTE_PTYPE_INNER_L4_TCP, RTE_PTYPE_INNER_L4_UDP,
RTE_PTYPE_INNER_L4_SCTP.
For example, let's suppose we configured the Rx queue with the
following segments:
seg0 - pool0, proto_hdr0=RTE_PTYPE_L3_IPV4, off0=2B
seg1 - pool1, proto_hdr1=RTE_PTYPE_L4_UDP, off1=128B
seg2 - pool2, off1=0B
The packet consists of MAC_IPV4_UDP_PAYLOAD will be split like
following:
seg0 - ipv4 header @ RTE_PKTMBUF_HEADROOM + 2 in mbuf from
pool0
seg1 - udp header @ 128 in mbuf from pool1
seg2 - payload @ 0 in mbuf from pool2
It must be defined how ICMPv4 packets will be split in such case.
And how UDP over IPv6 will be split.
The ICMP header type is missed, I will define the expected split behavior and
add it in next version, thanks for your catch.
In fact, the buffer split based on protocol header depends on the driver
parsing result.
As long as driver can recognize this packet type, I think there is no
difference between
UDP over IPV4 and UDP over IPV6?
We can bind it to ptypes recognized by the HW+driver, but I can
easily imagine the case when HW has no means to report recognized
packet type (i.e. ptype get returns empty list), but still could
split on it.
Also, nobody guarantees that there is no different in UDP over IPv4 vs
IPv6 recognition and split. IPv6 could have a number of extension
headers which could be not that trivial to hop in HW. So, HW could
recognize IPv6, but not protocols after it.
Also it is very interesting question how to define protocol split
for IPv6 plus extension headers. Where to stop?
Now buffet split can be configured in two modes. For length based
buffer split, the mp, length, offset field in Rx packet segment should
be configured, while the proto_hdr field should not be configured.
For protocol header based buffer split, the mp, offset, proto_hdr
field in Rx packet segment should be configured, while the length
field should not be configured.
The split limitations imposed by underlying PMD is reported in the
rte_eth_dev_info->rx_seg_capa field. The memory attributes for the
split parts may differ either, dpdk memory and external memory,
respectively.
Signed-off-by: Xuan Ding
Signed-off-by: Yuan Wang
Signed-off-by: Wenxuan Wu
Reviewed-by: Qi Zhang
Acked-by: Ray Kinsella
---
lib/ethdev/rte_ethdev.c | 40 +---
lib/ethdev/rte_ethdev.h | 28 +++-
2 files changed, 60 insertion
[PATCH 00/10] Sync BPHY changes
This series is a mixture of new features and improvements that have piled up during development phase. As for the features support for CPRI/eCPRI management was introduced, both for older and newer platforms. Along with that comes bunch of improvements and code cleanups. Jakub Palider (1): raw/cnxk_bphy: add doxygen comments Tomasz Duszynski (9): common/cnxk: update register access for CNF10xxN common/cnxk: use wider mask to extract RPM ID common/cnxk: don't switch affinity back and forth raw/cnxk_bphy: support switching from eCPRI to CPRI raw/cnxk_bphy: support enabling TX for CPRI SERDES raw/cnxk_bphy: support changing CPRI misc settings common/cnxk: remove unused constants common/cnxk: sync eth mode change command with firmware common/cnxk: support switching CPRI/ETH back and forth doc/guides/rawdevs/cnxk_bphy.rst| 32 ++ drivers/common/cnxk/roc_bphy_cgx.c | 148 ++- drivers/common/cnxk/roc_bphy_cgx.h | 66 ++- drivers/common/cnxk/roc_bphy_cgx_priv.h | 85 ++-- drivers/common/cnxk/roc_bphy_irq.c | 103 + drivers/common/cnxk/roc_model.h | 24 ++ drivers/common/cnxk/version.map | 3 + drivers/raw/cnxk_bphy/cnxk_bphy_cgx.c | 52 ++- drivers/raw/cnxk_bphy/rte_pmd_bphy.h| 509 +++- 9 files changed, 826 insertions(+), 196 deletions(-) -- 2.25.1
[PATCH 01/10] common/cnxk: update register access for CNF10xxN
Due to HW changes some fields which were used to enable
xmit were moved elsewhere. This patch takes care of this.
Signed-off-by: Tomasz Duszynski
Reviewed-by: Jakub Palider
Reviewed-by: Jerin Jacob Kollanukkaran
Tested-by: Jerin Jacob Kollanukkaran
---
drivers/common/cnxk/roc_bphy_cgx.c | 33 --
1 file changed, 22 insertions(+), 11 deletions(-)
diff --git a/drivers/common/cnxk/roc_bphy_cgx.c
b/drivers/common/cnxk/roc_bphy_cgx.c
index c3be3c9041..19baaa6757 100644
--- a/drivers/common/cnxk/roc_bphy_cgx.c
+++ b/drivers/common/cnxk/roc_bphy_cgx.c
@@ -21,10 +21,13 @@
*
* Hence common longer mask may be used.
*/
-#define CGX_CMRX_RX_LMACS 0x128
-#define CGX_CMRX_RX_LMACS_LMACS GENMASK_ULL(3, 0)
-#define CGX_CMRX_SCRATCH0 0x1050
-#define CGX_CMRX_SCRATCH1 0x1058
+#define CGX_CMRX_RX_LMACS 0x128
+#define CGX_CMRX_RX_LMACS_LMACS GENMASK_ULL(3, 0)
+#define CGX_CMRX_SCRATCH0 0x1050
+#define CGX_CMRX_SCRATCH1 0x1058
+#define CGX_MTI_MAC100X_COMMAND_CONFIG0x8010
+#define CGX_MTI_MAC100X_COMMAND_CONFIG_RX_ENA BIT_ULL(1)
+#define CGX_MTI_MAC100X_COMMAND_CONFIG_TX_ENA BIT_ULL(0)
static uint64_t
roc_bphy_cgx_read(struct roc_bphy_cgx *roc_cgx, uint64_t lmac, uint64_t offset)
@@ -221,7 +224,7 @@ static int
roc_bphy_cgx_start_stop_rxtx(struct roc_bphy_cgx *roc_cgx, unsigned int lmac,
bool start)
{
- uint64_t val;
+ uint64_t val, reg, rx_field, tx_field;
if (!roc_cgx)
return -EINVAL;
@@ -229,16 +232,24 @@ roc_bphy_cgx_start_stop_rxtx(struct roc_bphy_cgx
*roc_cgx, unsigned int lmac,
if (!roc_bphy_cgx_lmac_exists(roc_cgx, lmac))
return -ENODEV;
+ if (roc_model_is_cnf10kb()) {
+ reg = CGX_MTI_MAC100X_COMMAND_CONFIG;
+ rx_field = CGX_MTI_MAC100X_COMMAND_CONFIG_RX_ENA;
+ tx_field = CGX_MTI_MAC100X_COMMAND_CONFIG_TX_ENA;
+ } else {
+ reg = CGX_CMRX_CONFIG;
+ rx_field = CGX_CMRX_CONFIG_DATA_PKT_RX_EN;
+ tx_field = CGX_CMRX_CONFIG_DATA_PKT_TX_EN;
+ }
+
pthread_mutex_lock(&roc_cgx->lock);
- val = roc_bphy_cgx_read(roc_cgx, lmac, CGX_CMRX_CONFIG);
- val &= ~(CGX_CMRX_CONFIG_DATA_PKT_RX_EN |
-CGX_CMRX_CONFIG_DATA_PKT_TX_EN);
+ val = roc_bphy_cgx_read(roc_cgx, lmac, reg);
+ val &= ~(rx_field | tx_field);
if (start)
- val |= FIELD_PREP(CGX_CMRX_CONFIG_DATA_PKT_RX_EN, 1) |
- FIELD_PREP(CGX_CMRX_CONFIG_DATA_PKT_TX_EN, 1);
+ val |= FIELD_PREP(rx_field, 1) | FIELD_PREP(tx_field, 1);
- roc_bphy_cgx_write(roc_cgx, lmac, CGX_CMRX_CONFIG, val);
+ roc_bphy_cgx_write(roc_cgx, lmac, reg, val);
pthread_mutex_unlock(&roc_cgx->lock);
return 0;
--
2.25.1
[PATCH 02/10] common/cnxk: use wider mask to extract RPM ID
Some platforms have more RPMs available than the others. Take than
into account when retrieving id of a particular RPM.
Signed-off-by: Tomasz Duszynski
Reviewed-by: Jakub Palider
Reviewed-by: Jerin Jacob Kollanukkaran
Tested-by: Jerin Jacob Kollanukkaran
---
drivers/common/cnxk/roc_bphy_cgx.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/common/cnxk/roc_bphy_cgx.c
b/drivers/common/cnxk/roc_bphy_cgx.c
index 19baaa6757..a0a0d22f85 100644
--- a/drivers/common/cnxk/roc_bphy_cgx.c
+++ b/drivers/common/cnxk/roc_bphy_cgx.c
@@ -173,8 +173,14 @@ roc_bphy_cgx_intf_req(struct roc_bphy_cgx *roc_cgx,
unsigned int lmac,
static unsigned int
roc_bphy_cgx_dev_id(struct roc_bphy_cgx *roc_cgx)
{
- uint64_t cgx_id = roc_model_is_cn10k() ? GENMASK_ULL(26, 24) :
-GENMASK_ULL(25, 24);
+ uint64_t cgx_id;
+
+ if (roc_model_is_cnf10kb())
+ cgx_id = GENMASK_ULL(27, 24);
+ else if (roc_model_is_cn10k())
+ cgx_id = GENMASK_ULL(26, 24);
+ else
+ cgx_id = GENMASK_ULL(25, 24);
return FIELD_GET(cgx_id, roc_cgx->bar0_pa);
}
--
2.25.1
[PATCH 03/10] raw/cnxk_bphy: add doxygen comments
From: Jakub Palider
Documentation in doxygen format is important for API
headers used by end user. This patch fills BPHY and CGX
interface with missing bits.
Signed-off-by: Jakub Palider
Reviewed-by: Jerin Jacob Kollanukkaran
---
drivers/raw/cnxk_bphy/rte_pmd_bphy.h | 339 +--
1 file changed, 318 insertions(+), 21 deletions(-)
diff --git a/drivers/raw/cnxk_bphy/rte_pmd_bphy.h
b/drivers/raw/cnxk_bphy/rte_pmd_bphy.h
index cc2372f719..db8a13a4f8 100644
--- a/drivers/raw/cnxk_bphy/rte_pmd_bphy.h
+++ b/drivers/raw/cnxk_bphy/rte_pmd_bphy.h
@@ -13,103 +13,169 @@
#include
#include
+/**
+ * @file rte_pmd_bphy.h
+ *
+ * Marvell CGX and BPHY PMD specific structures and interface
+ *
+ * This API allows applications to manage BPHY memory in user space along with
+ * installing interrupt handlers for low latency signal processing.
+ */
+
#ifdef __cplusplus
extern "C" {
#endif
+/** Available message types */
enum cnxk_bphy_cgx_msg_type {
+ /** Type used to obtain link information */
CNXK_BPHY_CGX_MSG_TYPE_GET_LINKINFO,
+ /** Type used to disable internal loopback */
CNXK_BPHY_CGX_MSG_TYPE_INTLBK_DISABLE,
+ /** Type used to enable loopback */
CNXK_BPHY_CGX_MSG_TYPE_INTLBK_ENABLE,
+ /** Type used to disable PTP on RX */
CNXK_BPHY_CGX_MSG_TYPE_PTP_RX_DISABLE,
+ /** Type used to enable PTP on RX */
CNXK_BPHY_CGX_MSG_TYPE_PTP_RX_ENABLE,
+ /** Type used to set link mode */
CNXK_BPHY_CGX_MSG_TYPE_SET_LINK_MODE,
+ /** Type used to set link state */
CNXK_BPHY_CGX_MSG_TYPE_SET_LINK_STATE,
+ /** Type used to start transmission and packet reception */
CNXK_BPHY_CGX_MSG_TYPE_START_RXTX,
+ /** Type used to stop transmission and packet reception */
CNXK_BPHY_CGX_MSG_TYPE_STOP_RXTX,
+ /** Type used to obtain supported FEC */
CNXK_BPHY_CGX_MSG_TYPE_GET_SUPPORTED_FEC,
+ /** Type used to set FEC */
CNXK_BPHY_CGX_MSG_TYPE_SET_FEC,
};
+/** Available link speeds */
enum cnxk_bphy_cgx_eth_link_speed {
- CNXK_BPHY_CGX_ETH_LINK_SPEED_NONE,
- CNXK_BPHY_CGX_ETH_LINK_SPEED_10M,
- CNXK_BPHY_CGX_ETH_LINK_SPEED_100M,
- CNXK_BPHY_CGX_ETH_LINK_SPEED_1G,
- CNXK_BPHY_CGX_ETH_LINK_SPEED_2HG,
- CNXK_BPHY_CGX_ETH_LINK_SPEED_5G,
- CNXK_BPHY_CGX_ETH_LINK_SPEED_10G,
- CNXK_BPHY_CGX_ETH_LINK_SPEED_20G,
- CNXK_BPHY_CGX_ETH_LINK_SPEED_25G,
- CNXK_BPHY_CGX_ETH_LINK_SPEED_40G,
- CNXK_BPHY_CGX_ETH_LINK_SPEED_50G,
- CNXK_BPHY_CGX_ETH_LINK_SPEED_80G,
- CNXK_BPHY_CGX_ETH_LINK_SPEED_100G,
+ CNXK_BPHY_CGX_ETH_LINK_SPEED_NONE, /**< None */
+ CNXK_BPHY_CGX_ETH_LINK_SPEED_10M, /**< 10 Mbps */
+ CNXK_BPHY_CGX_ETH_LINK_SPEED_100M, /**< 100 Mbps */
+ CNXK_BPHY_CGX_ETH_LINK_SPEED_1G, /**< 1 Gbps */
+ CNXK_BPHY_CGX_ETH_LINK_SPEED_2HG, /**< 2.5 Gbps */
+ CNXK_BPHY_CGX_ETH_LINK_SPEED_5G, /**< 5 Gbps */
+ CNXK_BPHY_CGX_ETH_LINK_SPEED_10G, /**< 10 Gbps */
+ CNXK_BPHY_CGX_ETH_LINK_SPEED_20G, /**< 20 Gbps */
+ CNXK_BPHY_CGX_ETH_LINK_SPEED_25G, /**< 25 Gbps */
+ CNXK_BPHY_CGX_ETH_LINK_SPEED_40G, /**< 40 Gbps */
+ CNXK_BPHY_CGX_ETH_LINK_SPEED_50G, /**< 50 Gbps */
+ CNXK_BPHY_CGX_ETH_LINK_SPEED_80G, /**< 80 Gbps */
+ CNXK_BPHY_CGX_ETH_LINK_SPEED_100G, /**< 100 Gbps */
__CNXK_BPHY_CGX_ETH_LINK_SPEED_MAX
};
+/** Available FEC modes */
enum cnxk_bphy_cgx_eth_link_fec {
+ /** Disable FEC */
CNXK_BPHY_CGX_ETH_LINK_FEC_NONE,
+ /** Base FEC (IEEE 802.3 CLause 74) */
CNXK_BPHY_CGX_ETH_LINK_FEC_BASE_R,
+ /** Reed-Solomon FEC */
CNXK_BPHY_CGX_ETH_LINK_FEC_RS,
__CNXK_BPHY_CGX_ETH_LINK_FEC_MAX
};
+/** Available link modes */
enum cnxk_bphy_cgx_eth_link_mode {
+ /** SGMII */
CNXK_BPHY_CGX_ETH_LINK_MODE_SGMII_BIT,
+ /** 1000BASE-X */
CNXK_BPHY_CGX_ETH_LINK_MODE_1000_BASEX_BIT,
+ /** QSGMII */
CNXK_BPHY_CGX_ETH_LINK_MODE_QSGMII_BIT,
+ /** 10GBASE-C2C */
CNXK_BPHY_CGX_ETH_LINK_MODE_10G_C2C_BIT,
+ /** 10GBASE-C2M */
CNXK_BPHY_CGX_ETH_LINK_MODE_10G_C2M_BIT,
+ /** 10GBASE-KR */
CNXK_BPHY_CGX_ETH_LINK_MODE_10G_KR_BIT,
+ /** 20GBASE-C2C */
CNXK_BPHY_CGX_ETH_LINK_MODE_20G_C2C_BIT,
+ /** 25GBASE-C2C */
CNXK_BPHY_CGX_ETH_LINK_MODE_25G_C2C_BIT,
+ /** 25GBASE-C2M */
CNXK_BPHY_CGX_ETH_LINK_MODE_25G_C2M_BIT,
+ /** 25GBASE-2-C2M */
CNXK_BPHY_CGX_ETH_LINK_MODE_25G_2_C2C_BIT,
+ /** 25GBASE-CR */
CNXK_BPHY_CGX_ETH_LINK_MODE_25G_CR_BIT,
+ /** 25GBASE-KR */
CNXK_BPHY_CGX_ETH_LINK_MODE_25G_KR_BIT,
+ /** 40GBASE-C2C */
CNXK_BPHY_CGX_ETH_LINK_MODE_40G_C2C_BIT,
+ /** 40GBASE-C2M */
CNXK_BPHY_CGX_ETH_LINK_MODE_40G_C2M_BIT,
+ /** 40GBASE-CR4 */
CNXK_BPHY_CGX_ETH_LINK_MODE_40G_CR4_B
[PATCH 04/10] common/cnxk: don't switch affinity back and forth
Switching affinity back and forth was used as a mean to pass cpu number
to irq registration routine which is an overkill.
Simplify current logic by extending irq registration routine parameter
list with a cpu which should run irq handler.
Signed-off-by: Tomasz Duszynski
Reviewed-by: Jakub Palider
Reviewed-by: Jerin Jacob Kollanukkaran
---
drivers/common/cnxk/roc_bphy_irq.c | 103 +++--
1 file changed, 9 insertions(+), 94 deletions(-)
diff --git a/drivers/common/cnxk/roc_bphy_irq.c
b/drivers/common/cnxk/roc_bphy_irq.c
index f4954d2a28..7b39b61537 100644
--- a/drivers/common/cnxk/roc_bphy_irq.c
+++ b/drivers/common/cnxk/roc_bphy_irq.c
@@ -11,8 +11,6 @@
#include "roc_api.h"
#include "roc_bphy_irq.h"
-#define roc_cpuset_t cpu_set_t
-
struct roc_bphy_irq_usr_data {
uint64_t isr_base;
uint64_t sp;
@@ -222,14 +220,13 @@ roc_bphy_intr_handler(unsigned int irq_num)
}
static int
-roc_bphy_irq_handler_set(struct roc_bphy_irq_chip *chip, int irq_num,
+roc_bphy_irq_handler_set(struct roc_bphy_irq_chip *chip, int cpu, int irq_num,
void (*isr)(int irq_num, void *isr_data),
void *isr_data)
{
- roc_cpuset_t orig_cpuset, intr_cpuset;
struct roc_bphy_irq_usr_data irq_usr;
const struct plt_memzone *mz;
- int i, retval, curr_cpu, rc;
+ int retval, rc;
char *env;
mz = plt_memzone_lookup(chip->mz_name);
@@ -244,38 +241,11 @@ roc_bphy_irq_handler_set(struct roc_bphy_irq_chip *chip,
int irq_num,
if (chip->irq_vecs[irq_num].handler != NULL)
return -EINVAL;
- rc = pthread_getaffinity_np(pthread_self(), sizeof(orig_cpuset),
- &orig_cpuset);
- if (rc < 0) {
- plt_err("Failed to get affinity mask");
- return rc;
- }
-
- for (curr_cpu = -1, i = 0; i < CPU_SETSIZE; i++)
- if (CPU_ISSET(i, &orig_cpuset))
- curr_cpu = i;
- if (curr_cpu < 0)
- return -ENOENT;
-
- CPU_ZERO(&intr_cpuset);
- CPU_SET(curr_cpu, &intr_cpuset);
- rc = pthread_setaffinity_np(pthread_self(), sizeof(intr_cpuset),
- &intr_cpuset);
- if (rc < 0) {
- plt_err("Failed to set affinity mask");
- return rc;
- }
-
irq_usr.isr_base = (uint64_t)roc_bphy_intr_handler;
- irq_usr.sp = (uint64_t)roc_bphy_irq_stack_get(curr_cpu);
- irq_usr.cpu = curr_cpu;
- if (irq_usr.sp == 0) {
- rc = pthread_setaffinity_np(pthread_self(), sizeof(orig_cpuset),
- &orig_cpuset);
- if (rc < 0)
- plt_err("Failed to restore affinity mask");
- return rc;
- }
+ irq_usr.sp = (uint64_t)roc_bphy_irq_stack_get(cpu);
+ irq_usr.cpu = cpu;
+ if (irq_usr.sp == 0)
+ return -ENOMEM;
/* On simulator memory locking operation takes much time. We want
* to skip this when running in such an environment.
@@ -289,23 +259,18 @@ roc_bphy_irq_handler_set(struct roc_bphy_irq_chip *chip,
int irq_num,
*((struct roc_bphy_irq_chip **)(mz->addr)) = chip;
irq_usr.irq_num = irq_num;
- chip->irq_vecs[irq_num].handler_cpu = curr_cpu;
+ chip->irq_vecs[irq_num].handler_cpu = cpu;
chip->irq_vecs[irq_num].handler = isr;
chip->irq_vecs[irq_num].isr_data = isr_data;
retval = ioctl(chip->intfd, ROC_BPHY_IOC_SET_BPHY_HANDLER, &irq_usr);
if (retval != 0) {
- roc_bphy_irq_stack_remove(curr_cpu);
+ roc_bphy_irq_stack_remove(cpu);
chip->irq_vecs[irq_num].handler = NULL;
chip->irq_vecs[irq_num].handler_cpu = -1;
} else {
chip->n_handlers++;
}
- rc = pthread_setaffinity_np(pthread_self(), sizeof(orig_cpuset),
- &orig_cpuset);
- if (rc < 0)
- plt_warn("Failed to restore affinity mask");
-
return retval;
}
@@ -327,7 +292,6 @@ roc_bphy_intr_max_get(struct roc_bphy_irq_chip *irq_chip)
int
roc_bphy_intr_clear(struct roc_bphy_irq_chip *chip, int irq_num)
{
- roc_cpuset_t orig_cpuset, intr_cpuset;
const struct plt_memzone *mz;
int retval;
@@ -343,24 +307,6 @@ roc_bphy_intr_clear(struct roc_bphy_irq_chip *chip, int
irq_num)
if (mz == NULL)
return -ENXIO;
- retval = pthread_getaffinity_np(pthread_self(), sizeof(orig_cpuset),
- &orig_cpuset);
- if (retval < 0) {
- plt_warn("Failed to get affinity mask");
- CPU_ZERO(&orig_cpuset);
- CPU_SET(0, &orig_cpuset);
- }
-
- CPU_ZERO(&intr_cpuset);
- CPU_SET(chip->irq_vecs[irq_num].handler_cpu, &intr_cpuset);
- retval = pthr
[PATCH 08/10] common/cnxk: remove unused constants
Some constants are redundant hence remove them.
Signed-off-by: Tomasz Duszynski
Reviewed-by: Jakub Palider
Reviewed-by: Jerin Jacob Kollanukkaran
---
drivers/common/cnxk/roc_bphy_cgx_priv.h | 53 -
1 file changed, 53 deletions(-)
diff --git a/drivers/common/cnxk/roc_bphy_cgx_priv.h
b/drivers/common/cnxk/roc_bphy_cgx_priv.h
index a1a4239cbe..c8c406439c 100644
--- a/drivers/common/cnxk/roc_bphy_cgx_priv.h
+++ b/drivers/common/cnxk/roc_bphy_cgx_priv.h
@@ -5,59 +5,6 @@
#ifndef _ROC_BPHY_CGX_PRIV_H_
#define _ROC_BPHY_CGX_PRIV_H_
-/* LINK speed types */
-enum eth_link_speed {
- ETH_LINK_NONE,
- ETH_LINK_10M,
- ETH_LINK_100M,
- ETH_LINK_1G,
- ETH_LINK_2HG, /* 2.5 Gbps */
- ETH_LINK_5G,
- ETH_LINK_10G,
- ETH_LINK_20G,
- ETH_LINK_25G,
- ETH_LINK_40G,
- ETH_LINK_50G,
- ETH_LINK_80G,
- ETH_LINK_100G,
- ETH_LINK_MAX,
-};
-
-/* Supported LINK MODE enums
- * Each link mode is a bit mask of these
- * enums which are represented as bits
- */
-enum eth_mode {
- ETH_MODE_SGMII_BIT = 0,
- ETH_MODE_1000_BASEX_BIT,
- ETH_MODE_QSGMII_BIT,
- ETH_MODE_10G_C2C_BIT,
- ETH_MODE_10G_C2M_BIT,
- ETH_MODE_10G_KR_BIT, /* = 5 */
- ETH_MODE_20G_C2C_BIT,
- ETH_MODE_25G_C2C_BIT,
- ETH_MODE_25G_C2M_BIT,
- ETH_MODE_25G_2_C2C_BIT,
- ETH_MODE_25G_CR_BIT, /* = 10 */
- ETH_MODE_25G_KR_BIT,
- ETH_MODE_40G_C2C_BIT,
- ETH_MODE_40G_C2M_BIT,
- ETH_MODE_40G_CR4_BIT,
- ETH_MODE_40G_KR4_BIT, /* = 15 */
- ETH_MODE_40GAUI_C2C_BIT,
- ETH_MODE_50G_C2C_BIT,
- ETH_MODE_50G_C2M_BIT,
- ETH_MODE_50G_4_C2C_BIT,
- ETH_MODE_50G_CR_BIT, /* = 20 */
- ETH_MODE_50G_KR_BIT,
- ETH_MODE_80GAUI_C2C_BIT,
- ETH_MODE_100G_C2C_BIT,
- ETH_MODE_100G_C2M_BIT,
- ETH_MODE_100G_CR4_BIT, /* = 25 */
- ETH_MODE_100G_KR4_BIT,
- ETH_MODE_MAX_BIT /* = 27 */
-};
-
/* REQUEST ID types. Input to firmware */
enum eth_cmd_id {
ETH_CMD_GET_LINK_STS = 4,
--
2.25.1
[PATCH 09/10] common/cnxk: sync eth mode change command with firmware
Layout of eth mode change command defined by firmware has been changed
recently. So in order to retain compatibility between ROC and firmware
update existing codebase.
Signed-off-by: Tomasz Duszynski
Reviewed-by: Jakub Palider
Reviewed-by: Jerin Jacob Kollanukkaran
---
drivers/common/cnxk/roc_bphy_cgx.c | 11 +++--
drivers/common/cnxk/roc_bphy_cgx.h | 19 +-
drivers/common/cnxk/roc_bphy_cgx_priv.h | 12 +
drivers/raw/cnxk_bphy/cnxk_bphy_cgx.c | 4 +++
drivers/raw/cnxk_bphy/rte_pmd_bphy.h| 33 +
5 files changed, 71 insertions(+), 8 deletions(-)
diff --git a/drivers/common/cnxk/roc_bphy_cgx.c
b/drivers/common/cnxk/roc_bphy_cgx.c
index 4b62905164..a5df104088 100644
--- a/drivers/common/cnxk/roc_bphy_cgx.c
+++ b/drivers/common/cnxk/roc_bphy_cgx.c
@@ -367,8 +367,10 @@ roc_bphy_cgx_set_link_mode(struct roc_bphy_cgx *roc_cgx,
unsigned int lmac,
{
uint64_t scr1, scr0;
- if (roc_model_is_cn10k())
+ if (roc_model_is_cn9k() &&
+ (mode->use_portm_idx || mode->portm_idx || mode->mode_group_idx)) {
return -ENOTSUP;
+ }
if (!roc_cgx)
return -EINVAL;
@@ -383,7 +385,12 @@ roc_bphy_cgx_set_link_mode(struct roc_bphy_cgx *roc_cgx,
unsigned int lmac,
FIELD_PREP(SCR1_ETH_MODE_CHANGE_ARGS_SPEED, mode->speed) |
FIELD_PREP(SCR1_ETH_MODE_CHANGE_ARGS_DUPLEX, mode->full_duplex) |
FIELD_PREP(SCR1_ETH_MODE_CHANGE_ARGS_AN, mode->an) |
- FIELD_PREP(SCR1_ETH_MODE_CHANGE_ARGS_PORT, mode->port) |
+ FIELD_PREP(SCR1_ETH_MODE_CHANGE_ARGS_USE_PORTM_IDX,
+ mode->use_portm_idx) |
+ FIELD_PREP(SCR1_ETH_MODE_CHANGE_ARGS_PORTM_IDX,
+ mode->portm_idx) |
+ FIELD_PREP(SCR1_ETH_MODE_CHANGE_ARGS_MODE_GROUP_IDX,
+ mode->mode_group_idx) |
FIELD_PREP(SCR1_ETH_MODE_CHANGE_ARGS_MODE, BIT_ULL(mode->mode));
return roc_bphy_cgx_intf_req(roc_cgx, lmac, scr1, &scr0);
diff --git a/drivers/common/cnxk/roc_bphy_cgx.h
b/drivers/common/cnxk/roc_bphy_cgx.h
index 3b645eb130..4ce1316513 100644
--- a/drivers/common/cnxk/roc_bphy_cgx.h
+++ b/drivers/common/cnxk/roc_bphy_cgx.h
@@ -72,13 +72,30 @@ enum roc_bphy_cgx_eth_link_mode {
ROC_BPHY_CGX_ETH_LINK_MODE_100G_C2M_BIT,
ROC_BPHY_CGX_ETH_LINK_MODE_100G_CR4_BIT,
ROC_BPHY_CGX_ETH_LINK_MODE_100G_KR4_BIT,
+ ROC_BPHY_CGX_ETH_LINK_MODE_50GAUI_2_C2C_BIT,
+ ROC_BPHY_CGX_ETH_LINK_MODE_50GAUI_2_C2M_BIT,
+ ROC_BPHY_CGX_ETH_LINK_MODE_50GBASE_CR2_C_BIT,
+ ROC_BPHY_CGX_ETH_LINK_MODE_50GBASE_KR2_C_BIT,
+ ROC_BPHY_CGX_ETH_LINK_MODE_100GAUI_2_C2C_BIT,
+ ROC_BPHY_CGX_ETH_LINK_MODE_100GAUI_2_C2M_BIT,
+ ROC_BPHY_CGX_ETH_LINK_MODE_100GBASE_CR2_BIT,
+ ROC_BPHY_CGX_ETH_LINK_MODE_100GBASE_KR2_BIT,
+ ROC_BPHY_CGX_ETH_LINK_MODE_SFI_1G_BIT,
+ ROC_BPHY_CGX_ETH_LINK_MODE_25GBASE_CR_C_BIT,
+ ROC_BPHY_CGX_ETH_LINK_MODE_25GBASE_KR_C_BIT,
__ROC_BPHY_CGX_ETH_LINK_MODE_MAX
};
+enum roc_bphy_cgx_mode_group {
+ ROC_BPHY_CGX_MODE_GROUP_ETH,
+};
+
struct roc_bphy_cgx_link_mode {
bool full_duplex;
bool an;
- unsigned int port;
+ bool use_portm_idx;
+ unsigned int portm_idx;
+ enum roc_bphy_cgx_mode_group mode_group_idx;
enum roc_bphy_cgx_eth_link_speed speed;
enum roc_bphy_cgx_eth_link_mode mode;
};
diff --git a/drivers/common/cnxk/roc_bphy_cgx_priv.h
b/drivers/common/cnxk/roc_bphy_cgx_priv.h
index c8c406439c..78fa1eaa6b 100644
--- a/drivers/common/cnxk/roc_bphy_cgx_priv.h
+++ b/drivers/common/cnxk/roc_bphy_cgx_priv.h
@@ -74,11 +74,13 @@ enum eth_cmd_own {
#define SCR1_ETH_CTL_ARGS_ENABLE BIT_ULL(8)
/* struct eth_mode_change_args */
-#define SCR1_ETH_MODE_CHANGE_ARGS_SPEED GENMASK_ULL(11, 8)
-#define SCR1_ETH_MODE_CHANGE_ARGS_DUPLEX BIT_ULL(12)
-#define SCR1_ETH_MODE_CHANGE_ARGS_ANBIT_ULL(13)
-#define SCR1_ETH_MODE_CHANGE_ARGS_PORT GENMASK_ULL(21, 14)
-#define SCR1_ETH_MODE_CHANGE_ARGS_MODE GENMASK_ULL(63, 22)
+#define SCR1_ETH_MODE_CHANGE_ARGS_SPEED GENMASK_ULL(11, 8)
+#define SCR1_ETH_MODE_CHANGE_ARGS_DUPLEX BIT_ULL(12)
+#define SCR1_ETH_MODE_CHANGE_ARGS_ANBIT_ULL(13)
+#define SCR1_ETH_MODE_CHANGE_ARGS_USE_PORTM_IDX BIT_ULL(14)
+#define SCR1_ETH_MODE_CHANGE_ARGS_PORTM_IDX GENMASK_ULL(19, 15)
+#define SCR1_ETH_MODE_CHANGE_ARGS_MODE_GROUP_IDX GENMASK_ULL(21, 20)
+#define SCR1_ETH_MODE_CHANGE_ARGS_MODE GENMASK_ULL(63, 22)
/* struct eth_set_fec_args */
#define SCR1_ETH_SET_FEC_ARGS GENMASK_ULL(9, 8)
diff --git a/drivers/raw/cnxk_bphy/cnxk_bphy_cgx.c
b/drivers/raw/cnxk_bphy/cnxk_bphy_cgx.c
index de1c372334..f839a70f04 100644
--- a/drivers/raw/cnxk_bphy/cnxk_bphy_cgx.c
+++ b/drivers/raw/cnxk_bphy/cnxk_bphy_cgx.c
@@ -112,6 +112,10 @@ cnxk_bphy_cgx_process_buf(struct cnxk_bphy_cgx *cgx,
unsigned in
[PATCH 10/10] common/cnxk: support switching CPRI/ETH back and forth
Add support for toggling modes between ETH and CPRI on
newer MACs (RPM).
Signed-off-by: Tomasz Duszynski
Reviewed-by: Jakub Palider
Reviewed-by: Jerin Jacob Kollanukkaran
---
drivers/common/cnxk/roc_bphy_cgx.h| 17 -
drivers/raw/cnxk_bphy/cnxk_bphy_cgx.c | 14 --
drivers/raw/cnxk_bphy/rte_pmd_bphy.h | 27 +--
3 files changed, 53 insertions(+), 5 deletions(-)
diff --git a/drivers/common/cnxk/roc_bphy_cgx.h
b/drivers/common/cnxk/roc_bphy_cgx.h
index 4ce1316513..2b9a23f5b1 100644
--- a/drivers/common/cnxk/roc_bphy_cgx.h
+++ b/drivers/common/cnxk/roc_bphy_cgx.h
@@ -86,8 +86,20 @@ enum roc_bphy_cgx_eth_link_mode {
__ROC_BPHY_CGX_ETH_LINK_MODE_MAX
};
+/* Supported CPRI modes */
+enum roc_bphy_cgx_eth_mode_cpri {
+ ROC_BPHY_CGX_ETH_MODE_CPRI_2_4G_BIT,
+ ROC_BPHY_CGX_ETH_MODE_CPRI_3_1G_BIT,
+ ROC_BPHY_CGX_ETH_MODE_CPRI_4_9G_BIT,
+ ROC_BPHY_CGX_ETH_MODE_CPRI_6_1G_BIT,
+ ROC_BPHY_CGX_ETH_MODE_CPRI_9_8G_BIT,
+ ROC_BPHY_CGX_ETH_MODE_CPRI_10_1_BIT,
+ ROC_BPHY_CGX_ETH_MODE_CPRI_24_3G_BIT,
+};
+
enum roc_bphy_cgx_mode_group {
ROC_BPHY_CGX_MODE_GROUP_ETH,
+ ROC_BPHY_CGX_MODE_GROUP_CPRI = 2,
};
struct roc_bphy_cgx_link_mode {
@@ -97,7 +109,10 @@ struct roc_bphy_cgx_link_mode {
unsigned int portm_idx;
enum roc_bphy_cgx_mode_group mode_group_idx;
enum roc_bphy_cgx_eth_link_speed speed;
- enum roc_bphy_cgx_eth_link_mode mode;
+ union {
+ enum roc_bphy_cgx_eth_link_mode mode;
+ enum roc_bphy_cgx_eth_mode_cpri mode_cpri;
+ };
};
struct roc_bphy_cgx_link_info {
diff --git a/drivers/raw/cnxk_bphy/cnxk_bphy_cgx.c
b/drivers/raw/cnxk_bphy/cnxk_bphy_cgx.c
index f839a70f04..26def43564 100644
--- a/drivers/raw/cnxk_bphy/cnxk_bphy_cgx.c
+++ b/drivers/raw/cnxk_bphy/cnxk_bphy_cgx.c
@@ -118,8 +118,18 @@ cnxk_bphy_cgx_process_buf(struct cnxk_bphy_cgx *cgx,
unsigned int queue,
(enum roc_bphy_cgx_mode_group)link_mode->mode_group_idx;
rlink_mode.speed =
(enum roc_bphy_cgx_eth_link_speed)link_mode->speed;
- rlink_mode.mode =
- (enum roc_bphy_cgx_eth_link_mode)link_mode->mode;
+ switch (link_mode->mode_group_idx) {
+ case CNXK_BPHY_CGX_MODE_GROUP_ETH:
+ rlink_mode.mode =
+ (enum roc_bphy_cgx_eth_link_mode)
+ link_mode->mode;
+ break;
+ case CNXK_BPHY_CGX_MODE_GROUP_CPRI:
+ rlink_mode.mode_cpri =
+ (enum roc_bphy_cgx_eth_mode_cpri)
+ link_mode->mode_cpri;
+ break;
+ }
ret = roc_bphy_cgx_set_link_mode(cgx->rcgx, lmac, &rlink_mode);
break;
case CNXK_BPHY_CGX_MSG_TYPE_SET_LINK_STATE:
diff --git a/drivers/raw/cnxk_bphy/rte_pmd_bphy.h
b/drivers/raw/cnxk_bphy/rte_pmd_bphy.h
index 7f326e3643..f9949fa313 100644
--- a/drivers/raw/cnxk_bphy/rte_pmd_bphy.h
+++ b/drivers/raw/cnxk_bphy/rte_pmd_bphy.h
@@ -168,9 +168,28 @@ enum cnxk_bphy_cgx_eth_link_mode {
__CNXK_BPHY_CGX_ETH_LINK_MODE_MAX
};
+enum cnxk_bphy_cgx_eth_mode_cpri {
+ /** 2.4G Lane Rate */
+ CNXK_BPHY_CGX_ETH_MODE_CPRI_2_4G_BIT,
+ /** 3.1G Lane Rate */
+ CNXK_BPHY_CGX_ETH_MODE_CPRI_3_1G_BIT,
+ /** 4.9G Lane Rate */
+ CNXK_BPHY_CGX_ETH_MODE_CPRI_4_9G_BIT,
+ /** 6.1G Lane Rate */
+ CNXK_BPHY_CGX_ETH_MODE_CPRI_6_1G_BIT,
+ /** 9.8G Lane Rate */
+ CNXK_BPHY_CGX_ETH_MODE_CPRI_9_8G_BIT,
+ /** 10.1G Lane Rate */
+ CNXK_BPHY_CGX_ETH_MODE_CPRI_10_1_BIT,
+ /** 24.3G Lane Rate */
+ CNXK_BPHY_CGX_ETH_MODE_CPRI_24_3G_BIT,
+};
+
enum cnxk_bphy_cgx_mode_group {
/** ETH group */
CNXK_BPHY_CGX_MODE_GROUP_ETH,
+ /** CPRI group */
+ CNXK_BPHY_CGX_MODE_GROUP_CPRI = 2,
};
struct cnxk_bphy_cgx_msg_link_mode {
@@ -186,8 +205,12 @@ struct cnxk_bphy_cgx_msg_link_mode {
enum cnxk_bphy_cgx_mode_group mode_group_idx;
/** Link speed */
enum cnxk_bphy_cgx_eth_link_speed speed;
- /** Link mode */
- enum cnxk_bphy_cgx_eth_link_mode mode;
+ union {
+ /** Link mode */
+ enum cnxk_bphy_cgx_eth_link_mode mode;
+ /** CPRI mode */
+ enum cnxk_bphy_cgx_eth_mode_cpri mode_cpri;
+ };
};
struct cnxk_bphy_cgx_msg_link_info {
--
2.25.1
[PATCH 05/10] raw/cnxk_bphy: support switching from eCPRI to CPRI
Add support for switching from ethernet (eCPRI) to CPRI mode.
Signed-off-by: Tomasz Duszynski
Reviewed-by: Jakub Palider
Reviewed-by: Jerin Jacob Kollanukkaran
---
doc/guides/rawdevs/cnxk_bphy.rst| 11 +++
drivers/common/cnxk/roc_bphy_cgx.c | 33
drivers/common/cnxk/roc_bphy_cgx.h | 14 +++--
drivers/common/cnxk/roc_bphy_cgx_priv.h | 8 +
drivers/common/cnxk/roc_model.h | 24 +++
drivers/common/cnxk/version.map | 1 +
drivers/raw/cnxk_bphy/cnxk_bphy_cgx.c | 13
drivers/raw/cnxk_bphy/rte_pmd_bphy.h| 40 +
8 files changed, 141 insertions(+), 3 deletions(-)
diff --git a/doc/guides/rawdevs/cnxk_bphy.rst b/doc/guides/rawdevs/cnxk_bphy.rst
index 522390bf1b..7f55e9eac6 100644
--- a/doc/guides/rawdevs/cnxk_bphy.rst
+++ b/doc/guides/rawdevs/cnxk_bphy.rst
@@ -100,6 +100,17 @@ Message must have type set to
``CNXK_BPHY_CGX_MSG_TYPE_START_RXTX`` or
``CNXK_BPHY_CGX_MSG_TYPE_STOP_RXTX``. Former will enable traffic while the
latter will
do the opposite.
+Change mode from eCPRI to CPRI
+~~
+
+Message is used to change operating mode from eCPRI to CPRI along with other
+settings.
+
+Message must have type set to ``CNXK_BPHY_CGX_MSG_TYPE_CPRI_MODE_CHANGE``.
+Prior to sending actual message payload i.e
+``struct cnxk_bphy_cgx_msg_cpri_mode_change`` needs to be filled with relevant
+information.
+
BPHY PMD
diff --git a/drivers/common/cnxk/roc_bphy_cgx.c
b/drivers/common/cnxk/roc_bphy_cgx.c
index a0a0d22f85..223bd313fa 100644
--- a/drivers/common/cnxk/roc_bphy_cgx.c
+++ b/drivers/common/cnxk/roc_bphy_cgx.c
@@ -455,3 +455,36 @@ roc_bphy_cgx_fec_supported_get(struct roc_bphy_cgx
*roc_cgx, unsigned int lmac,
return 0;
}
+
+int
+roc_bphy_cgx_cpri_mode_change(struct roc_bphy_cgx *roc_cgx, unsigned int lmac,
+ struct roc_bphy_cgx_cpri_mode_change *mode)
+{
+ uint64_t scr1, scr0;
+
+ if (!(roc_model_is_cnf95xxn_a0() ||
+ roc_model_is_cnf95xxn_a1() ||
+ roc_model_is_cnf95xxn_b0()))
+ return -ENOTSUP;
+
+ if (!roc_cgx)
+ return -EINVAL;
+
+ if (!roc_bphy_cgx_lmac_exists(roc_cgx, lmac))
+ return -ENODEV;
+
+ if (!mode)
+ return -EINVAL;
+
+ scr1 = FIELD_PREP(SCR1_ETH_CMD_ID, ETH_CMD_CPRI_MODE_CHANGE) |
+ FIELD_PREP(SCR1_CPRI_MODE_CHANGE_ARGS_GSERC_IDX,
+ mode->gserc_idx) |
+ FIELD_PREP(SCR1_CPRI_MODE_CHANGE_ARGS_LANE_IDX, mode->lane_idx) |
+ FIELD_PREP(SCR1_CPRI_MODE_CHANGE_ARGS_RATE, mode->rate) |
+ FIELD_PREP(SCR1_CPRI_MODE_CHANGE_ARGS_DISABLE_LEQ,
+ mode->disable_leq) |
+ FIELD_PREP(SCR1_CPRI_MODE_CHANGE_ARGS_DISABLE_DFE,
+ mode->disable_dfe);
+
+ return roc_bphy_cgx_intf_req(roc_cgx, lmac, scr1, &scr0);
+}
diff --git a/drivers/common/cnxk/roc_bphy_cgx.h
b/drivers/common/cnxk/roc_bphy_cgx.h
index d522d4e202..59a420 100644
--- a/drivers/common/cnxk/roc_bphy_cgx.h
+++ b/drivers/common/cnxk/roc_bphy_cgx.h
@@ -92,6 +92,14 @@ struct roc_bphy_cgx_link_info {
enum roc_bphy_cgx_eth_link_mode mode;
};
+struct roc_bphy_cgx_cpri_mode_change {
+ int gserc_idx;
+ int lane_idx;
+ int rate;
+ bool disable_leq;
+ bool disable_dfe;
+};
+
__roc_api int roc_bphy_cgx_dev_init(struct roc_bphy_cgx *roc_cgx);
__roc_api int roc_bphy_cgx_dev_fini(struct roc_bphy_cgx *roc_cgx);
@@ -118,9 +126,9 @@ __roc_api int roc_bphy_cgx_ptp_rx_disable(struct
roc_bphy_cgx *roc_cgx,
__roc_api int roc_bphy_cgx_fec_set(struct roc_bphy_cgx *roc_cgx,
unsigned int lmac,
enum roc_bphy_cgx_eth_link_fec fec);
-__roc_api int roc_bphy_cgx_fec_supported_get(struct roc_bphy_cgx *roc_cgx,
-unsigned int lmac,
+__roc_api int roc_bphy_cgx_fec_supported_get(struct roc_bphy_cgx *roc_cgx,
unsigned int lmac,
enum roc_bphy_cgx_eth_link_fec
*fec);
-
+__roc_api int roc_bphy_cgx_cpri_mode_change(struct roc_bphy_cgx *roc_cgx,
unsigned int lmac,
+ struct
roc_bphy_cgx_cpri_mode_change *mode);
#endif /* _ROC_BPHY_CGX_H_ */
diff --git a/drivers/common/cnxk/roc_bphy_cgx_priv.h
b/drivers/common/cnxk/roc_bphy_cgx_priv.h
index 6a6b5a7b08..cdd94989c8 100644
--- a/drivers/common/cnxk/roc_bphy_cgx_priv.h
+++ b/drivers/common/cnxk/roc_bphy_cgx_priv.h
@@ -69,6 +69,7 @@ enum eth_cmd_id {
ETH_CMD_GET_SUPPORTED_FEC = 18,
ETH_CMD_SET_FEC = 19,
ETH_CMD_SET_PTP_MODE = 34,
+ ETH_CMD_CPRI_MODE_CHANGE = 35,
};
/* event types - cause of interrupt */
@@ -133,6 +134,13 @@ enum eth_cmd_own {
/* struct eth_set_fec_args */
#define SCR1_ETH_SET_FEC_ARGS GENMASK_ULL(9, 8)
[PATCH 06/10] raw/cnxk_bphy: support enabling TX for CPRI SERDES
Add support for enabling or disablig TX for SERDES
configured in CPRI mode.
Signed-off-by: Tomasz Duszynski
Reviewed-by: Jakub Palider
Reviewed-by: Jerin Jacob Kollanukkaran
---
doc/guides/rawdevs/cnxk_bphy.rst| 10 +++
drivers/common/cnxk/roc_bphy_cgx.c | 31 +
drivers/common/cnxk/roc_bphy_cgx.h | 8 ++
drivers/common/cnxk/roc_bphy_cgx_priv.h | 6 +
drivers/common/cnxk/version.map | 1 +
drivers/raw/cnxk_bphy/cnxk_bphy_cgx.c | 11
drivers/raw/cnxk_bphy/rte_pmd_bphy.h| 36 +
7 files changed, 103 insertions(+)
diff --git a/doc/guides/rawdevs/cnxk_bphy.rst b/doc/guides/rawdevs/cnxk_bphy.rst
index 7f55e9eac6..50ee9bdaa6 100644
--- a/doc/guides/rawdevs/cnxk_bphy.rst
+++ b/doc/guides/rawdevs/cnxk_bphy.rst
@@ -111,6 +111,16 @@ Prior to sending actual message payload i.e
``struct cnxk_bphy_cgx_msg_cpri_mode_change`` needs to be filled with relevant
information.
+Enable TX for CPRI SERDES
+~
+
+Message is used to enable TX for SERDES configured in CPRI mode.
+
+Message must have type set to ``CNXK_BPHY_CGX_MSG_TYPE_CPRI_TX_CONTROL``.
+Prior to sending actual message payload i.e
+``struct cnxk_bphy_cgx_msg_cpri_mode_tx_ctrl`` needs to be filled with relevant
+information.
+
BPHY PMD
diff --git a/drivers/common/cnxk/roc_bphy_cgx.c
b/drivers/common/cnxk/roc_bphy_cgx.c
index 223bd313fa..ee0198924e 100644
--- a/drivers/common/cnxk/roc_bphy_cgx.c
+++ b/drivers/common/cnxk/roc_bphy_cgx.c
@@ -488,3 +488,34 @@ roc_bphy_cgx_cpri_mode_change(struct roc_bphy_cgx
*roc_cgx, unsigned int lmac,
return roc_bphy_cgx_intf_req(roc_cgx, lmac, scr1, &scr0);
}
+
+int
+roc_bphy_cgx_cpri_mode_tx_control(struct roc_bphy_cgx *roc_cgx,
+ unsigned int lmac,
+ struct roc_bphy_cgx_cpri_mode_tx_ctrl *mode)
+{
+ uint64_t scr1, scr0;
+
+ if (!(roc_model_is_cnf95xxn_a0() ||
+ roc_model_is_cnf95xxn_a1() ||
+ roc_model_is_cnf95xxn_b0()))
+ return -ENOTSUP;
+
+ if (!roc_cgx)
+ return -EINVAL;
+
+ if (!roc_bphy_cgx_lmac_exists(roc_cgx, lmac))
+ return -ENODEV;
+
+ if (!mode)
+ return -EINVAL;
+
+ scr1 = FIELD_PREP(SCR1_ETH_CMD_ID, ETH_CMD_CPRI_TX_CONTROL) |
+ FIELD_PREP(SCR1_CPRI_MODE_TX_CTRL_ARGS_GSERC_IDX,
+ mode->gserc_idx) |
+ FIELD_PREP(SCR1_CPRI_MODE_TX_CTRL_ARGS_LANE_IDX,
+ mode->lane_idx) |
+ FIELD_PREP(SCR1_CPRI_MODE_TX_CTRL_ARGS_ENABLE, mode->enable);
+
+ return roc_bphy_cgx_intf_req(roc_cgx, lmac, scr1, &scr0);
+}
diff --git a/drivers/common/cnxk/roc_bphy_cgx.h
b/drivers/common/cnxk/roc_bphy_cgx.h
index 59a420..b8023cce88 100644
--- a/drivers/common/cnxk/roc_bphy_cgx.h
+++ b/drivers/common/cnxk/roc_bphy_cgx.h
@@ -100,6 +100,12 @@ struct roc_bphy_cgx_cpri_mode_change {
bool disable_dfe;
};
+struct roc_bphy_cgx_cpri_mode_tx_ctrl {
+ int gserc_idx;
+ int lane_idx;
+ bool enable;
+};
+
__roc_api int roc_bphy_cgx_dev_init(struct roc_bphy_cgx *roc_cgx);
__roc_api int roc_bphy_cgx_dev_fini(struct roc_bphy_cgx *roc_cgx);
@@ -130,5 +136,7 @@ __roc_api int roc_bphy_cgx_fec_supported_get(struct
roc_bphy_cgx *roc_cgx, unsig
enum roc_bphy_cgx_eth_link_fec
*fec);
__roc_api int roc_bphy_cgx_cpri_mode_change(struct roc_bphy_cgx *roc_cgx,
unsigned int lmac,
struct
roc_bphy_cgx_cpri_mode_change *mode);
+__roc_api int roc_bphy_cgx_cpri_mode_tx_control(struct roc_bphy_cgx *roc_cgx,
unsigned int lmac,
+ struct
roc_bphy_cgx_cpri_mode_tx_ctrl *mode);
#endif /* _ROC_BPHY_CGX_H_ */
diff --git a/drivers/common/cnxk/roc_bphy_cgx_priv.h
b/drivers/common/cnxk/roc_bphy_cgx_priv.h
index cdd94989c8..96db34f6a1 100644
--- a/drivers/common/cnxk/roc_bphy_cgx_priv.h
+++ b/drivers/common/cnxk/roc_bphy_cgx_priv.h
@@ -70,6 +70,7 @@ enum eth_cmd_id {
ETH_CMD_SET_FEC = 19,
ETH_CMD_SET_PTP_MODE = 34,
ETH_CMD_CPRI_MODE_CHANGE = 35,
+ ETH_CMD_CPRI_TX_CONTROL = 36,
};
/* event types - cause of interrupt */
@@ -141,6 +142,11 @@ enum eth_cmd_own {
#define SCR1_CPRI_MODE_CHANGE_ARGS_DISABLE_LEQ BIT_ULL(32)
#define SCR1_CPRI_MODE_CHANGE_ARGS_DISABLE_DFE BIT_ULL(33)
+/* struct cpri_mode_tx_ctrl_args */
+#define SCR1_CPRI_MODE_TX_CTRL_ARGS_GSERC_IDX GENMASK_ULL(11, 8)
+#define SCR1_CPRI_MODE_TX_CTRL_ARGS_LANE_IDX GENMASK_ULL(15, 12)
+#define SCR1_CPRI_MODE_TX_CTRL_ARGS_ENABLEBIT_ULL(16)
+
#define SCR1_OWN_STATUS GENMASK_ULL(1, 0)
#endif /* _ROC_BPHY_CGX_PRIV_H_ */
diff --git a/drivers/common/cnxk/version.map b/drivers/common/cnxk/version.map
index 720cad61ea..a6183799a9 100644
--- a/drivers/common/cnxk/version.map
+++ b/drivers/common/cnxk/
[PATCH 07/10] raw/cnxk_bphy: support changing CPRI misc settings
Add support for changing miscellaneous CPRI settings.
Signed-off-by: Tomasz Duszynski
Reviewed-by: Jerin Jacob Kollanukkaran
---
doc/guides/rawdevs/cnxk_bphy.rst| 11
drivers/common/cnxk/roc_bphy_cgx.c | 30 +
drivers/common/cnxk/roc_bphy_cgx.h | 8 ++
drivers/common/cnxk/roc_bphy_cgx_priv.h | 6 +
drivers/common/cnxk/version.map | 1 +
drivers/raw/cnxk_bphy/cnxk_bphy_cgx.c | 10 +++
drivers/raw/cnxk_bphy/rte_pmd_bphy.h| 36 +
7 files changed, 102 insertions(+)
diff --git a/doc/guides/rawdevs/cnxk_bphy.rst b/doc/guides/rawdevs/cnxk_bphy.rst
index 50ee9bdaa6..2490912534 100644
--- a/doc/guides/rawdevs/cnxk_bphy.rst
+++ b/doc/guides/rawdevs/cnxk_bphy.rst
@@ -121,6 +121,17 @@ Prior to sending actual message payload i.e
``struct cnxk_bphy_cgx_msg_cpri_mode_tx_ctrl`` needs to be filled with relevant
information.
+Change CPRI misc settings
+~
+
+Message is used to change misc CPRI settings, for example to reset RX state
+machine on CPRI SERDES.
+
+Message must have type set to ``CNXK_BPHY_CGX_MSG_TYPE_CPRI_MODE_MISC``.
+Prior to sending actual message payload i.e
+``struct cnxk_bphy_cgx_msg_cpri_mode_misc`` needs to be filled with relevant
+information.
+
BPHY PMD
diff --git a/drivers/common/cnxk/roc_bphy_cgx.c
b/drivers/common/cnxk/roc_bphy_cgx.c
index ee0198924e..4b62905164 100644
--- a/drivers/common/cnxk/roc_bphy_cgx.c
+++ b/drivers/common/cnxk/roc_bphy_cgx.c
@@ -519,3 +519,33 @@ roc_bphy_cgx_cpri_mode_tx_control(struct roc_bphy_cgx
*roc_cgx,
return roc_bphy_cgx_intf_req(roc_cgx, lmac, scr1, &scr0);
}
+
+int
+roc_bphy_cgx_cpri_mode_misc(struct roc_bphy_cgx *roc_cgx, unsigned int lmac,
+ struct roc_bphy_cgx_cpri_mode_misc *mode)
+{
+ uint64_t scr1, scr0;
+
+ if (!(roc_model_is_cnf95xxn_a0() ||
+ roc_model_is_cnf95xxn_a1() ||
+ roc_model_is_cnf95xxn_b0()))
+ return -ENOTSUP;
+
+ if (!roc_cgx)
+ return -EINVAL;
+
+ if (!roc_bphy_cgx_lmac_exists(roc_cgx, lmac))
+ return -ENODEV;
+
+ if (!mode)
+ return -EINVAL;
+
+ scr1 = FIELD_PREP(SCR1_ETH_CMD_ID, ETH_CMD_CPRI_MISC) |
+ FIELD_PREP(SCR1_CPRI_MODE_MISC_ARGS_GSERC_IDX,
+ mode->gserc_idx) |
+ FIELD_PREP(SCR1_CPRI_MODE_MISC_ARGS_LANE_IDX,
+ mode->lane_idx) |
+ FIELD_PREP(SCR1_CPRI_MODE_MISC_ARGS_FLAGS, mode->flags);
+
+ return roc_bphy_cgx_intf_req(roc_cgx, lmac, scr1, &scr0);
+}
diff --git a/drivers/common/cnxk/roc_bphy_cgx.h
b/drivers/common/cnxk/roc_bphy_cgx.h
index b8023cce88..3b645eb130 100644
--- a/drivers/common/cnxk/roc_bphy_cgx.h
+++ b/drivers/common/cnxk/roc_bphy_cgx.h
@@ -106,6 +106,12 @@ struct roc_bphy_cgx_cpri_mode_tx_ctrl {
bool enable;
};
+struct roc_bphy_cgx_cpri_mode_misc {
+ int gserc_idx;
+ int lane_idx;
+ int flags;
+};
+
__roc_api int roc_bphy_cgx_dev_init(struct roc_bphy_cgx *roc_cgx);
__roc_api int roc_bphy_cgx_dev_fini(struct roc_bphy_cgx *roc_cgx);
@@ -138,5 +144,7 @@ __roc_api int roc_bphy_cgx_cpri_mode_change(struct
roc_bphy_cgx *roc_cgx, unsign
struct
roc_bphy_cgx_cpri_mode_change *mode);
__roc_api int roc_bphy_cgx_cpri_mode_tx_control(struct roc_bphy_cgx *roc_cgx,
unsigned int lmac,
struct
roc_bphy_cgx_cpri_mode_tx_ctrl *mode);
+__roc_api int roc_bphy_cgx_cpri_mode_misc(struct roc_bphy_cgx *roc_cgx,
unsigned int lmac,
+ struct roc_bphy_cgx_cpri_mode_misc
*mode);
#endif /* _ROC_BPHY_CGX_H_ */
diff --git a/drivers/common/cnxk/roc_bphy_cgx_priv.h
b/drivers/common/cnxk/roc_bphy_cgx_priv.h
index 96db34f6a1..a1a4239cbe 100644
--- a/drivers/common/cnxk/roc_bphy_cgx_priv.h
+++ b/drivers/common/cnxk/roc_bphy_cgx_priv.h
@@ -71,6 +71,7 @@ enum eth_cmd_id {
ETH_CMD_SET_PTP_MODE = 34,
ETH_CMD_CPRI_MODE_CHANGE = 35,
ETH_CMD_CPRI_TX_CONTROL = 36,
+ ETH_CMD_CPRI_MISC = 42,
};
/* event types - cause of interrupt */
@@ -147,6 +148,11 @@ enum eth_cmd_own {
#define SCR1_CPRI_MODE_TX_CTRL_ARGS_LANE_IDX GENMASK_ULL(15, 12)
#define SCR1_CPRI_MODE_TX_CTRL_ARGS_ENABLEBIT_ULL(16)
+/* struct cpri_mode_misc_args */
+#define SCR1_CPRI_MODE_MISC_ARGS_GSERC_IDX GENMASK_ULL(11, 8)
+#define SCR1_CPRI_MODE_MISC_ARGS_LANE_IDX GENMASK_ULL(15, 12)
+#define SCR1_CPRI_MODE_MISC_ARGS_FLAGS GENMASK_ULL(17, 16)
+
#define SCR1_OWN_STATUS GENMASK_ULL(1, 0)
#endif /* _ROC_BPHY_CGX_PRIV_H_ */
diff --git a/drivers/common/cnxk/version.map b/drivers/common/cnxk/version.map
index a6183799a9..d5fd1f41c2 100644
--- a/drivers/common/cnxk/version.map
+++ b/drivers/common/cnxk/version.map
@@ -29,6 +29,7 @@ INTERNAL {
roc_ae_fpm_put;
roc_aes_xcbc_key_derive;
[PATCH] common/cnxk: allow building generic arm64 target for cn9k/cn10k
Allow building generic arm64 target using config/arm/arm64_armv8_linux_*
config which works on both cn9k and cn10k by relaxing cache line size
requirements a bit.
While at it move cache line checks to common place.
Signed-off-by: Tomasz Duszynski
Reviewed-by: Jerin Jacob Kollanukkaran
---
drivers/common/cnxk/roc_dev.c | 26 ++
drivers/event/cnxk/cn10k_eventdev.c | 5 -
drivers/event/cnxk/cn9k_eventdev.c | 5 -
drivers/net/cnxk/cn10k_ethdev.c | 5 -
drivers/net/cnxk/cn9k_ethdev.c | 5 -
5 files changed, 26 insertions(+), 20 deletions(-)
diff --git a/drivers/common/cnxk/roc_dev.c b/drivers/common/cnxk/roc_dev.c
index 9a869698c4..09199ac2ff 100644
--- a/drivers/common/cnxk/roc_dev.c
+++ b/drivers/common/cnxk/roc_dev.c
@@ -1094,6 +1094,29 @@ dev_lmt_setup(struct dev *dev)
return -errno;
}
+static bool
+dev_cache_line_size_valid(void)
+{
+ if (roc_model_is_cn9k()) {
+ if (PLT_CACHE_LINE_SIZE != 128) {
+ plt_err("Cache line size of %d is wrong for CN9K",
+ PLT_CACHE_LINE_SIZE);
+ return false;
+ }
+ } else if (roc_model_is_cn10k()) {
+ if (PLT_CACHE_LINE_SIZE == 128) {
+ plt_warn("Cache line size of %d might affect
performance",
+PLT_CACHE_LINE_SIZE);
+ } else if (PLT_CACHE_LINE_SIZE != 64) {
+ plt_err("Cache line size of %d is wrong for CN10K",
+ PLT_CACHE_LINE_SIZE);
+ return false;
+ }
+ }
+
+ return true;
+}
+
int
dev_init(struct dev *dev, struct plt_pci_device *pci_dev)
{
@@ -1102,6 +1125,9 @@ dev_init(struct dev *dev, struct plt_pci_device *pci_dev)
uintptr_t vf_mbase = 0;
uint64_t intr_offset;
+ if (!dev_cache_line_size_valid())
+ return -EFAULT;
+
bar2 = (uintptr_t)pci_dev->mem_resource[2].addr;
bar4 = (uintptr_t)pci_dev->mem_resource[4].addr;
if (bar2 == 0 || bar4 == 0) {
diff --git a/drivers/event/cnxk/cn10k_eventdev.c
b/drivers/event/cnxk/cn10k_eventdev.c
index 77f0c28160..25d01fd90a 100644
--- a/drivers/event/cnxk/cn10k_eventdev.c
+++ b/drivers/event/cnxk/cn10k_eventdev.c
@@ -963,11 +963,6 @@ cn10k_sso_init(struct rte_eventdev *event_dev)
struct cnxk_sso_evdev *dev = cnxk_sso_pmd_priv(event_dev);
int rc;
- if (RTE_CACHE_LINE_SIZE != 64) {
- plt_err("Driver not compiled for CN10K");
- return -EFAULT;
- }
-
rc = roc_plt_init();
if (rc < 0) {
plt_err("Failed to initialize platform model");
diff --git a/drivers/event/cnxk/cn9k_eventdev.c
b/drivers/event/cnxk/cn9k_eventdev.c
index 4d45f02c1c..6fef15e352 100644
--- a/drivers/event/cnxk/cn9k_eventdev.c
+++ b/drivers/event/cnxk/cn9k_eventdev.c
@@ -1193,11 +1193,6 @@ cn9k_sso_init(struct rte_eventdev *event_dev)
struct cnxk_sso_evdev *dev = cnxk_sso_pmd_priv(event_dev);
int rc;
- if (RTE_CACHE_LINE_SIZE != 128) {
- plt_err("Driver not compiled for CN9K");
- return -EFAULT;
- }
-
rc = roc_plt_init();
if (rc < 0) {
plt_err("Failed to initialize platform model");
diff --git a/drivers/net/cnxk/cn10k_ethdev.c b/drivers/net/cnxk/cn10k_ethdev.c
index 4cd82af7e5..33f61743f9 100644
--- a/drivers/net/cnxk/cn10k_ethdev.c
+++ b/drivers/net/cnxk/cn10k_ethdev.c
@@ -759,11 +759,6 @@ cn10k_nix_probe(struct rte_pci_driver *pci_drv, struct
rte_pci_device *pci_dev)
struct cnxk_eth_dev *dev;
int rc;
- if (RTE_CACHE_LINE_SIZE != 64) {
- plt_err("Driver not compiled for CN10K");
- return -EFAULT;
- }
-
rc = roc_plt_init();
if (rc) {
plt_err("Failed to initialize platform model, rc=%d", rc);
diff --git a/drivers/net/cnxk/cn9k_ethdev.c b/drivers/net/cnxk/cn9k_ethdev.c
index a388b3a8a6..fb34d20759 100644
--- a/drivers/net/cnxk/cn9k_ethdev.c
+++ b/drivers/net/cnxk/cn9k_ethdev.c
@@ -689,11 +689,6 @@ cn9k_nix_probe(struct rte_pci_driver *pci_drv, struct
rte_pci_device *pci_dev)
struct cnxk_eth_dev *dev;
int rc;
- if (RTE_CACHE_LINE_SIZE != 128) {
- plt_err("Driver not compiled for CN9K");
- return -EFAULT;
- }
-
rc = roc_plt_init();
if (rc) {
plt_err("Failed to initialize platform model, rc=%d", rc);
--
2.25.1
Re: [PATCH v6 0/4] Add APIs for configurable power options
> Kevin Laatz (4): > lib/power: add get and set API for emptypoll max > lib/power: add get and set API for pause duration > lib/power: add get and set API for scaling freq min and max with > pstate mode > examples/l3fwd_power: add cli for configurable options Applied, thanks.
[PATCH] net/bonding: failover of LACP with mode 4 takes long time
When the primary port of bond slaves with bond mode 4 linked down,
the system id of the other slave ports channged.
It may cause some switches to renegotiate,
and the process takes a few seconds. It is not acceptable for any
Telcos.
We need sub-second switchover time like in linux.
Set the mac of the bond port to the slave port's system to solve the
problem.
Bugzilla ID: 551
Fixes: 46fb43683679 ("bond: add mode 4")
Cc: sta...@dpdk.org
Signed-off-by: Gaoxiang Liu
---
drivers/net/bonding/rte_eth_bond_8023ad.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/net/bonding/rte_eth_bond_8023ad.c
b/drivers/net/bonding/rte_eth_bond_8023ad.c
index b3cddd8a20..b393148238 100644
--- a/drivers/net/bonding/rte_eth_bond_8023ad.c
+++ b/drivers/net/bonding/rte_eth_bond_8023ad.c
@@ -866,7 +866,6 @@ bond_mode_8023ad_periodic_cb(void *arg)
struct bond_dev_private *internals = bond_dev->data->dev_private;
struct port *port;
struct rte_eth_link link_info;
- struct rte_ether_addr slave_addr;
struct rte_mbuf *lacp_pkt = NULL;
uint16_t slave_id;
uint16_t i;
@@ -893,7 +892,6 @@ bond_mode_8023ad_periodic_cb(void *arg)
key = 0;
}
- rte_eth_macaddr_get(slave_id, &slave_addr);
port = &bond_mode_8023ad_ports[slave_id];
key = rte_cpu_to_be_16(key);
@@ -905,8 +903,8 @@ bond_mode_8023ad_periodic_cb(void *arg)
SM_FLAG_SET(port, NTT);
}
- if (!rte_is_same_ether_addr(&port->actor.system, &slave_addr)) {
- rte_ether_addr_copy(&slave_addr, &port->actor.system);
+ if (!rte_is_same_ether_addr(&internals->mode4.mac_addr,
&port->actor.system)) {
+ rte_ether_addr_copy(&internals->mode4.mac_addr,
&port->actor.system);
if (port->aggregator_port_id == slave_id)
SM_FLAG_SET(port, NTT);
}
@@ -1178,15 +1176,15 @@ bond_mode_8023ad_mac_address_update(struct rte_eth_dev
*bond_dev)
bond_mode_8023ad_stop(bond_dev);
+ rte_eth_macadd_get(internals->port_id, &internals->mode4.mac_addr);
for (i = 0; i < internals->active_slave_count; i++) {
slave_id = internals->active_slaves[i];
slave = &bond_mode_8023ad_ports[slave_id];
- rte_eth_macaddr_get(slave_id, &slave_addr);
- if (rte_is_same_ether_addr(&slave_addr, &slave->actor.system))
+ if (rte_is_same_ether_addr(&internals->mode4.mac_addr,
&slave->actor.system))
continue;
- rte_ether_addr_copy(&slave_addr, &slave->actor.system);
+ rte_ether_addr_copy(&internals->mode4.mac_addr,
&slave->actor.system);
/* Do nothing if this port is not an aggregator. In other case
* Set NTT flag on every port that use this aggregator. */
if (slave->aggregator_port_id != slave_id)
--
2.32.0
