--- Begin Message ---
El dom., 28 jun. 2020 a las 18:02, Michael Richardson
() escribió:
>
>
> Mario Rugiero via tcpdump-workers wrote:
> >> For a contract, I am trying to improve the write performance by using
> >> async I/O. {I also need to associate re
--- Begin Message ---
El sáb., 27 jun. 2020 a las 23:56, Michael Richardson
() escribió:
>
>
> Mario, can you confirm my understanding here.
>
Hi Michael.
> In TPACKET3 mode, there are (tp_block_nr) pools of memory.
> The beginning of each block is tp_block_size in size, which can
> be large numbe
--- Begin Message ---
OK, it seems fair. Besides, I just checked the code for the oldest
long-term release from kernel.org, a 3.16 one, and it doesn't contain
the fix, and I think it should be supported.
--- End Message ---
___
tcpdump-workers mailing lis
--- Begin Message ---
OK, follow up.
I haven't yet been able to test it, which is why I've been delaying
writing about this,
but these two commits[0][1], which according to these threads[2][3]
are the ones fixing
the timeout issue, have been applied to CentOS 7 default kernel,
3.10.0-1062.el7.
It c
--- Begin Message ---
El sáb., 21 mar. 2020 18:15, Guy Harris via tcpdump-workers <
tcpdump-workers@lists.tcpdump.org> escribió:
> 1) has the slight disadvantage that the name for the team suggests it's
> for pcapng only; it appears that teams can be renamed:
>
>
> https://help.github.com/en/githu
--- Begin Message ---
Hi again.
I'm not sure I'm reading it right (thus I ask here), but is this[0]
the fixing commit?
If it is, I think it's applied on CentOS 7, and since it's basically a
free rebuild of RHEL, I'd expect it to be fixed there, too.
I'll send a few links later so you can check it o
--- Begin Message ---
El mar., 10 mar. 2020 15:26, Mario Rugiero via tcpdump-workers <
tcpdump-workers@lists.tcpdump.org> escribió:
>
>
>
> -- Forwarded message --
> From: Mario Rugiero
> To: Michael Richardson
> Cc: tcpdump-workers
> Bcc:
>
--- Begin Message ---
El mar., 10 mar. 2020 15:07, Michael Richardson
escribió:
>
> Mario Rugiero wrote:
> >> I am trying to process many pull requests for libpcap and tcpdump,
> get some
> >> things closed. I don't think that there is a pull request from you
> yet.
> >> Am I wrong?
--- Begin Message ---
El lun., 2 mar. 2020 a las 14:31, Michael Richardson
() escribió:
> I am trying to process many pull requests for libpcap and tcpdump, get some
> things closed. I don't think that there is a pull request from you yet.
> Am I wrong?
>
Some related PRs got merged already. My Gi
--- Begin Message ---
El mar., 22 oct. 2019 a las 18:01, Guy Harris () escribió:
>
> If RHEL 6 matters, oldest longterm from kernel.org only doesn't work, because
> RHEL 6 runs 2.6.32, according to
>
> https://access.redhat.com/articles/3078
>
> so if we're going to support only the oldest
--- Begin Message ---
El mar., 22 oct. 2019 a las 16:02, Guy Harris () escribió:
> I.e., the goal for libpcap support on Linux should be something such as
>
> it should work on min({kernel for oldest supported enterprise
> distribution}, {oldest "longterm maintenance" kernel release from k
--- Begin Message ---
El mar., 22 oct. 2019 a las 15:08, Guy Harris () escribió:
>
> On Oct 21, 2019, at 5:59 PM, Mario Rugiero via tcpdump-workers
> wrote:
> > - TPACKET_V2 stays for immediate-mode support.
> > - As a side-effect, RHEL6 remains supported.
>
> So RHE
--- Begin Message ---
I think it's time to summarize, and to propose one last idea.
I'm following the thread again to try and be as accurate as possible,
but of course any objections are welcomed.
- The oldest officially supported kernel is 3.16, as this is the
oldest LTS according to kernel.org.
13 matches
Mail list logo
