Message ID | 20230713085506.1946-2-viacheslav.galaktionov@arknetworks.am |
---|---|
State | Accepted |
Commit | a5fdc45b842d5109d38e9f1564afd3e3da77d6be |
Headers | show |
Series | [ovs-dev] netdev-dpdk: Fix build with experimental API. | expand |
Context | Check | Description |
---|---|---|
ovsrobot/apply-robot | success | apply and check: success |
ovsrobot/github-robot-_Build_and_Test | fail | github build: failed |
On 7/13/23 10:55, Viacheslav Galaktionov via dev wrote: > The set_error function is now used regardless of whether experimental APIs > are allowed or not, so it must be defined unconditionally. > > Fixes: fc06ea9a1883 ("netdev-dpdk: Add custom rx-steering configuration.") > Signed-off-by: Viacheslav Galaktionov <viacheslav.galaktionov@arknetworks.am> > Acked-by: Ivan Malov <ivan.malov@arknetworks.am> > --- > lib/netdev-dpdk.h | 22 +++++++++++----------- > 1 file changed, 11 insertions(+), 11 deletions(-) Applied. Thanks! Best regards, Ilya Maximets.
On Thu, Jul 13, 2023 at 11:02 AM Viacheslav Galaktionov via dev <ovs-dev@openvswitch.org> wrote: > > The set_error function is now used regardless of whether experimental APIs > are allowed or not, so it must be defined unconditionally. > > Fixes: fc06ea9a1883 ("netdev-dpdk: Add custom rx-steering configuration.") > Signed-off-by: Viacheslav Galaktionov <viacheslav.galaktionov@arknetworks.am> > Acked-by: Ivan Malov <ivan.malov@arknetworks.am> Can we merge the dpdk-latest patch for checking experimental API compilation in the master branch? I am referring to: https://github.com/openvswitch/ovs/commit/561e15fabd43613cb9c8a2d996c1dae6c16b4a0d
On 8/8/23 09:17, David Marchand wrote: > On Thu, Jul 13, 2023 at 11:02 AM Viacheslav Galaktionov via dev > <ovs-dev@openvswitch.org> wrote: >> >> The set_error function is now used regardless of whether experimental APIs >> are allowed or not, so it must be defined unconditionally. >> >> Fixes: fc06ea9a1883 ("netdev-dpdk: Add custom rx-steering configuration.") >> Signed-off-by: Viacheslav Galaktionov <viacheslav.galaktionov@arknetworks.am> >> Acked-by: Ivan Malov <ivan.malov@arknetworks.am> > > Can we merge the dpdk-latest patch for checking experimental API > compilation in the master branch? I'd vote for removal of the code that requires experimental API from master instead and not accepting any new code that requires experimental API to branches other than dpdk-latest. Can the flow restoration API be stabilized until 23.11 release? I saw you made some progress on the mbuf flag. And I posted a small additional request not so long ago: https://lore.kernel.org/dpdk-dev/820c8ce1-091a-cd9b-2dd2-c830ff0a503c@ovn.org/ Best regards, Ilya Maximets.
On Tue, Aug 8, 2023 at 3:14 PM Ilya Maximets <i.maximets@ovn.org> wrote: > > On 8/8/23 09:17, David Marchand wrote: > > On Thu, Jul 13, 2023 at 11:02 AM Viacheslav Galaktionov via dev > > <ovs-dev@openvswitch.org> wrote: > >> > >> The set_error function is now used regardless of whether experimental APIs > >> are allowed or not, so it must be defined unconditionally. > >> > >> Fixes: fc06ea9a1883 ("netdev-dpdk: Add custom rx-steering configuration.") > >> Signed-off-by: Viacheslav Galaktionov <viacheslav.galaktionov@arknetworks.am> > >> Acked-by: Ivan Malov <ivan.malov@arknetworks.am> > > > > Can we merge the dpdk-latest patch for checking experimental API > > compilation in the master branch? > > I'd vote for removal of the code that requires experimental API > from master instead and not accepting any new code that requires > experimental API to branches other than dpdk-latest. I was reacting to this fix being applied on the master branch, which let the experimental code in place rather than drop it. If we keep it, we need something in the CI to avoid future breakage. Let's see what others think. > > Can the flow restoration API be stabilized until 23.11 release? We have a common chicken/egg situation. OVS wants to use "stable" API, but DPDK prefers marking an API stable once there is feedback / a user of such API. My intention is to mark it stable on DPDK side, based on OVS feedback. As a next step, the point is on my side to send a OVS patch to make use of this API update. Hopefully, it will get a timely feedback so DPDK can mark the API stable, before v23.11-rc1. > I saw you made some progress on the mbuf flag. And I posted a > small additional request not so long ago: > https://lore.kernel.org/dpdk-dev/820c8ce1-091a-cd9b-2dd2-c830ff0a503c@ovn.org/ It is on my todo list as part of preparing the OVS patch.
diff --git a/lib/netdev-dpdk.h b/lib/netdev-dpdk.h index 5cd95d00f..86df7a1e8 100644 --- a/lib/netdev-dpdk.h +++ b/lib/netdev-dpdk.h @@ -52,6 +52,17 @@ netdev_dpdk_rte_flow_query_count(struct netdev *netdev, int netdev_dpdk_get_port_id(struct netdev *netdev); +static inline void +set_error(struct rte_flow_error *error, enum rte_flow_error_type type) +{ + if (!error) { + return; + } + error->type = type; + error->cause = NULL; + error->message = NULL; +} + #ifdef ALLOW_EXPERIMENTAL_API int netdev_dpdk_rte_flow_tunnel_decap_set(struct netdev *, @@ -79,17 +90,6 @@ int netdev_dpdk_rte_flow_tunnel_item_release(struct netdev *, #else -static inline void -set_error(struct rte_flow_error *error, enum rte_flow_error_type type) -{ - if (!error) { - return; - } - error->type = type; - error->cause = NULL; - error->message = NULL; -} - static inline int netdev_dpdk_rte_flow_tunnel_decap_set( struct netdev *netdev OVS_UNUSED,