On Fri, Feb 7, 2020 at 1:18 AM Dincer Beken <dbe...@blackned.de> wrote: > > Just repeating last mail with fixed indentations (mail was in wrong format): > > > 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? > I am not in favor of checking of flow in OVS_PACKET_CMD_EXECUTE for same issue that you have mentioned. It involves flow lookup, the flow might not exist in datapath, so we need handle that case. On the other hand it is much straightforward in OVS_FLOW_CMD_NEW. As Ben has mentioned OVS_FLOW_ATTR_PACKET attr can be used for passing packet data. After executing the actions for packet we can update the stats for newly added flow.
> > > 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 > _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
