Re: [Qemu-devel] Contribution - L2TPv3 transport

[Stefan Hajnoczi]

On Tue, Mar 04, 2014 at 11:32:26AM +0000, Anton Ivanov (antivano) wrote:
> > If you really *need* the page size, please use sysconf(_SC_PAGESIZE).
> 
> I like to have it page aligned and if possible page sized so I can later 
> extend to do jumbo frame support via a vector. If this is the wrong way 
> of doing it, I am happy to fix.

Page size may be the best size unit but you need to express it in a
portable way.  Not all host architectures use 4 KB pages so hardcoding a
constant is wrong.

> > +       //vec->iov_len = PAGE_SIZE; /* reset for next read */
> > I think it *is* necessary to reset ->iov_len for both msgvec iovecs.
> 
> mmsgsend does not return these modified. However better be safe than 
> sorry - I am uncommenting these in the next revision.

Oh, I see.  In that case feel free to drop the assignments.  I now see
that msg_len contains the size when recvmmsg(2) returns.

> > Can you use C structs and unions instead of choosing an arbitrary
> > 256-byte size and calculating offsets at runtime?
> 
> It is has now updated to be the correct size for the actual config.
> 
> As far as structs - not really.
> 
> I tried that once upon a time in an early version, I ended up with 8+ 
> different structs (cookies can vary in size so you cannot union-ize 
> them, compiler will allocate the size for the "biggest option"). In 
> addition to that the standard has slightly different headers on raw and 
> udp. The linux kernel people have done the same - header offsets. It is 
> an unfortunate necessity for code like this.
> 
> Also, there is one nearly universal non-standard feature which I would 
> like to put back. It is present in the linux kernel implementation and 
> it is the "arbitrary offset after header" so you can stick extra 
> metadata between header and packet. That will necessitate offset 
> calculations anyway.

Okay, that's fine.  I was hoping but agree it cannot be represented
properly with C structs.

> > Is there a way to disable the IP header included in received packets? 
> > I haven't looked into how IP_HDRINCL works... 
> 
> It works the other way - you can get headers on v6 using that option, 
> but v6 does not give you headers by default. AFAIK v4 raw always gives 
> you the header do you like it or not. Makes the code very ugly 
> unfortunately.

Okay.