On 3 Mar 2023, at 11:45, Adrian Moreno wrote:

> On 3/3/23 11:33, Eelco Chaudron wrote:
>>
>>
>> On 27 Feb 2023, at 15:29, Ilya Maximets wrote:
>>
>>> On 2/24/23 11:41, Adrián Moreno wrote:
>>>> From: Adrian Moreno <amore...@redhat.com>
>>>>
>>>> This is basically a rewrite of the upcall_cost.py script moving some of
>>>> it's functionality to the ebpf programs. These are the main changes:
>>>>
>>>> * Correlation of kernel upcall <-> userspace recv upcall.
>>>> The correlation was being done in python by comparing the packet
>>>> contents.
>>>> We still don't have a better way to do it but, instead of doing it
>>>> at post-processing time, compute a hash in the ebpf program so
>>>> correlation is little more than an indirection.
>>>> For the hash library we use jhash.h from the linux-headers package.
>>>>
>>>> * GSO packets
>>>> We where attaching to the upcall tracepoint which is hit before
>>>> fragmentation. Use a kprobe on kprobe__queue_userspace_packet to
>>>> correlate upcalls to upcall queue events.
>>>>
>>>> * Userspace operation batching.
>>>> Also move the batc tracking implementation to the ebpf programs so each
>>>> operation (e.g: PUT, EXEC) event  contains the id (hash) of the
>>>> correspondent RECV.
>>>>
>>>> As a result of this, it's no longer mandatory to send the packet or key
>>>> bytes to userspace, leading to smaller events and less event drops.
>>>> Also, accuracy is improved since we're now considering fragmentation.
>>>> Additionally, there is no need for a time-consuming post-processing
>>>> phase so the script is now much faster.
>>>>
>>>> Signed-off-by: Adrian Moreno <amore...@redhat.com>
>>>
>>> Hi, Adrian.  I'll leave the actual review to Eelco, but FYI this change
>>> is failing builds due to PEP8 issues.
>>
>> In addition, it looks like you also run the entire script through the black 
>> auto formatter, which makes reviewing a pain, due to all the style changes.
>>
>> If you really want to run this through black can you split this in a 
>> separate patch?
>>
>
> I actually only applied black formatting to the pieces I modified but since 
> I've gone back and forth several times with this script there are some 
> gratuitous formatting changes that should be undone. I'll send another 
> version.

Thanks, I’ll wait for the next rev! I think we should try to keep the style of 
the (python) file you changing, and if we want to go black, we should do it in 
one go.

//Eelco


_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to