cvs commit: src/sys/dev/bge if_bge.c
Robert Watson
rwatson at FreeBSD.org
Wed Sep 20 04:19:16 PDT 2006
On Wed, 20 Sep 2006, David Malone wrote:
>>> With VLAN tagging we can't trust the VLAN tag.
>
>> Unlike checksums etc, the kernel must be able to determine the VLAN tag to
>> be able to process the packet. The problem is that it isn't where bpf
>> expects.
>
> True, though BPF just expects to find the data where it should be on the
> wire. It seems like it should be up to the responsibility of the code
> calling bpf_*tap* to make sure it is in that format. Checksums that seem
> incorrect to bpf have already caused a non-trivial number questions on the
> mailing lists.
>
> We almost need a way to indicate to BPF that there are certain ranges of
> bytes that we couldn't see because they are provided by the hardware rather
> than us.
As an issue of symmetry, it strikes me that the driver is most aware of what
has been removed from the packet, and so in the best position to provide
substitute data to make up for the removed data. As a matter of abstraction,
it seems likely that the link layer might provide a utility routine to help
mock up the missing data, however. I tend to agree with the observation that
we should not frob the driver level state as a result of BPF listeners -- if
nothing else, this increases the chances of hitting race conditions between
changing of card state and the descriptor rings, in which some packets in the
rings were processed with tag stripping, and some without, but the driver
treats them all as being consistent with its most recent notion of how the
flags were set. Ideally, we should frob the hardware's encapsulation/etc as
little as possible, and probably drain the send and receive descriptor rings
when that happens so there's a clean transition.
Robert N M Watson
Computer Laboratory
University of Cambridge
More information about the cvs-src
mailing list