Re: Improving the data supplied by BPF

[Darren Reed <darrenr%netbsd.org@localhost>]

Greg Troxel wrote:
> Darren Reed <darrenr%netbsd.org@localhost> writes:
> 
>> Greg Troxel wrote:
>>> One thing I've always found missing in bpf is a flag to denote outgoing
>>> vs incoming packets.  It might also be nice to note 'tapped as added to
>>> queue' vs 'tapped when tx dma set up' vs 'tapped when tx ack arrives'.
>> Interesting but I think that's outside the scope of what I'm
>> trying to do here and now. Additionally, if there were possible,
>> we'd need to think about if/how that is exposed to the user
>> and how to interpret a user saying "tap tx dma set up packets
>> for loopback" (because they'll try to use the same CLI/filter
>> for loopback as they did the bge chip...)
> 
> I wasn't proposing an interface to control tap location, just flag bits
> to record what happened.  I once added support to ath(4) to do the
> tapping on tx complete so it could include more status.
> But I see the point that one has to stop somewhere.

I wonder if what you're looking for is something more akin to
what dtrace allows? bpf's purpose is primarily packet data and
not so much NIC status, etc. A dtrace-like solution would let
you tap packets as they move along, in and out of packets and
at specific "probe" points. I say that because it sounds like
you are just as (if not more) interested in non-packet data
and for that, I think BPF is not really the right answer...

Darren