[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] RFC - best way to organize a multiprotocol transport?
From: |
Anton Ivanov |
Subject: |
[Qemu-devel] RFC - best way to organize a multiprotocol transport? |
Date: |
Fri, 21 Mar 2014 10:01:09 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130922 Icedove/17.0.9 |
Hi list, hi all,
I am interested in what would be the best way to organize a
multiprotocol transport.
I am playing with l2tpv3 and gre - At the end of the day 90% of the
driver code for either looks the same.
If we ignore GRE checksums for a moment, the only differences are in
"form header" and "verify header" functions. TX is the same, RX is the
same, poll state engine is the same and 70% of the init code is the same.
Further to this, if I implement recvmmsg (instead of packet_mmap) based
raw driver this ends up sharing 50% of the code with it too. Same story
with udp based legacy "socket" in unicast mode - that can be expressed
as a NULL encaps sharing 90% of the code with l2tpv3 or gre.
I am wondering how to re-organize these so that the code is not
duplicated across 3-4 drivers as well as allow people to easily add more
encaps in the future.
One way will be to pull all common routines into a common file and have
different option sets and different inits. Another will be to have
"encaps" as a parameter to a common driver. This, however will make all
params optional making option parsing ugly and prone to coding errors.
A.
- [Qemu-devel] RFC - best way to organize a multiprotocol transport?,
Anton Ivanov <=