Hello Ben, Pravin, Thank you for your consideration. > It is also simpler to fix the stats issue using this approach.
There's no stats issue. Userspace just counts the number of packets it sent and adds them in. Regarding the stats issue. In case of LTE Broadcast, I have tight synchronization periods (from 80ms down to 10ms in 5G) in which I need to set the elapsed #octets and the packet number, as well as the timestamp into the header. Since I do not wan't to make an upcall with each packet, I am using the stats of the kernel flows. Since OVS_PACKET_CMD_EXECUTE does remove the flow directly after use, I am missing the stats of the first packet. Therefore I wanted to know, if there is a specific reason why OVS_PACKET_CMD_EXECUTE has to always use temporary kernel flows. > > > > On Thu, Feb 06, 2020 at 11:36:19AM -0800, Pravin Shelar wrote: > > > Another option would be to add new command that install and execute > > > packet in same netlink msg. That would save us a netlink msg to handle > > > a miss-call. what do you think about it? > > > > When I experimented with that in the past, I found that it didn't have a > > noticeable impact on performance. > > > Reduced number of msgs sent here would help in certain situations. That is plausible, but it didn't help when I measured it previously. If we add a distinct message for packet execution with checking a flow, ex.: OVS_PACKET_CMD_EXECUTE_2, if there is is no flow found, should the packet be dropped? I assume that you probably would like the userplane (altough we are talking here about the a dpif-netlink adapter), to be loosely coupled from the kernel datapath state (such that the userplane does not always has to %100 know if a kernel flow has been purged or not). So this would be an unnecessary risk. Well if we add the temporary flow creation, would not OVS_PACKET_CMD_EXECUTE be redundant? If it did help, then I don't think we'd need a new command, we could just add a OVS_FLOW_ATTR_PACKET to attach a packet to the existing OVS_FLOW_CMD_NEW or OVS_FLOW_CMD_SET commands. I guess that we only need to check in handle_upcalls, if the should_install_flow is positive, install the flow and append the packet, and only if not, create an DPIF_OP_EXECUTE netlink message. This looks helpful. I did not work with OVS_FLOW_CMD_SET yet, but this should be likewise I assume. Regards, Dincer ________________________________ Von: Ben Pfaff <b...@ovn.org> Gesendet: Donnerstag, 6. Februar 2020 22:55 An: Pravin Shelar <pshe...@ovn.org> Cc: Dincer Beken <dbe...@blackned.de>; ovs-dev@openvswitch.org <ovs-dev@openvswitch.org>; Andreas Eberlein <aeberl...@blackned.de> Betreff: Re: [ovs-dev] Question Regarding ovs_packet_cmd_execute in Kernel Datapath On Thu, Feb 06, 2020 at 01:32:12PM -0800, Pravin Shelar wrote: > On Thu, Feb 6, 2020 at 12:18 PM Ben Pfaff <b...@ovn.org> wrote: > > > > On Thu, Feb 06, 2020 at 11:36:19AM -0800, Pravin Shelar wrote: > > > Another option would be to add new command that install and execute > > > packet in same netlink msg. That would save us a netlink msg to handle > > > a miss-call. what do you think about it? > > > > When I experimented with that in the past, I found that it didn't have a > > noticeable impact on performance. > > > Reduced number of msgs sent here would help in certain situations. That is plausible, but it didn't help when I measured it previously. > It is also simpler to fix the stats issue using this approach. There's no stats issue. Userspace just counts the number of packets it sent and adds them in. _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
