[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Mirageos Devel <mirageos-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: pierre.alain@xxxxxxx
  • Date: Fri, 31 Jul 2026 21:38:52 +0200 (CEST)
  • Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=s1 header.d=tuta.io header.i="@tuta.io" header.h="From:To:Subject:Content-Type:Content-Transfer-Encoding:Cc:Date:MIME-Version:Message-ID"
  • Cc: Pierre Alain <pierre.alain@xxxxxxx>
  • Delivery-date: Fri, 31 Jul 2026 19:39:04 +0000
  • Feedback-id: 01eaf8ab5c4fb66a25616152514a399f598322e6638868ba822dedd227211ef3e68edf4699e2849fa51d28ca2bbb961117ec852d94c0b4e715ebab57f6709efd92:TurnOnPrivacy!:tutamail
  • List-id: Developer list for MirageOS <mirageos-devel.lists.xenproject.org>

Dear All,

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

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.

Best,
Pierre

[1]: 
https://github.com/mirage/qubes-mirage-firewall/issues/130#issuecomment-1571959103
[2]: https://github.com/mirage/mirage-net-xen/pull/117
[3]: https://github.com/mirage/mirage-xen/pull/56
[4]: https://github.com/mirage/mirage-nat/pull/54
[5]: https://github.com/mirage/mirage-nat/pull/53


--
P.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.