Re: [RFC PATCH] Add new `pcap_set_buffer_size1` API.

[Mario Rugiero <mrugiero () gmail com>]

El mié., 2 oct. 2019 a las 18:46, Guy Harris (<gharris () sonic net>) escribió:
> On Oct 2, 2019, at 2:16 PM, Mario Rugiero <mrugiero () gmail com> wrote:
>
> > A new `pcap_set_buffer_size1` call is created, taking a `size_t`
> > instead of an `int`, allowing for buffers as big as the platform
> > allows.
>
> Perhaps pcap_set_buffer_size_ext (Windows-style) would be better - a 1 at the end 1) is a bit unclear about what it 
> means and 2) may look too much like an l (I first thought it *was* an "l", for "long", but maybe that's just the 
> particular fixed-width font that's the default in macOS).
>
> (Or pcap_set_buffer_size_size_t, but that may be a bit awkward.)
I used '1' because that's what Linux does when advertising newer
versions of syscalls.
'_ext' does look better, I think I'd go with that.
> > Due to some contexts requiring smaller maximum buffers, a new field
> > named `max_buffer_size` of type `size_t` was added to the same structure
> > to account for that.
>
> There should probably be an API to get the maximum buffer size as well, for the benefit of 1) programs that want "the 
> biggest buffer they can get" and 2) GUI programs that might have a "buffer size" field implemented as a spinbox.
I thought about that after sending the RFC, and I think it's a good idea.
> Should pcap_set_buffer_size also check against the maximum size, and set it to the maximum size if it's above the 
> maximum?
I'd like that, but I thought it'd be better to leave it as is to avoid
breaking existing programs that might rely on this check missing.
For the same reason, I avoided changing the check for positivity to
return an error, as I think libraries should provide mechanisms, not
policies, and silently deciding on a different behaviour is the
latter.
> > This field is initialized by default to `INT_MAX` to preserve the
> > behaviour of the older API.
> > Then, each driver is expected, but not mandated, to fix it to a more
> > appropriate value for the platform.
> > In this RFC, Linux and DPDK are used as examples.
>
> Is there a maximum buffer size > INT_MAX for Linux?
It seems I forgot to commit the changes to pcap-linux.c. It did set
the maximum buffer size to SIZE_MAX as well.
> At least in macOS, and possibly in other BSD-flavored OSes, the sysctl variable debug.bpf_maxbufsize will indicate 
> the maximum size.
I'm not sure how to handle this.
Buffer size can only be set before activation, but filters can be set
at any point.
From the user POV, I wouldn't like my buffers to be limited by the
maximum size of filters when I never use them.
However, another user may attempt to set it after using a buffer
exceeding this, and it would fail in mysterious ways.
The only solution I came up with is to always use software filters
when the buffer is too big.
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers