cvs commit: src/sys/dev/bge if_bge.c

[Robert Watson]

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