Re: Mirage-net-xen and Generic Segmentation Offload, and question about genAI and code

[Hannes Mehnert <hannes@xxxxxxxxxxx>]

Dear Pierre,

thanks for starting the discussion. And great to hear the improved 
numbers for mirage-qubes-firewall/GSO.
On 31/07/2026 21:38, pierre.alain@xxxxxxx wrote:
> I've started some time ago (maybe years?) to add Generic Segmentation Offload 
> to mirage-net-xen to improve bandwidth for qubes-mirage-firewall, because I 
> observed that it introduced a large restriction compared to a Linux kernel 
> firewall [1].
>
> That was very long, and now I'm happy to announce that I have some PRs [2-5] 
> that enable GSO with qubes-mirage-firewall. The 'good' thing is that I've got 
> the following results on Qubes using iperf3 for 10 second runs between two VMs 
> with a firewall in between (run only once, and 10s, so I won't commit to exact 
> figures, just take the overall picture):
> - GSO disabled with qubes-mirage-firewall: 0.531 Gbit/s (current head is at 
> 0.350 Gbit/s) vs. Linux: 1.92 Gbit/s, ratio 3.62
> - GSO enabled with qubes-mirage-firewall: 3.16 Gbit/s vs. Linux-fw: 6.16 
> Gbit/s, ratio 1.95

That sounds great - do you have some profiling what are the expensive 
bits compared to the linux firewall? A factor of 2 is still very high 
IMHO - a good selling point would be a factor of 0.2 ;)

> So now we're only roughly half the performance of Linux \o/
> Although there is still a lot of work to do to improve the bandwidth, it's not 
> on the GSO path any more.
>
> The 'bad' thing, leading to this email, is that across the branches for 
> mirage-xen, mirage-net-xen, mirage-nat and qubes-mirage-firewall, some (a lot 
> of) findings and code were produced using Claude Opus 5 as a 'rubber duck'. I 
> tried to be explicit in the commits about the help I got from it, from findings 
> to co-authorship, and I want to convey that, even if I've done a lot of work 
> before, I would not have been able to finish so quickly without that tool. It 
> really helped me a lot for tracking issues in pcaps, comparing packets byte by 
> byte, finding references in the Xen or Linux sources, etc.
>
> So my question about this work is whether the way I disclosed it in the commits the 
> right granularity? Especially, when Claude Opus is credited with co-authorship (e.g. 
> the mirage-xen PR [3]), it means the code was written by the tool and reviewed by 
> me, I cannot guarantee that the same code does not exist in another repository, 
> possibly under a more restrictive licence.

From my point of view, the first item is crucial: be transparent (as 
you are) about the usage thereof. Review all the changes in detail, and 
figure out whether that is the way to go or there would be some other 
way (which also means, be open for constructive feedback on PRs).
The license issue is a real one, where I don't have any clue about. If 
the first point - you reviewed and now own the code - is done 
extensively, it shouldn't be a thing to re-implement the solution you 
saw with your own fingers -- but that certainly won't solve the 
licensing in any way (since it is not a clean-room implementation). I 
wonder what a good strategy is? Maybe other people who use AI a lot have 
some ideas about it? All I can tell is that last Friday in Germany some 
AI music generator lost in court against real musicians -- so the AI 
generated music violates copyright. I believe the same will be in the 
future being adapted to software and copyright.
And obviously, using AI to find references, compare packets, ... is an 
ok utilization - as long as you agree to the terms and impact (to 
climate, politics, strengthening bigtech companies, likely more) of AI. 
[To make it transparent, I never used AI, and I don't plan to use any 
for writing code. If you're interested about some reasoning, I find the 
article https://superrr.net/en/blog/about-ai-and-unlikelihood very 
interesting, with lots of useful links. If you're more of an audio 
person, https://techwontsave.us/episodes also has tons of interesting 
episodes.]
I am happy to review your PRs, and am not so happy to review random 
passing-by PRs which are heavily done by AI without any manual review 
(as https://github.com/mirage/mirage/pull/1647).

Best,

Hannes