From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48219) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WL7nK-0000il-4c for Qemu-devel@nongnu.org; Wed, 05 Mar 2014 04:07:26 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WL7nB-00086s-Nf for Qemu-devel@nongnu.org; Wed, 05 Mar 2014 04:07:18 -0500 Received: from mail-ee0-x232.google.com ([2a00:1450:4013:c00::232]:33800) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WL7nB-00086n-Ff for Qemu-devel@nongnu.org; Wed, 05 Mar 2014 04:07:09 -0500 Received: by mail-ee0-f50.google.com with SMTP id c13so287963eek.37 for ; Wed, 05 Mar 2014 01:07:08 -0800 (PST) Date: Wed, 5 Mar 2014 10:07:04 +0100 From: Stefan Hajnoczi Message-ID: <20140305090704.GB18052@stefanha-thinkpad.muc.redhat.com> References: <5310489A.4060501@cisco.com> <20140303145303.GF21055@stefanha-thinkpad.redhat.com> <5315B9C8.1000300@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5315B9C8.1000300@cisco.com> Subject: Re: [Qemu-devel] Contribution - L2TPv3 transport List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Anton Ivanov (antivano)" Cc: "Qemu-devel@nongnu.org" 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.