[Qemu-devel] RFC - best way to organize a multiprotocol transport?

[Qemu-devel] RFC - best way to organize a multiprotocol transport?

[Anton Ivanov]

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.

Re: [Qemu-devel] RFC - best way to organize a multiprotocol transport?

[Stefan Hajnoczi]

On Fri, Mar 21, 2014 at 10:01:09AM +0000, Anton Ivanov wrote:
> 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.

The user-visible command-line options will be different (e.g. L2TPv3 rx
cookie).  Therefore, I suggest having independent user-facing netdevs.

In other words, give each encapsulation its own NetdevFooOptions in
qapi-schema.json and a net_init_foo() function.

qemu -netdev gre,... -netdev l2tp,...

The actual implementation could be shared.  Maybe something like:
net/encap.c - common code for encapsulation/tunneling
net/encap.h - header used by L2TPv3 and GRE
net/l2tpv3.c - L2TPv3 specific code and net_init_l2tp()
net/gre.c - GRE specific code and net_init_gre()

How exactly the net/encap.h interface looks is something you need to
decide based on the details.  Does it make sense to have a common
NetdevEncap struct that can be embedded and has function pointers for
protocol-specific hooks?  Or is it better to just provide common
functions and let protocols use them as a library?  It's up to you.

Stefan

Re: [Qemu-devel] RFC - best way to organize a multiprotocol transport?

[Anton Ivanov]

On 21/03/14 13:14, Stefan Hajnoczi wrote:
> On Fri, Mar 21, 2014 at 10:01:09AM +0000, Anton Ivanov wrote:
>> 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.
> The user-visible command-line options will be different (e.g. L2TPv3 rx
> cookie).  Therefore, I suggest having independent user-facing netdevs.
>
> In other words, give each encapsulation its own NetdevFooOptions in
> qapi-schema.json and a net_init_foo() function.
>
> qemu -netdev gre,... -netdev l2tp,...

OK.

>
> The actual implementation could be shared.  Maybe something like:
> net/encap.c - common code for encapsulation/tunneling
> net/encap.h - header used by L2TPv3 and GRE
> net/l2tpv3.c - L2TPv3 specific code and net_init_l2tp()
> net/gre.c - GRE specific code and net_init_gre()
>
> How exactly the net/encap.h interface looks is something you need to
> decide based on the details.  Does it make sense to have a common
> NetdevEncap struct that can be embedded and has function pointers for
> protocol-specific hooks?  Or is it better to just provide common
> functions and let protocols use them as a library?  It's up to you.

OK. Undestood.

I will probably collect all common routines and merge them into a
library. Once that is done I will submit a revised patch that does
l2tpv3 and gre.

A

>
> Stefan
>

Re: [Qemu-devel] RFC - best way to organize a multiprotocol transport?

[Stefan Hajnoczi]

On Fri, Mar 21, 2014 at 3:06 PM, Anton Ivanov
<anton.ivanov@kot-begemot.co.uk> wrote:
> On 21/03/14 13:14, Stefan Hajnoczi wrote:
>> On Fri, Mar 21, 2014 at 10:01:09AM +0000, Anton Ivanov wrote:
> I will probably collect all common routines and merge them into a
> library. Once that is done I will submit a revised patch that does
> l2tpv3 and gre.

It's up to you, but I suggest submitting l2tpv3 in the current form
before embarking on this change.

That way you can get it upstream and finished.  We won't have to
review the code again.  Instead, we'll be able to focus on the GRE and
code reuse aspects when you submit new patches.

Stefan

Re: [Qemu-devel] RFC - best way to organize a multiprotocol transport?

[Anton Ivanov]

On 21/03/14 15:27, Stefan Hajnoczi wrote:
> On Fri, Mar 21, 2014 at 3:06 PM, Anton Ivanov
> <anton.ivanov@kot-begemot.co.uk> wrote:
>> On 21/03/14 13:14, Stefan Hajnoczi wrote:
>>> On Fri, Mar 21, 2014 at 10:01:09AM +0000, Anton Ivanov wrote:
>> I will probably collect all common routines and merge them into a
>> library. Once that is done I will submit a revised patch that does
>> l2tpv3 and gre.
> It's up to you, but I suggest submitting l2tpv3 in the current form
> before embarking on this change.
>
> That way you can get it upstream and finished.  We won't have to
> review the code again.  Instead, we'll be able to focus on the GRE and
> code reuse aspects when you submit new patches.

OK. I will resubmit it on Monday. If anyone has any comments before then
it will be greatly appreciated.

Best Regards,

A.

>
> Stefan
>