On 05/01/2018 13:11, Slawa Olhovchenkov wrote:
On Fri, Jan 05, 2018 at 03:50:31AM +0700, Eugene Grosbein wrote:
05.01.2018 3:05, Steven Hartland wrote:
Author: smh
Date: Thu Jan 4 20:05:47 2018
New Revision: 327559
URL: https://svnweb.freebsd.org/changeset/base/327559
Log:
Disabled the u
On 05.01.2018 19:11, Steven Hartland wrote:
>> I am mostly concerned about the overhead of manual calculation but my
>> knowledge is a bit rusty right now and lagg has always been special so
>> please try this out and see.
>>
>
> I've not been able to find any such option:
> head:src> grep -ri rss
On 05/01/2018 23:30, Scott Long wrote:
On Jan 5, 2018, at 11:20 AM, Eugene Grosbein wrote:
CC'ng scottl@ as author of the change in question.
06.01.2018 0:39, Matt Joras wrote:
For what it's worth, this was the conclusion I came to, and at Isilon
we've made the same change being discussed
> On Jan 5, 2018, at 11:20 AM, Eugene Grosbein wrote:
>
> CC'ng scottl@ as author of the change in question.
>
> 06.01.2018 0:39, Matt Joras wrote:
>
For what it's worth, this was the conclusion I came to, and at Isilon
we've made the same change being discussed here. For the case o
On 05/01/2018 17:39, Matt Joras wrote:
On Fri, Jan 5, 2018 at 9:32 AM, Eugene Grosbein wrote:
06.01.2018 0:28, Matt Joras wrote:
For what it's worth, this was the conclusion I came to, and at Isilon
we've made the same change being discussed here. For the case of
drivers that end up using a
06.01.2018 2:20, Navdeep Parhar пишет:
> On Fri, Jan 5, 2018 at 10:23 AM, Eugene Grosbein wrote:
>> 06.01.2018 1:03, Steven Hartland wrote:
>>
>>> Is there a way to determine if the mbuf is a forwarded mbuf of not?
>>
>> Yes: m->m_pkthdr.rcvif is defined in case of forwarding.
>> It is NULL for lo
On Fri, Jan 5, 2018 at 10:23 AM, Eugene Grosbein wrote:
> 06.01.2018 1:03, Steven Hartland wrote:
>
>> Is there a way to determine if the mbuf is a forwarded mbuf of not?
>
> Yes: m->m_pkthdr.rcvif is defined in case of forwarding.
> It is NULL for locally originated packets.
>
Can't rely on this
06.01.2018 1:03, Steven Hartland wrote:
> Is there a way to determine if the mbuf is a forwarded mbuf of not?
Yes: m->m_pkthdr.rcvif is defined in case of forwarding.
It is NULL for locally originated packets.
___
svn-src-head@freebsd.org mailing list
CC'ng scottl@ as author of the change in question.
06.01.2018 0:39, Matt Joras wrote:
>>> For what it's worth, this was the conclusion I came to, and at Isilon
>>> we've made the same change being discussed here. For the case of
>>> drivers that end up using a queue index for the flowid, you end
On 05/01/2018 17:06, Eugene Grosbein wrote:
05.01.2018 23:11, Steven Hartland wrote:
What do others think, am I missing something?
You still consider only TCP case missing IP forwarning case when all IP packets
are transit coming from lagg0 and going out via lagg1.
Just going out via a laggX
On Fri, Jan 5, 2018 at 9:32 AM, Eugene Grosbein wrote:
> 06.01.2018 0:28, Matt Joras wrote:
>
>> For what it's worth, this was the conclusion I came to, and at Isilon
>> we've made the same change being discussed here. For the case of
>> drivers that end up using a queue index for the flowid, you
06.01.2018 0:38, Steven Hartland wrote:
>> How do you know that flowid of incoming packet is preserved on outgoing
>> path? It should not.
> https://github.com/freebsd/freebsd/blob/master/sys/netinet/ip_output.c#L234
This is a bug then. It should keep previously computed flowid value (for
outgo
On 05/01/2018 17:16, Eugene Grosbein wrote:
That is, there is no guarantee of persistance of flowid of incoming packets
as they can be received with distinct ports of lagg being distinct hardware
computing flowid differently. Some ports may not support RSS at all.
We should not use incoming har
06.01.2018 0:28, Matt Joras wrote:
> For what it's worth, this was the conclusion I came to, and at Isilon
> we've made the same change being discussed here. For the case of
> drivers that end up using a queue index for the flowid, you end up
> with pathological behavior on the lagg; the flowid en
On Fri, Jan 05, 2018 at 11:59:30PM +0700, Eugene Grosbein wrote:
> 05.01.2018 21:38, Slawa Olhovchenkov wrote:
>
> >>> Irrelevant to RSS and etc. flowid distribution in lacp case work very
> >>> bad. This is good and must be MFC (IMHO).
> >>
> >> It may work bad depending on NIC and/or traffic ty
06.01.2018 0:12, Steven Hartland wrote:
>>> I hope there's some improvements that can be made, for example if we
>>> can determine
>>> the stream was instigated remotely then flowid would always be valid
>>> hence we can use it assuming it
>>> matches the requested spec or if
On Fri, Jan 5, 2018 at 7:42 AM, Steven Hartland wrote:
> My current thinking is that flowid shouldn't be used for either LACP or
> loadbalance protocols as doing so will almost certainly lead to unexpected
> behavior (the stated lagghash may not be valid).
>
> Regards
> Steve
>
For what i
05.01.2018 22:42, Steven Hartland wrote:
>> RSS by definition has meaning to received stream. What is "outbound"
>> stream
>> in this context, why can the hash calculatiom method change and what
>> exactly
>> does it mean "a stream being incorrectly split"?
> Yes RSS is i
On 05/01/2018 17:02, Eugene Grosbein wrote:
05.01.2018 22:13, Steven Hartland wrote:
I hope there's some improvements that can be made, for example if we can
determine
the stream was instigated remotely then flowid would always be valid hence we
can use it assuming it
matches the requested
05.01.2018 23:11, Steven Hartland wrote:
> What do others think, am I missing something?
You still consider only TCP case missing IP forwarning case when all IP packets
are transit coming from lagg0 and going out via lagg1.
IP forwarding case benefits from pre-computed RSS flowid since 8.0-RELEA
05.01.2018 22:13, Steven Hartland wrote:
> I hope there's some improvements that can be made, for example if we can
> determine
> the stream was instigated remotely then flowid would always be valid
> hence we can use it assuming it
> matches the requested spec or if we can m
05.01.2018 21:38, Slawa Olhovchenkov wrote:
>>> Irrelevant to RSS and etc. flowid distribution in lacp case work very
>>> bad. This is good and must be MFC (IMHO).
>>
>> It may work bad depending on NIC and/or traffic type.
>> It works just fine in common case of IP forwarding for packets with TCP
On 05/01/2018 09:41, hiren panchasara wrote:
IIRC, with 'RSS' in kernconf, most NIC drivers and stack should do the
right thing. Look at drivers and also conn startup code in TCP as I
recall it doing the flowid mapping correctly when stream originated from
the other side and had flowid assigned t
On 05/01/2018 14:38, Slawa Olhovchenkov wrote:
On Fri, Jan 05, 2018 at 08:36:48PM +0700, Eugene Grosbein wrote:
05.01.2018 20:11, Slawa Olhovchenkov wrote:
Irrelevant to RSS and etc. flowid distribution in lacp case work very
bad. This is good and must be MFC (IMHO).
It may work bad dependin
On 05/01/2018 13:49, Eugene Grosbein wrote:
05.01.2018 16:26, Steven Hartland пишет:
On 05/01/2018 02:01, Eugene Grosbein wrote:
05.01.2018 4:52, Steven Hartland wrote:
RSS by definition has meaning to received stream. What is "outbound" stream
in this context, why can the hash calculatiom me
On 05/01/2018 13:41, Eugene Grosbein wrote:
05.01.2018 16:34, Steven Hartland wrote:
I hope there's some improvements that can be made, for example if we can
determine
the stream was instigated remotely then flowid would always be valid hence we
can use it assuming it
matches the requested sp
On Fri, Jan 05, 2018 at 08:36:48PM +0700, Eugene Grosbein wrote:
> 05.01.2018 20:11, Slawa Olhovchenkov wrote:
>
> > Irrelevant to RSS and etc. flowid distribution in lacp case work very
> > bad. This is good and must be MFC (IMHO).
>
> It may work bad depending on NIC and/or traffic type.
> It
On Fri, Jan 05, 2018 at 03:50:31AM +0700, Eugene Grosbein wrote:
> 05.01.2018 3:05, Steven Hartland wrote:
>
> > Author: smh
> > Date: Thu Jan 4 20:05:47 2018
> > New Revision: 327559
> > URL: https://svnweb.freebsd.org/changeset/base/327559
> >
> > Log:
> > Disabled the use of flowid for lag
05.01.2018 16:26, Steven Hartland пишет:
>
> On 05/01/2018 02:01, Eugene Grosbein wrote:
>> 05.01.2018 4:52, Steven Hartland wrote:
>>
RSS by definition has meaning to received stream. What is "outbound" stream
in this context, why can the hash calculatiom method change and what
ex
05.01.2018 16:34, Steven Hartland wrote:
>>> I hope there's some improvements that can be made, for example if we can
>>> determine
>>> the stream was instigated remotely then flowid would always be valid hence
>>> we can use it assuming it
>>> matches the requested spec or if we can make it cle
05.01.2018 20:11, Slawa Olhovchenkov wrote:
> Irrelevant to RSS and etc. flowid distribution in lacp case work very
> bad. This is good and must be MFC (IMHO).
It may work bad depending on NIC and/or traffic type.
It works just fine in common case of IP forwarding for packets with TCP/UDP
inside
I found https://wiki.freebsd.org/NetworkRSS but I couldn't see any
options mentioned, is there a sysctl or kernel option for that Adrian?
For reference our current test is on a production LB running
11.0-RELEASE. We're in the process of updating our HEAD box for
additional testing.
On 05/01/
On 01/04/18 at 11:37P, Steven Hartland wrote:
>
>
> On 04/01/2018 22:42, hiren panchasara wrote:
> > On 01/04/18 at 09:52P, Steven Hartland wrote:
> >> On 04/01/2018 20:50, Eugene Grosbein wrote:
> >>> 05.01.2018 3:05, Steven Hartland wrote:
> >>>
> Author: smh
> Date: Thu Jan 4 20:05:
On 05/01/2018 02:09, Eugene Grosbein wrote:
05.01.2018 6:37, Steven Hartland wrote:
Our TCP stack seems fragile during setup to out of order packets
which this multipath behavior causes, we've seen this on our loadbalancers
which is what triggered the investigation. The concrete result is many
On 05/01/2018 02:01, Eugene Grosbein wrote:
05.01.2018 4:52, Steven Hartland wrote:
RSS by definition has meaning to received stream. What is "outbound" stream
in this context, why can the hash calculatiom method change and what exactly
does it mean "a stream being incorrectly split"?
Yes RSS
does it also happen when you actually enable RSS in the kernel? Since
like I went through a whole lot of pain to assign a flowid at
connection setup time.
-a
On 4 January 2018 at 15:37, Steven Hartland wrote:
>
>
> On 04/01/2018 22:42, hiren panchasara wrote:
>
> On 01/04/18 at 09:52P, Steven
05.01.2018 6:37, Steven Hartland wrote:
> Our TCP stack seems fragile during setup to out of order packets
> which this multipath behavior causes, we've seen this on our loadbalancers
> which is what triggered the investigation. The concrete result is many
> aborted TCP connections,
> over 300k
05.01.2018 4:52, Steven Hartland wrote:
>> RSS by definition has meaning to received stream. What is "outbound" stream
>> in this context, why can the hash calculatiom method change and what exactly
>> does it mean "a stream being incorrectly split"?
> Yes RSS is indeed a received stream but that
On 04/01/2018 22:42, hiren panchasara wrote:
On 01/04/18 at 09:52P, Steven Hartland wrote:
On 04/01/2018 20:50, Eugene Grosbein wrote:
05.01.2018 3:05, Steven Hartland wrote:
Author: smh
Date: Thu Jan 4 20:05:47 2018
New Revision: 327559
URL: https://svnweb.freebsd.org/changeset/base/32755
On 01/04/18 at 09:52P, Steven Hartland wrote:
> On 04/01/2018 20:50, Eugene Grosbein wrote:
> > 05.01.2018 3:05, Steven Hartland wrote:
> >
> >> Author: smh
> >> Date: Thu Jan 4 20:05:47 2018
> >> New Revision: 327559
> >> URL: https://svnweb.freebsd.org/changeset/base/327559
> >>
> >> Log:
> >>
On 04/01/2018 20:50, Eugene Grosbein wrote:
05.01.2018 3:05, Steven Hartland wrote:
Author: smh
Date: Thu Jan 4 20:05:47 2018
New Revision: 327559
URL: https://svnweb.freebsd.org/changeset/base/327559
Log:
Disabled the use of flowid for lagg by default
Disabled the use of RSS hash f
05.01.2018 3:05, Steven Hartland wrote:
> Author: smh
> Date: Thu Jan 4 20:05:47 2018
> New Revision: 327559
> URL: https://svnweb.freebsd.org/changeset/base/327559
>
> Log:
> Disabled the use of flowid for lagg by default
>
> Disabled the use of RSS hash from the network card aka flowid
Author: smh
Date: Thu Jan 4 20:05:47 2018
New Revision: 327559
URL: https://svnweb.freebsd.org/changeset/base/327559
Log:
Disabled the use of flowid for lagg by default
Disabled the use of RSS hash from the network card aka flowid for
lagg(4) interfaces by default as it's currently incom
43 matches
Mail list logo
