Hi Ben,
I’ve managed to implement the action to the kernel space too, now packets are
mangled successfully. The only issue I have now is that, when the userspace is
running and a packet arrives the userpace won’t translate my action to the
datapath. The trace command clearly says, that there is sth wrong with the
translations.
root@osv:~# ovs-appctl ofproto/trace br0 in_port=enp0s8,tcp,tcp_dst=8000
Flow:
tcp,in_port=2,vlan_tci=0x0000,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,nw_src=0.0.0.0,nw_dst=0.0.0.0,nw_tos=0,nw_ecn=0,nw_ttl=0,tp_src=0,tp_dst=8000,tcp_flags=0
bridge("br0")
-------------
0. tcp,tp_dst=8000, priority 32768
inc_seq(1)
output:1
Final flow: unchanged
Megaflow:
recirc_id=0,eth,tcp,in_port=2,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,nw_src=0.0.0.0/1,nw_dst=0.0.0.0/1,nw_frag=no,tp_dst=8000
Datapath actions: 3
root@osv:~#
I assume this part is done in the dpif-xlate files, however I could not figure
out what should happen there. I’ve implemented the compose_inc_seq function,
but I believe it is wrong. Could you please, give a hint, what these compose
functions should do? Is that the place where the translation occurs or I’m
totally wrong?
Thank you,
Tomas
> On 12 Jan 2018, at 00:04, Ben Pfaff <[email protected]> wrote:
>
> The datapath is what actually implements the actions, after the first
> packet, so that's probably the problem.
>
> On Thu, Jan 11, 2018 at 10:15:44PM +0100, Thomas Boros wrote:
>> The action is not yet implemented for the datapath. I’ve made some changes
>> in the ofproto-dpif-xlate. When I start the vswitchd the kernel module is
>> loaded, but I unload it with modprobe -r openvswitch. When I start a
>> communication, add flows via ofctl, actions are added and the packet
>> mangling works on the first packet, however ovs-dpctl says no dapatath
>> exists.
>>
>> root@osv:~# ovs-dpctl dump-flows
>> ovs-dpctl: no datapaths exist
>> root@osv:~#
>>
>> I’ve also set root@osv:~# ovs-vsctl set bridge br0 datapath_type=netdev,
>> which I’m not quite sure what it does.
>>
>> current changes I’ve made are here
>> https://github.com/fr6nco/ovs/compare/v2.8.1...fr6nco:seq_ack_experimenter
>> <https://github.com/fr6nco/ovs/compare/v2.8.1...fr6nco:seq_ack_experimenter>
>> I’ve forked it from v2.8.1 tag.
>>
>> Does the userspace code have a fast_path too..or fast_path means it is
>> processed in the kernel? Currently i get around 10Mbits of speed, so I
>> assume the communication goes through the userspace, but my custom action in
>> the lib/packets.c:inc_seq is not reached for subsequent packets.
>>
>> Tomas
>>
>>
>>> On 11 Jan 2018, at 22:02, Ben Pfaff <[email protected]> wrote:
>>>
>>> On Thu, Jan 11, 2018 at 09:47:16PM +0100, Thomas Boros wrote:
>>>> for my PhD studies Im implementing a new action, which modifies the
>>>> sequence number in the TCP header. I’ve managed to add the action,
>>>> however the action is applied only on the first packet. I’ve disabled
>>>> the kernel datapath during this development, however I have no idea
>>>> where to make changes to apply my modification on the fast path. I
>>>> see, when a first packet arrives a cache miss occurs in the
>>>> fast_path_processing (file lib/dpif-netdev.c). Could you give some
>>>> hints how to implement my custom action, so it will modify packets on
>>>> the fast_path too? Or how the switch behaves when the kernel module is
>>>> enabled? Do the packet processing goes through the fast_path or
>>>> remains in the kernel datapath?
>>>
>>> Did you implement the action as a datapath action and make the
>>> translation code in ofproto-dpif-xlate emit that datapath action?
>>
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev