[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Contribution - L2TPv3 transport
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-devel] Contribution - L2TPv3 transport |
Date: |
Wed, 5 Mar 2014 10:07:04 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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.
Re: [Qemu-devel] Contribution - L2TPv3 transport, Eric Blake, 2014/03/04
Re: [Qemu-devel] Contribution - L2TPv3 transport, Eric Blake, 2014/03/04