On 4/1/14, 5:43 PM, Jarno Rajahalme wrote:
Sent from my iPhone
On Apr 1, 2014, at 7:27 AM, Ben Pfaff <b...@nicira.com> wrote:
On Tue, Apr 01, 2014 at 03:14:16PM +0300, Lori Jakab wrote:
On 3/26/14, 2:16 AM, Ben Pfaff wrote:
On Mon, Mar 24, 2014 at 10:59:06AM -0700, Jarno Rajahalme wrote:
This patch shrinks the struct ofpbuf from 104 to 48 bytes on 64-bit
systems, or from 52 to 36 bytes on 32-bit systems (counting in the
'l7' removal by the previous patch). This may help contribute to
cache efficiency, and will speed up initializing, copying and
manipulating ofpbufs. This is potentially important for the DPDK
datapath, but the rest of the code base may also see a little benefit.
Changes are:
- Remove 'l7' pointer (previous patch).
- Use offsets instead of layer pointers for l2_5, l3, and l4 using
'l2' as basis. Usually 'data' is the same as 'l2', but this is not
always the case (e.g., when parsing or constructing a packet), so it
can not be easily used as the offset basis. Also, packet parsing is
faster if we do not need to maintain the offsets each time we pull
data from the ofpbuf.
- Use uint32_t for 'allocated' and 'size', as 2^32 is enough even for
largest possible messages/packets.
- Use packed enum for 'source'.
- Rearrange to avoid unnecessary padding.
- Remove 'private_p', which was used only in two cases, both of which
had the invariant ('l2' == 'data'), so we can temporarily use 'l2'
as a private pointer.
Signed-off-by: Jarno Rajahalme <jrajaha...@nicira.com>
Unfotunately I missed this patch until rebasing my layer 3 patch
series [1] today.
Before this patch, I set the 'l2' pointer to NULL and 'l3' to the
start of the network header to represent a layer 3 packet in a
struct ofpbuf. The way struct ofpbuf looks after this patch makes
the assumption of always having layer 2 headers a lot stronger.
I see two options for my patches going forward:
1) Add back 'l3' and remove 'l3_ofs' from struct ofpbuf (keeping the
rest as is); or
2) Encode a layer 3 packet by setting 'l2' to the network header
address and set l3_ofs to 0.
Can we do the following?
3) Replace 'l2' by 'l2_ofs' also?
I'll look into this today. However, my earlier analysis was that this would
complicate things when the offset basis ('data') is changing a lot (e.g., when
pulling data from ofpbuf). Maybe the cleanest solution would be to have a
pointer to the start of packet and an additional l2 offset.
Yes, that's the most elegant solution IMHO.
However, as 0 is a valid offset value, having a separate l2 offset seems
redundant as l3_ofs 0 would be an unambiguous way of encoding the absence of
the l2 header.
I think having 'l2' set to a value other then NULL for layer 3 packets
can be confusing, even if l3_ofs is set to 0, but I don't mind
implementing L3 support that way.
I like Ben's proposal 3) better than 2), but I understand the concerns
about the basis changing a lot.
-Lori
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
