On 30 Jul 2026, at 19:49, Aaron Conole wrote:
> Offloading providers will need input port details in order to
> correctly map the packet movement. They will also need the output
> port mapping for the batch, but that will come in the future.
Hi Aaron,
Thanks for the patch, see some comments below. However,
one major thing I am wondering about is how port changes
are detected and handled. For example, a bond could
change and now the ingress and/or egress netdev changes.
We might need an additional API for this.
//Eelco
[...]
> diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
> index 4151ea0565..cc3ca404cb 100644
> --- a/lib/dpif-netdev.c
> +++ b/lib/dpif-netdev.c
> @@ -8307,9 +8307,24 @@ dp_execute_cb(void *aux_, struct dp_packet_batch
> *packets_,
> VLOG_WARN_RL(&rl, "NAT specified without commit.");
> }
>
> + /* Resolve the input netdev for offload providers. No netdev_ref()
> is
> + * needed here: port deletion waits for PMD quiescence, so the netdev
> + * is guaranteed live for the duration of this PMD callback. */
The comment says no netdev_ref() is needed because port
deletion waits for PMD quiescence. But dp_execute_cb is
also called from the non-PMD path (dpif_netdev_execute),
where that guarantee does not hold. Should we take a
netdev_ref() here and netdev_close() after
conntrack_execute() returns?
> + struct netdev *in_netdev = NULL;
Blank line after the declaration.
> + if (!dp_packet_batch_is_empty(packets_)) {
> + odp_port_t query_port =
> + packets_->packets[0]->md.orig_in_port;
> + struct dp_netdev_port *in_port_p =
> + dp_netdev_lookup_port(dp, query_port);
> + if (in_port_p) {
> + in_netdev = in_port_p->netdev;
> + }
I think the below is easier on the eyes as it avoids the line breaks:
if (!dp_packet_batch_is_empty(packets_)) {
struct dp_netdev_port *in_port_p;
odp_port_t query_port;
query_port = packets_->packets[0]->md.orig_in_port;
in_port_p = dp_netdev_lookup_port(dp, query_port);
if (in_port_p) {
in_netdev = in_port_p->netdev;
}
}
> + }
> +
[...]
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
