On Mon, 2015-05-25 at 19:35 -0400, John A. Sullivan III wrote:
> On Mon, 2015-05-25 at 16:19 -0700, Eric Dumazet wrote:
> > On Mon, 2015-05-25 at 18:44 -0400, John A. Sullivan III wrote:
> > > On Mon, 2015-05-25 at 15:38 -0700, Eric Dumazet wrote:
> > > > On Mon, 2015-05-25 at 18:22 -0400, John A.
On Mon, 2015-05-25 at 16:19 -0700, Eric Dumazet wrote:
> On Mon, 2015-05-25 at 18:44 -0400, John A. Sullivan III wrote:
> > On Mon, 2015-05-25 at 15:38 -0700, Eric Dumazet wrote:
> > > On Mon, 2015-05-25 at 18:22 -0400, John A. Sullivan III wrote:
> > >
> > > > 2) Why do we still not negotiate the
On Mon, 2015-05-25 at 18:44 -0400, John A. Sullivan III wrote:
> On Mon, 2015-05-25 at 15:38 -0700, Eric Dumazet wrote:
> > On Mon, 2015-05-25 at 18:22 -0400, John A. Sullivan III wrote:
> >
> > > 2) Why do we still not negotiate the 16MB buffer that we get when we are
> > > not using GRE?
> >
>
On Mon, 2015-05-25 at 15:38 -0700, Eric Dumazet wrote:
> On Mon, 2015-05-25 at 18:22 -0400, John A. Sullivan III wrote:
>
> > 2) Why do we still not negotiate the 16MB buffer that we get when we are
> > not using GRE?
>
> What exact NIC handles receive side ?
>
> If drivers allocate a full 4KB p
On Mon, 2015-05-25 at 18:22 -0400, John A. Sullivan III wrote:
> 2) Why do we still not negotiate the 16MB buffer that we get when we are
> not using GRE?
What exact NIC handles receive side ?
If drivers allocate a full 4KB page to hold each frame,
plus sk_buff overhead,
then 32MB of kernel memo
On Mon, 2015-05-25 at 17:34 -0400, John A. Sullivan III wrote:
> On Mon, 2015-05-25 at 13:41 -0700, Eric Dumazet wrote:
> > On Mon, 2015-05-25 at 15:21 -0400, John A. Sullivan III wrote:
> >
> > >
> > > Thanks, Eric. I really appreciate the help. This is a problem holding up
> > > a very high pro
On Mon, 2015-05-25 at 13:41 -0700, Eric Dumazet wrote:
> On Mon, 2015-05-25 at 15:21 -0400, John A. Sullivan III wrote:
>
> >
> > Thanks, Eric. I really appreciate the help. This is a problem holding up
> > a very high profile, major project and, for the life of me, I can't
> > figure out why my
On Mon, 2015-05-25 at 13:41 -0700, Eric Dumazet wrote:
> lpaa23:~# DUMP_TCP_INFO=1 ./netperf -H 10.7.8.152 -Cc -t OMNI -l 20
> OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.7.8.152 () port 0
> AF_INET
> tcpi_rto 281000 tcpi_ato 0 tcpi_pmtu 1476 tcpi_rcv_ssthresh 28720
> tcpi_rtt 8043
On Mon, 2015-05-25 at 15:21 -0400, John A. Sullivan III wrote:
>
> Thanks, Eric. I really appreciate the help. This is a problem holding up
> a very high profile, major project and, for the life of me, I can't
> figure out why my TCP window size is reduced inside the GRE tunnel.
>
> Here is the
On Mon, 2015-05-25 at 15:29 -0400, John A. Sullivan III wrote:
> On Mon, 2015-05-25 at 15:21 -0400, John A. Sullivan III wrote:
> > On Mon, 2015-05-25 at 12:05 -0700, Eric Dumazet wrote:
> > > On Mon, 2015-05-25 at 14:49 -0400, John A. Sullivan III wrote:
> > > > On Mon, 2015-05-25 at 09:58 -0700,
On Mon, 2015-05-25 at 15:21 -0400, John A. Sullivan III wrote:
> On Mon, 2015-05-25 at 12:05 -0700, Eric Dumazet wrote:
> > On Mon, 2015-05-25 at 14:49 -0400, John A. Sullivan III wrote:
> > > On Mon, 2015-05-25 at 09:58 -0700, Eric Dumazet wrote:
> > > > On Mon, 2015-05-25 at 11:42 -0400, John A.
On Mon, 2015-05-25 at 12:05 -0700, Eric Dumazet wrote:
> On Mon, 2015-05-25 at 14:49 -0400, John A. Sullivan III wrote:
> > On Mon, 2015-05-25 at 09:58 -0700, Eric Dumazet wrote:
> > > On Mon, 2015-05-25 at 11:42 -0400, John A. Sullivan III wrote:
> > > > Hello, all. I hope this is the correct lis
On Mon, 2015-05-25 at 14:49 -0400, John A. Sullivan III wrote:
> On Mon, 2015-05-25 at 09:58 -0700, Eric Dumazet wrote:
> > On Mon, 2015-05-25 at 11:42 -0400, John A. Sullivan III wrote:
> > > Hello, all. I hope this is the correct list for this question. We are
> > > having serious problems on h
On Mon, 2015-05-25 at 09:58 -0700, Eric Dumazet wrote:
> On Mon, 2015-05-25 at 11:42 -0400, John A. Sullivan III wrote:
> > Hello, all. I hope this is the correct list for this question. We are
> > having serious problems on high BDP networks using GRE tunnels. Our
> > traces show it to be a TCP
On Mon, 2015-05-25 at 09:58 -0700, Eric Dumazet wrote:
> 1) Non GRE session
>
> lpaa23:~# DUMP_TCP_INFO=1 ./netperf -H lpaa24 -Cc -t OMNI
> OMNI Send TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
> lpaa24.prod.google.com () port 0 AF_INET
> tcpi_rto 201000 tcpi_ato 0 tcpi_pmtu 1500 tcpi_rcv_ssth
On Mon, 2015-05-25 at 11:42 -0400, John A. Sullivan III wrote:
> Hello, all. I hope this is the correct list for this question. We are
> having serious problems on high BDP networks using GRE tunnels. Our
> traces show it to be a TCP Window problem. When we test without GRE,
> throughput is wir
Hello, all. I hope this is the correct list for this question. We are
having serious problems on high BDP networks using GRE tunnels. Our
traces show it to be a TCP Window problem. When we test without GRE,
throughput is wire speed and traces show the window size to be 16MB
which is what we con
17 matches
Mail list logo
