Hello,
Further looking at the code, when upcall_xlate is performed, we create a
hardcoded status block to represent the first packet:
stats.n_packets = 1;
stats.n_bytes = dp_packet_size(upcall->packet);
stats.used = time_msec();
stats.tcp_flags = ntohs(upcall->flow->tcp_flags);
This information is pushed into the flow status when a output or a goto_table
action is performed. Additionally, the revalidator which pulls the status
information from
the kernel also updates the flow information, right after the flow is
established.
Assuming that we are interested in the successfully established kernel flows,
the status of the revalidator should give us the conclusive flow statistics. Is
this status block and the resubmit of the status information than a workaround
because the first packet of MISS_UPCALL is not registered in the kernel stats?
Regards,
Dincer
________________________________
Von: dev <ovs-dev-boun...@openvswitch.org> im Auftrag von Dincer Beken
<dbe...@blackned.de>
Gesendet: Freitag, 7. Februar 2020 10:18
An: Ben Pfaff <b...@ovn.org>; Pravin Shelar <pshe...@ovn.org>
Cc: 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
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?
> 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
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
