On 07/26/15 06:16, Kristof Provost wrote:
> On 2015-07-15 00:54:25 (-0700), Colin Percival wrote:
>> In my tests, deleting these lines from pf_ioctl.c
>> 3570 /* We need a proper CSUM befor we start (s. OpenBSD ip_output) */
>> [...]
>> unbreaks pf+TSO on EC2 instances. I'm not entirely sure why
On 2015-07-15 00:54:25 (-0700), Colin Percival wrote:
> In my tests, deleting these lines from pf_ioctl.c
>
> 3570 /* We need a proper CSUM befor we start (s. OpenBSD ip_output) */
> 3571 if ((*m)->m_pkthdr.csum_flags & CSUM_DELAY_DATA) {
> 3572 in_delayed_cksum(*m);
> 3573 (*
23:44, Sydney Meyer wrote:
>
>
>> On 14 Jul 2015, at 18:15, Mark Felder wrote:
>>
>>
>>
>> On Tue, Jul 14, 2015, at 07:36, Sydney Meyer wrote:
>>> Hello everybody,
>>>
>>> i have noticed some odd behaviour with networking under
On 19 Jul 2015, at 12:14, Kristof Provost wrote:
On 19 Jul 2015, at 17:58, George Neville-Neil
wrote:
Since Kristof is already working on this, I'll let him address it.
If necessary
open a PR on this specifically please.
It’s on my todo list, but I’d like to take another run at PR
17264
> On 19 Jul 2015, at 17:58, George Neville-Neil wrote:
> Since Kristof is already working on this, I'll let him address it. If
> necessary
> open a PR on this specifically please.
It’s on my todo list, but I’d like to take another run at PR 172648 first.
Regards,
Kristof
_
On 15 Jul 2015, at 3:54, Colin Percival wrote:
On 07/15/15 00:44, Kristof Provost wrote:
On 14 Jul 2015, at 21:23, Mark Felder wrote:
On Tue, Jul 14, 2015, at 13:54, Colin Percival wrote:
More precisely *pf* is a known issue. It's inserting TCP checksums
into TSO packets. I reported this
On 07/15/15 00:44, Kristof Provost wrote:
>> On 14 Jul 2015, at 21:23, Mark Felder wrote:
>> On Tue, Jul 14, 2015, at 13:54, Colin Percival wrote:
>>> More precisely *pf* is a known issue. It's inserting TCP checksums
>>> into TSO packets. I reported this a long time ago and I don't know
>>> why
> On 14 Jul 2015, at 21:23, Mark Felder wrote:
> On Tue, Jul 14, 2015, at 13:54, Colin Percival wrote:
>> On 07/14/15 09:15, Mark Felder wrote:
>> More precisely *pf* is a known issue. It's inserting TCP checksums
>> into TSO packets. I reported this a long time ago and I don't know
>> why pf s
> On 14 Jul 2015, at 18:15, Mark Felder wrote:
>
>
>
> On Tue, Jul 14, 2015, at 07:36, Sydney Meyer wrote:
>> Hello everybody,
>>
>> i have noticed some odd behaviour with networking under Xen with FreeBSD
>> 10 as a DomU.
>>
>> - IPv6 (T
On Tue, Jul 14, 2015, at 13:54, Colin Percival wrote:
> On 07/14/15 09:15, Mark Felder wrote:
> > On Tue, Jul 14, 2015, at 07:36, Sydney Meyer wrote:
> >> - Dropped/Stalled Connections with TCP Segmentation Offload and pf
> >> enabled.
> >
> > TSO is a known issue. I've been turning it off for y
On 07/14/15 09:15, Mark Felder wrote:
> On Tue, Jul 14, 2015, at 07:36, Sydney Meyer wrote:
>> - Dropped/Stalled Connections with TCP Segmentation Offload and pf
>> enabled.
>
> TSO is a known issue. I've been turning it off for years to get FreeBSD
> to play nice on Xen.
More precisely *pf* is a
On Tue, Jul 14, 2015, at 07:36, Sydney Meyer wrote:
> Hello everybody,
>
> i have noticed some odd behaviour with networking under Xen with FreeBSD
> 10 as a DomU.
>
> - IPv6 (TCP) bandwith drops from ~10 Gbit/s IPv4 to around 3 Gbit/s IPv6.
> (measured with iperf)
>
Hello everybody,
i have noticed some odd behaviour with networking under Xen with FreeBSD 10 as
a DomU.
- IPv6 (TCP) bandwith drops from ~10 Gbit/s IPv4 to around 3 Gbit/s IPv6.
(measured with iperf)
- Dropped/Stalled Connections with TCP Segmentation Offload and pf enabled.
- IPSEC-enabled
13 matches
Mail list logo
