On 3/16/23 10:16, Eelco Chaudron wrote:
> On 1 Mar 2023, at 8:22, Chris Mi wrote:
>
>> In thread handler 0, add netdev offload recv in normal recv upcalls.
>> To avoid starvation, introduce a flag to alternate the order of
>> receiving normal upcalls and offload upcalls based on that flag.
>>
>> Add similar change for recv_wait.
>
> See some comments inline below, and some architecture input from Ilya is
> needed...
>
> //Eelco
>
>
>> Signed-off-by: Chris Mi <c...@nvidia.com>
>> Reviewed-by: Roi Dayan <r...@nvidia.com>
>> ---
>> lib/dpif-netlink.c | 42 ++++++++++++++++++++++++++++++-----
>> ofproto/ofproto-dpif-upcall.c | 16 +++++++++----
>> 2 files changed, 48 insertions(+), 10 deletions(-)
<snip>
>> +static int
>> +dpif_netlink_recv(struct dpif *dpif_, uint32_t handler_id,
>> + struct dpif_upcall *upcall, struct ofpbuf *buf)
>> +{
>> + struct dpif_netlink *dpif = dpif_netlink_cast(dpif_);
>> + struct dpif_handler *handler;
>> + int error;
>> +
>> + fat_rwlock_rdlock(&dpif->upcall_lock);
>> + handler = &dpif->handlers[handler_id];
>> + if (handler->recv_offload_first) {
>> + error = netdev_offload_recv(upcall, buf, handler_id);
>
> Here the abstraction blurs a bit, as netdev_offload_recv() would try to call
> implementations, tc and rte_flow?
> See also earlier comment in netdev_offload_recv()
>
> Also what about for example rte_flow being handled now in the dpif-netdev
> class?
> In general, OVS-DPDK does not have any upcall threads, so if OVS-DPDK (or any
> new offload) decides to use any of these mechanisms it will fail.
>
> Ilya do you have any feedback?
IIRC, handlers are getting created. But we need to implement recv()
and recv_wait() callbacks for dpif-netdev, that will just call to
netdev_offload_recv[_wait]().
Best regards, Ilya Maximets.
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
