Author: lwhsu (ports committer)
Date: Fri Jan 5 08:29:32 2018
New Revision: 327582
URL: https://svnweb.freebsd.org/changeset/base/327582
Log:
Fix typo & build
Approved by: kevlo
Modified:
head/usr.sbin/dumpcis/readcis.c
Modified: head/usr.sbin/dumpcis/readcis.c
===
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
Author: oshogbo
Date: Fri Jan 5 09:31:41 2018
New Revision: 327583
URL: https://svnweb.freebsd.org/changeset/base/327583
Log:
Build service tests with Casper support.
Modified:
head/lib/libcasper/services/cap_dns/tests/Makefile
head/lib/libcasper/services/cap_grp/tests/Makefile
head/lib/
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 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:
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/
Author: fsu
Date: Fri Jan 5 10:04:01 2018
New Revision: 327584
URL: https://svnweb.freebsd.org/changeset/base/327584
Log:
Add 64bit feature support.
Reviewed by:kevlo, pfg (mentor)
Approved by:pfg (mentor)
MFC after: 6 months
Differential Revision:https://reviews.
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
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 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
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
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 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 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 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 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
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
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 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
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 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
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
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: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 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: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
> Author: eadler
> Date: Fri Jan 5 07:14:39 2018
> New Revision: 327577
> URL: https://svnweb.freebsd.org/changeset/base/327577
>
> Log:
> cam/da: QUIRK: Add 4K quirks for WD Red and Black MHDDs
>
> PR: 188685
> Submitted by: Jeremy Chadwick
> Reported by:Marti
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
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
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
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
Author: jhb
Date: Fri Jan 5 18:32:46 2018
New Revision: 327591
URL: https://svnweb.freebsd.org/changeset/base/327591
Log:
Correct comment. procfs_doprocfile implements 'file', not 'self'.
Modified:
head/sys/fs/procfs/procfs.c
Modified: head/sys/fs/procfs/procfs.c
==
Author: avg
Date: Fri Jan 5 19:15:24 2018
New Revision: 327593
URL: https://svnweb.freebsd.org/changeset/base/327593
Log:
Fix a couple of comments in AMD Virtual Machine Control Block structure
MFC after:1 week
Modified:
head/sys/amd64/vmm/amd/vmcb.h
Modified: head/sys/amd64/vmm/am
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
On Thursday, January 04, 2018 09:59:34 PM John Baldwin wrote:
> Author: jhb
> Date: Thu Jan 4 21:59:34 2018
> New Revision: 327561
> URL: https://svnweb.freebsd.org/changeset/base/327561
>
> Log:
> Report offset relative to the backing object for kinfo_vmentry structures.
>
> For the pathn
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
Author: glebius
Date: Fri Jan 5 20:21:46 2018
New Revision: 327596
URL: https://svnweb.freebsd.org/changeset/base/327596
Log:
In sendfile_iodone() both pru_abort and sorele need to be executed
with proper VNET context set.
Reported by: sbruno
MFC after:2 weeks
Modified:
head/sy
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
Author: kib
Date: Fri Jan 5 21:06:19 2018
New Revision: 327597
URL: https://svnweb.freebsd.org/changeset/base/327597
Log:
Make it possible to re-evaluate cpu_features.
Add cpuctl(4) ioctl CPUCTL_EVAL_CPU_FEATURES which forces re-read of
cpu_features, cpu_features2, cpu_stdext_features, a
Author: jhb
Date: Fri Jan 5 22:26:23 2018
New Revision: 327598
URL: https://svnweb.freebsd.org/changeset/base/327598
Log:
Remove LINK_MAX.
After recent changes to change filesystems to use filesystem-specific
limits, LINK_MAX is no longer used in the base system. Applications
should i
Author: jkim
Date: Fri Jan 5 23:21:47 2018
New Revision: 327605
URL: https://svnweb.freebsd.org/changeset/base/327605
Log:
Merge ACPICA 20180105.
Added:
head/sys/contrib/dev/acpica/include/actbinfo.h
- copied unchanged from r327603,
vendor-sys/acpica/dist/source/include/actbinfo.h
> 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
Author: sbruno
Date: Fri Jan 5 23:50:50 2018
New Revision: 327606
URL: https://svnweb.freebsd.org/changeset/base/327606
Log:
Handle misconfigured/nonexistent pcidev for comconsole instead of BTX panic.
PR: 203319
Reviewed by: imp jhb
MFC after:2 weeks
Sponsored by: Lim
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
Author: jkim
Date: Sat Jan 6 03:41:35 2018
New Revision: 327607
URL: https://svnweb.freebsd.org/changeset/base/327607
Log:
Fix a header inclusion missed in the previous commit.
Reported by: Michael Butler (imb at protected-networks dot net)
Modified:
head/sys/contrib/dev/acpica/acpica_
Author: imp
Date: Sat Jan 6 06:00:40 2018
New Revision: 327611
URL: https://svnweb.freebsd.org/changeset/base/327611
Log:
There's no need / benefit from deleting the variable before we set it.
Sponsored by: Netflix
Modified:
head/usr.sbin/efibootmgr/efibootmgr.c
Modified: head/usr.sbin
Author: imp
Date: Sat Jan 6 06:00:45 2018
New Revision: 327612
URL: https://svnweb.freebsd.org/changeset/base/327612
Log:
Invent new #defines for the biospci_{read,write}_config function to
specify the width and use them everywhere.
Sponsored by: Netflix
Modified:
head/stand/i386/libf
Author: imp
Date: Sat Jan 6 06:00:34 2018
New Revision: 327610
URL: https://svnweb.freebsd.org/changeset/base/327610
Log:
Fix usage strings. -d and -p were removed before this was committed to
FreeBSD, but the strings weren't updated.
Sponsored by: Netflix
Modified:
head/usr.sbin/efib
Author: eadler
Date: Sat Jan 6 07:02:24 2018
New Revision: 327614
URL: https://svnweb.freebsd.org/changeset/base/327614
Log:
morse(6): implement support for decoding morse code
- Use `-r` for "reverse" mode and to match DragonFlyBSD.
- Move defines around to clear up logic
- use `errx`
On 5 January 2018 at 23:02, Eitan Adler wrote:
> Author: eadler
> Date: Sat Jan 6 07:02:24 2018
> New Revision: 327614
> URL: https://svnweb.freebsd.org/changeset/base/327614
>
> Log:
> morse(6): implement support for decoding morse code
>
> - Use `-r` for "reverse" mode and to match DragonFl
Author: eadler
Date: Sat Jan 6 07:48:17 2018
New Revision: 327615
URL: https://svnweb.freebsd.org/changeset/base/327615
Log:
morse(6): minor nits
- Use copyright comment header
- Make it easier to compile on !FreeBSD
- Diff reduction against DragonFlyBSD
Modified:
head/usr.bin/morse
52 matches
Mail list logo