On 13 Oct 2026, at 10:34, Eli Britstein wrote:
> On 13/10/2026 11:01, Eelco Chaudron wrote:
>>>> +/* Build a set of alternative actions to exercise the alt_actions support
>>>> in
>>>> + * the netdev_hw_post_process() API. The dummy implementation returns
>>>> + * alternative actions only when the action list consists solely of
>>>> + * OVS_ACTION_ATTR_OUTPUT actions, and at least one egress port is not of
>>>> + * type dummy-pmd. In that case, the dummy-pmd outputs are handled in
>>>> + * 'hardware', while the non-dummy-pmd outputs are returned as alternative
>>>> + * actions to be executed by the PMD thread. */
>>>> +static struct offload_actions *
>>>> +dummy_build_alt_actions(const struct dpif_offload *offload_,
>>>> + odp_port_t in_odp,
>>>> + const struct nlattr *actions,
>>>> + size_t actions_len)
>>>> +{
>>>> + struct offload_actions *alt_actions = NULL;
>>>> + const struct nlattr *nla;
>>>> + struct ofpbuf buf;
>>>> + size_t left;
>>>> +
>>>> + ofpbuf_init(&buf, 0);
>>>> +
>>>> + NL_ATTR_FOR_EACH (nla, left, actions, actions_len) {
>>>> + enum ovs_action_attr action = nl_attr_type(nla);
>>>> + struct dummy_offload_port *out_port;
>>>> + odp_port_t out_odp;
>>>> +
>>>> + if (action != OVS_ACTION_ATTR_OUTPUT) {
>>>> + goto out;
>>>> + }
>>>> +
>>>> + out_odp = nl_attr_get_odp_port(nla);
>>>> + out_port = dummy_offload_get_port_by_odp_port(offload_, out_odp);
>>>> + if (out_odp != in_odp
>>>> + && (!out_port
>>>> + || strcmp("dummy-pmd",
>>>> + netdev_get_type(out_port->pm_port.netdev)))) {
>>>> + ofpbuf_put(&buf, nla, NLA_ALIGN(nla->nla_len));
>>> I still think it can be simplified. Here you build a struct ofpbuf, that
>>> you copy from the actions to. Later, you copy this to alt_actions. All we
>>> need is to detect this case, then copy actions (minus the first one) to
>>> alt_actions.
>> Your suggestion assumes the non-dummy-pmd ports are always at the
>> start of the list. We support mixed port lists like:
>>
>> p1(non-pmd), p2(pmd), p3(non-pmd), p4(pmd)
>>
>> In this case we can not simply copy everything after the first
>> action, as the pmd ports (p2, p4) must still be handled in hardware
>> and should not be part of the alt_actions. However I reworked the
>> code to avoid the copy, by using xrealloc() instead of an ofpbuf.
>> Will send this in a v3 later.
>
> In practice, since we don't change the order (at least try) of the actions,
> we can have a "actions=port_ol1,port_non_ol1,port_ol2". In HW the offload
> will do only "port_ol1" and the rest will be done in SW since port_non_ol1 is
> not offloadable.
You are right, even in the demo/unit test code we should try to keep
the ordering. Reworked so it will only process up to the first action
we do not support, returning the remaining actions as alt_actions.
> BTW, this is a feature we abandoned at the time (because we didn't have
> alt_actions, :)), but also it was not very important.
>
> The real use case is for CT, but we don't have this part yet.
Agreed the use case is different, but this is just a way to test
the infrastructure. In the future hardware vendors could use this
for optimizations, for example doing all packet modifications in
hardware but only forwarding in software.
I will prepare a v3 with this change and send it out.
//Eelco
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
