Inefficiency in BPF code for DLT_RAW

[Darren Reed <Darren.Reed () Sun COM>]

Looking at the BPF code that gets generated for links such as
the IP tunnels in Solaris, there appears to be an inefficiency
in the opcodes generated. Let me explain.

The links that support the IP tunnels are a fixed type, be
it IPv4 or IPv6, and are reported as being DLT_RAW because
there is no real layer 2 header present.

This works fine for the opcodes generated but there's a slight
problem: if I do "tcp or udp" (for example), the opcodes output
handle both IPv4 and IPv6.

The root of this appears to be in functions such as
gen_proto_abbrev(), where opcodes to match for the protocol
are output against both IPv4 and IPv6, with no way to select
one or the other or both.

The inefficiency pops up in two ways:
1) a check for which IP protocol is added when none is needed;
2) the BPF program is longer than it needs to be, possibly
  double the size it should be.

In the face of modern processors, this might seem like
micro-optimisation but I see it more as a precision error:
it is not possible to precisely tell libpcap (and thus the
BPF compiler) that a link only sees one protocol and
therefore does not need to handle both protocol cases.

Thoughts?

Darren

-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.