Re: how to find out if an IP address is assigned statically or dynamically?
On Feb 11, 2013 10:44 PM, "h bagade" wrote: > > Hi all, > > I want to know if there is a way to find out if an interface address is > assigned by dhcp or statically? For example, any distinctive flag or > something like that on ifconfig output! or any other way except processing > dhclient leases files? As per my limited knowledge, no. The only reliable way is to look at /var/db/dhclient.leases. files as you mentioned. Hiren ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: request
On Wed, Mar 13, 2013 at 12:02 AM, rathish mudaliar wrote: > Hi, > > I request you to kindly add me to your mailing list. http://lists.freebsd.org/mailman/listinfo/freebsd-net This is where you can go and subscribe. cheers, Hiren > > > Regards > Rathish.R > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: bce(4) panics, 9.2rc1
On Wed, Jul 24, 2013 at 2:23 PM, Sean Bruno wrote: > On Wed, 2013-07-24 at 14:07 -0700, Sean Bruno wrote: >> Running 9.2 in production load mail servers. We're hitting the >> "watchdog" message and crashing with the stable/9 version. We're >> reverting the change from 2 weeks ago and seeing if it still happens. >> We didn't see this from stable/9 from about a month ago. >> pciconf -lvb: http://people.freebsd.org/~hiren/pciconf.txt Thanks, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: DTrace network providers
On Thu, Aug 22, 2013 at 8:36 AM, George Neville-Neil wrote: > > On Aug 21, 2013, at 1:00 , Mark Johnston wrote: > > > Hello! > > > > I've ported the ip, tcp and udp DTrace providers to FreeBSD, following > > the Solaris documentation here: > > > > https://wikis.oracle.com/display/DTrace/ip+Provider > > https://wikis.oracle.com/display/DTrace/tcp+Provider > > https://wikis.oracle.com/display/DTrace/udp+Provider > > > > My implementation of these providers makes use of dynamic translators, > > for which FreeBSD support was added in r254468; this patch won't compile > > with earlier revisions. The use of dynamic translators means that > > existing DTrace scripts which use these providers will just work when run > > on FreeBSD - no modifications needed. In particular, all of the examples > > in the links above will work properly on FreeBSD with my diff. > > > > I've collected a bunch of example scripts for these providers and placed > > them here: > > > > http://people.freebsd.org/~markj/dtrace/network-providers/ > > > > To run one you just need to execute "dtrace -s
Re: DTrace network providers
On Thu, Aug 22, 2013 at 3:05 PM, Yuri wrote: > On 08/20/2013 22:00, Mark Johnston wrote: >> >> The patch is here: >> >> >> http://people.freebsd.org/~markj/patches/network-providers/network-providers-1.diff >> >> It depends on r254468. To use it, just recompile the kernel (assuming > > > Your patch fails to apply, see below. fwiw, I update the laptop to an hour back CURRENT r254665 and patch applied cleanly. cheers, hiren > > I use clean r254468 as you suggested. > > Yuri > > -- > |diff --git a/sys/netinet/ip_output.c b/sys/netinet/ip_output.c > |index 0a87e7a..15196e0 100644 > |--- a/sys/netinet/ip_output.c > |+++ b/sys/netinet/ip_output.c > -- > Patching file a/sys/netinet/ip_output.c using Plan A... > Hunk #1 succeeded at 34. > Hunk #2 succeeded at 48. > Hunk #3 succeeded at 66. > Hunk #4 failed at 625. > Hunk #5 succeeded at 660 with fuzz 2. > 1 out of 5 hunks failed--saving rejects to a/sys/netinet/ip_output.c.rej > > -- > |diff --git a/sys/netinet6/nd6.c b/sys/netinet6/nd6.c > |index 7755da1..9eaa0aa 100644 > |--- a/sys/netinet6/nd6.c > |+++ b/sys/netinet6/nd6.c > -- > Patching file a/sys/netinet6/nd6.c using Plan A... > Hunk #1 succeeded at 34. > Hunk #2 succeeded at 51. > Hunk #3 succeeded at 64. > Hunk #4 failed at 2086. > 1 out of 4 hunks failed--saving rejects to a/sys/netinet6/nd6.c.rej > Hmm... The next patch looks like a unified diff to me... > The text leading up to this was: > > > ___ > freebsd-dtr...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-dtrace > To unsubscribe, send any mail to "freebsd-dtrace-unsubscr...@freebsd.org" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: DTrace network providers
On Thu, Aug 22, 2013 at 10:25 AM, hiren panchasara < hiren.panchas...@gmail.com> wrote: > > > > On Thu, Aug 22, 2013 at 8:36 AM, George Neville-Neil wrote: > >> >> On Aug 21, 2013, at 1:00 , Mark Johnston wrote: >> >> > Hello! >> > >> > I've ported the ip, tcp and udp DTrace providers to FreeBSD, following >> > the Solaris documentation here: >> > >> > https://wikis.oracle.com/display/DTrace/ip+Provider >> > https://wikis.oracle.com/display/DTrace/tcp+Provider >> > https://wikis.oracle.com/display/DTrace/udp+Provider >> > >> > My implementation of these providers makes use of dynamic translators, >> > for which FreeBSD support was added in r254468; this patch won't compile >> > with earlier revisions. The use of dynamic translators means that >> > existing DTrace scripts which use these providers will just work when >> run >> > on FreeBSD - no modifications needed. In particular, all of the examples >> > in the links above will work properly on FreeBSD with my diff. >> > >> > I've collected a bunch of example scripts for these providers and placed >> > them here: >> > >> > http://people.freebsd.org/~markj/dtrace/network-providers/ >> > >> > To run one you just need to execute "dtrace -s
Re: mbuf autotuning changes
On Fri, Sep 6, 2013 at 12:14 PM, Alfred Perlstein wrote:
> On 9/6/13 12:10 PM, hiren panchasara wrote:
>
>> tunable_mbinit() in kern_mbuf.c looks like this:
>>
>> 119 /*
>> 120 * The default limit for all mbuf related memory is 1/2 of all
>> 121 * available kernel memory (physical or kmem).
>> 122 * At most it can be 3/4 of available kernel memory.
>> 123 */
>> 124 realmem = qmin((quad_t)physmem * PAGE_SIZE,
>> 125 vm_map_max(kmem_map) - vm_map_min(kmem_map));
>> 126 maxmbufmem = realmem / 2;
>> 127 TUNABLE_QUAD_FETCH("kern.ipc.**maxmbufmem", &maxmbufmem);
>> 128 if (maxmbufmem > realmem / 4 * 3)
>> 129 maxmbufmem = realmem / 4 * 3;
>>
>> If I am reading the code correctly, we loose the value on line 126 when we
>> do FETCH on line 127.
>>
>> And after line 127, if we havent specified kern.ipc.maxmbufmem (in
>> loader.conf - I guess...), we set that value to 0.
>>
>> And because of that the if condition on line 128 is almost always false?
>>
>> What am I missing here?
>>
>> Thanks,
>> Hiren
>> __**_
>> freebsd-net@freebsd.org mailing list
>> http://lists.freebsd.org/**mailman/listinfo/freebsd-net<http://lists.freebsd.org/mailman/listinfo/freebsd-net>
>> To unsubscribe, send any mail to
>> "freebsd-net-unsubscribe@**freebsd.org
>> "
>>
>> I think TUNABLE_*_FETCH will only write to the variable if it explicitly
> set.
>
> Meaning, unless the user actually sets a value in loader.conf then 127 is
> a no-op.
>
Thanks Navdeep and Alfred.
Thats correct. Its not touching the var if its not set.
I guess the other TUNABLE_INT_FETCHs later in the function checking for
variable ==0 confused me. i.e. nmbclusters.
131 TUNABLE_INT_FETCH("kern.ipc.nmbclusters", &nmbclusters);
132 if (nmbclusters == 0)
133 nmbclusters = maxmbufmem / MCLBYTES / 4;
But those are global variable so here we are just checking if they are
explicitly set of not. If not, we will set them.
For maxmbufmem, we will set it to 1/2 the realmem. and if user sets it
explicitly than we will make sure its not more than 3/4 of the realmem.
Thanks again.
Hiren
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
mbuf autotuning changes
tunable_mbinit() in kern_mbuf.c looks like this:
119 /*
120 * The default limit for all mbuf related memory is 1/2 of all
121 * available kernel memory (physical or kmem).
122 * At most it can be 3/4 of available kernel memory.
123 */
124 realmem = qmin((quad_t)physmem * PAGE_SIZE,
125 vm_map_max(kmem_map) - vm_map_min(kmem_map));
126 maxmbufmem = realmem / 2;
127 TUNABLE_QUAD_FETCH("kern.ipc.maxmbufmem", &maxmbufmem);
128 if (maxmbufmem > realmem / 4 * 3)
129 maxmbufmem = realmem / 4 * 3;
If I am reading the code correctly, we loose the value on line 126 when we
do FETCH on line 127.
And after line 127, if we havent specified kern.ipc.maxmbufmem (in
loader.conf - I guess...), we set that value to 0.
And because of that the if condition on line 128 is almost always false?
What am I missing here?
Thanks,
Hiren
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: mbuf autotuning changes
On Fri, Sep 6, 2013 at 12:38 PM, Alfred Perlstein wrote:
> On 9/6/13 12:36 PM, hiren panchasara wrote:
>
>> On Fri, Sep 6, 2013 at 12:14 PM, Alfred Perlstein wrote:
>>
>> On 9/6/13 12:10 PM, hiren panchasara wrote:
>>>
>>> tunable_mbinit() in kern_mbuf.c looks like this:
>>>>
>>>> 119 /*
>>>> 120 * The default limit for all mbuf related memory is 1/2 of
>>>> all
>>>> 121 * available kernel memory (physical or kmem).
>>>> 122 * At most it can be 3/4 of available kernel memory.
>>>> 123 */
>>>> 124 realmem = qmin((quad_t)physmem * PAGE_SIZE,
>>>> 125 vm_map_max(kmem_map) - vm_map_min(kmem_map));
>>>> 126 maxmbufmem = realmem / 2;
>>>> 127 TUNABLE_QUAD_FETCH("kern.ipc.maxmbufmem", &maxmbufmem);
>>>>
>>>> 128 if (maxmbufmem > realmem / 4 * 3)
>>>> 129 maxmbufmem = realmem / 4 * 3;
>>>>
>>>> If I am reading the code correctly, we loose the value on line 126 when
>>>> we
>>>> do FETCH on line 127.
>>>>
>>>> And after line 127, if we havent specified kern.ipc.maxmbufmem (in
>>>> loader.conf - I guess...), we set that value to 0.
>>>>
>>>> And because of that the if condition on line 128 is almost always false?
>>>>
>>>> What am I missing here?
>>>>
>>>> Thanks,
>>>> Hiren
>>>> ___
>>>> freebsd-net@freebsd.org mailing list
>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net<http://lists.freebsd.org/**mailman/listinfo/freebsd-net>
>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net>
>>>> >
>>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@**fre**
>>>> ebsd.org
>>>> <http://freebsd.org>
>>>> >
>>>>
>>>> "
>>>>
>>>> I think TUNABLE_*_FETCH will only write to the variable if it
>>>> explicitly
>>>>
>>> set.
>>>
>>> Meaning, unless the user actually sets a value in loader.conf then 127 is
>>> a no-op.
>>>
>>> Thanks Navdeep and Alfred.
>>
>> Thats correct. Its not touching the var if its not set.
>>
>> I guess the other TUNABLE_INT_FETCHs later in the function checking for
>> variable ==0 confused me. i.e. nmbclusters.
>>
>> 131 TUNABLE_INT_FETCH("kern.ipc.**nmbclusters", &nmbclusters);
>> 132 if (nmbclusters == 0)
>> 133 nmbclusters = maxmbufmem / MCLBYTES / 4;
>>
>> But those are global variable so here we are just checking if they are
>> explicitly set of not. If not, we will set them.
>>
>> For maxmbufmem, we will set it to 1/2 the realmem. and if user sets it
>> explicitly than we will make sure its not more than 3/4 of the realmem.
>>
> Yes. It's somewhat confusing.
>
> I'm all for adding comments to this effect if you have the time and
> inclination.
I guess its verbose enough in kern_mbuf.c
I just had to *actually* read getenv_quad() to know that its not setting
the variable to 0, it was just the return value.
We can probably do:
[hirenp@wholecorner ~/commit_head/sys/kern]$ svn diff
Index: kern_environment.c
===
--- kern_environment.c (revision 255320)
+++ kern_environment.c (working copy)
@@ -530,7 +530,8 @@
}
/*
- * Return a quad_t value from an environment variable.
+ * Return a quad_t value from an environment variable inside "data".
+ * If the environment variable is not set, "data" will be unchanged.
*/
int
getenv_quad(const char *name, quad_t *data)
cheers,
Hiren
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
mbuf autotuning effect
We are seeing an interesting thing on a mips board with 32MB ram.
We run out of mbuf very easily and looking at numbers it seems we are only
getting 6mb of maxmbufmem.
# sysctl -a | grep hw | grep mem
hw.physmem: 33554432
hw.usermem: 21774336
hw.realmem: 33554432
#
# sysctl -a | grep maxmbuf
kern.ipc.maxmbufmem: 6291456
I believe that number is very low for a board with 32mb of ram.
Looking at the code:
sys/kern/kern_mbuf.c : tunable_mbinit()
124 realmem = qmin((quad_t)physmem * PAGE_SIZE, vm_kmem_size);
125 maxmbufmem = realmem / 2;
126 TUNABLE_QUAD_FETCH("kern.ipc.maxmbufmem", &maxmbufmem);
127 if (maxmbufmem > realmem / 4 * 3)
128 maxmbufmem = realmem / 4 * 3;
So, realmem plays important role in determining maxmbufmem.
physmem = 32mb
PAGE_SIZE = 4096
vm_kmem_size is calculated inside sys/kern/kern_malloc.c : kmeminit()
705 vm_kmem_size = VM_KMEM_SIZE + nmbclusters * PAGE_SIZE;
706 mem_size = cnt.v_page_count;
707
708 #if defined(VM_KMEM_SIZE_SCALE)
709 vm_kmem_size_scale = VM_KMEM_SIZE_SCALE;
710 #endif
711 TUNABLE_INT_FETCH("vm.kmem_size_scale", &vm_kmem_size_scale);
712 if (vm_kmem_size_scale > 0 &&
713 (mem_size / vm_kmem_size_scale) > (vm_kmem_size /
PAGE_SIZE))
714 vm_kmem_size = (mem_size / vm_kmem_size_scale) *
PAGE_SIZE;
here,
VM_KMEM_SIZE = 12*1024*1024
nmbclusters = 0 (initially)
PAGE_SIZE = 4096
# sysctl -a | grep v_page_count
vm.stats.vm.v_page_count: 7035
and VM_KMEM_SIZE_SCALE = 3 for mips.
So, vm_kmem_size = 12mb.
Going back to tunable_mbinit(),
we get realmem = 12mb.
and masmbufmem = 6mb.
Wanted to see if I am following the code correctly and how autotuning
should work here.
cheers,
Hiren
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: mbuf autotuning effect
On Sep 6, 2013 8:26 PM, "Warner Losh" wrote:
>
>
> On Sep 6, 2013, at 7:11 PM, Adrian Chadd wrote:
>
> > Yeah, why is VM_KMEM_SIZE only 12mbyte for MIPS? That's a little low
for a
> > platform that has a direct map that's slightly larger than 12mb :)
> >
> > Warner? Juli?
>
> All architectures have it at 12MB, except sparc64 where it is 16MB. This
can be changed with the options VM_KMEM_SIZE=x in the config file.
Right. Does that mean for any platform, if we do not have nmbclusters
pre-set in kmeminit() than we will always have pretty low value of
vm_kmem_size. And because of that, if maxmbufmem is not pre-set (via
loader.conf) inside tunable_mbinit() , we will have very low value for
maxmbufmem too.
I hope (partially believe) that my understanding is not entirely correct.
Because if its correct, we arw depending on loader.conf instead of actually
auto tuning.
Thanks,
Hiren
>
> So my guess as to why this is the case: cut and paste worked, so nobody
changed it after that.
>
> # Still need to reads hiren's email to comprehend it...
>
> Warner
>
>
> >
> >
> > -adrian
> >
> >
> >
> > On 6 September 2013 16:36, hiren panchasara wrote:
> >
> >> We are seeing an interesting thing on a mips board with 32MB ram.
> >>
> >> We run out of mbuf very easily and looking at numbers it seems we are
only
> >> getting 6mb of maxmbufmem.
> >>
> >> # sysctl -a | grep hw | grep mem
> >> hw.physmem: 33554432
> >> hw.usermem: 21774336
> >> hw.realmem: 33554432
> >> #
> >> # sysctl -a | grep maxmbuf
> >> kern.ipc.maxmbufmem: 6291456
> >>
> >> I believe that number is very low for a board with 32mb of ram.
> >>
> >> Looking at the code:
> >>
> >> sys/kern/kern_mbuf.c : tunable_mbinit()
> >>
> >> 124 realmem = qmin((quad_t)physmem * PAGE_SIZE, vm_kmem_size);
> >> 125 maxmbufmem = realmem / 2;
> >> 126 TUNABLE_QUAD_FETCH("kern.ipc.maxmbufmem", &maxmbufmem);
> >> 127 if (maxmbufmem > realmem / 4 * 3)
> >> 128 maxmbufmem = realmem / 4 * 3;
> >>
> >> So, realmem plays important role in determining maxmbufmem.
> >>
> >> physmem = 32mb
> >> PAGE_SIZE = 4096
> >>
> >> vm_kmem_size is calculated inside sys/kern/kern_malloc.c : kmeminit()
> >>
> >> 705 vm_kmem_size = VM_KMEM_SIZE + nmbclusters * PAGE_SIZE;
> >> 706 mem_size = cnt.v_page_count;
> >> 707
> >> 708 #if defined(VM_KMEM_SIZE_SCALE)
> >> 709 vm_kmem_size_scale = VM_KMEM_SIZE_SCALE;
> >> 710 #endif
> >> 711 TUNABLE_INT_FETCH("vm.kmem_size_scale",
&vm_kmem_size_scale);
> >> 712 if (vm_kmem_size_scale > 0 &&
> >> 713 (mem_size / vm_kmem_size_scale) > (vm_kmem_size /
> >> PAGE_SIZE))
> >> 714 vm_kmem_size = (mem_size / vm_kmem_size_scale) *
> >> PAGE_SIZE;
> >>
> >> here,
> >> VM_KMEM_SIZE = 12*1024*1024
> >> nmbclusters = 0 (initially)
> >> PAGE_SIZE = 4096
> >> # sysctl -a | grep v_page_count
> >> vm.stats.vm.v_page_count: 7035
> >>
> >> and VM_KMEM_SIZE_SCALE = 3 for mips.
> >>
> >> So, vm_kmem_size = 12mb.
> >>
> >> Going back to tunable_mbinit(),
> >> we get realmem = 12mb.
> >> and masmbufmem = 6mb.
> >>
> >>
> >> Wanted to see if I am following the code correctly and how autotuning
> >> should work here.
> >>
> >> cheers,
> >> Hiren
> >> ___
> >> freebsd-net@freebsd.org mailing list
> >> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> >> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
> >>
> > ___
> > freebsd-m...@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-mips
> > To unsubscribe, send any mail to "freebsd-mips-unsubscr...@freebsd.org"
>
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: mbuf autotuning effect
On Sat, Sep 7, 2013 at 12:56 PM, Ian Lepore wrote: > On Sat, 2013-09-07 at 12:21 -0700, hiren panchasara wrote: > > On Sep 6, 2013 8:26 PM, "Warner Losh" wrote: > > > > > > > > > On Sep 6, 2013, at 7:11 PM, Adrian Chadd wrote: > > > > > > > Yeah, why is VM_KMEM_SIZE only 12mbyte for MIPS? That's a little > > low > > for a > > > > platform that has a direct map that's slightly larger than 12mb :) > > > > > > > > Warner? Juli? > > > > > > All architectures have it at 12MB, except sparc64 where it is 16MB. > > This > > can be changed with the options VM_KMEM_SIZE=x in the config file. > > > > Right. Does that mean for any platform, if we do not have nmbclusters > > pre-set in kmeminit() than we will always have pretty low value of > > vm_kmem_size. And because of that, if maxmbufmem is not pre-set (via > > loader.conf) inside tunable_mbinit() , we will have very low value for > > maxmbufmem too. > > > > I hope (partially believe) that my understanding is not entirely > > correct. > > Because if its correct, we arw depending on loader.conf instead of > > actually > > auto tuning. > > > I think the part of this that strikes me as strange is calling 20% of > physical memory used for network buffers a "very low value". It seems > outrageously high to me. I'd be pissed if that much memory got wasted > on network buffers on one of our $work platforms with so little memory. > Interesting. So here how it looks on my laptop running amd64 GENERIC looks like: (without any special loader.conf settings) flymockour-l7% uname -a FreeBSD flymockour-l7.corp.yahoo.com 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r253512M: Sat Jul 20 23:00:51 PDT 2013 hir...@flymockour-l7.corp.yahoo.com:/usr/obj/usr/home/hirenp/head/sys/GENERIC amd64 flymockour-l7% sysctl -a | grep hw| grep mem hw.physmem: 8496877568 hw.usermem: 3538432000 hw.realmem: 9093251072 flymockour-l7% sysctl kern.ipc.maxmbufmem kern.ipc.maxmbufmem: 4132540416 flymockour-l7% sysctl -a | grep vm.kmem_ vm.kmem_size: 8265080832 vm.kmem_size_min: 0 vm.kmem_size_max: 329853485875 vm.kmem_size_scale: 1 vm.kmem_map_size: 1380515840 vm.kmem_map_free: 5796265984 VM_KMEM_SIZE_SCALE is 1 for amd64 while 3 for mips. Which might be one reason. > So the fact that you think it's crazy-low and I think it's crazy-high > may be a sign that it's auto-tuned to a reasonable compromise, and in > both our cases the right fix would be to use the available knobs to tune > things for our particular uses. > I am pretty ignorant on what the value _should_ be. I will try to find out more. cheers, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: mbuf autotuning effect
On Sat, Sep 7, 2013 at 1:39 PM, Adrian Chadd wrote: > On 7 September 2013 12:56, Ian Lepore wrote: > > >> I think the part of this that strikes me as strange is calling 20% of >> physical memory used for network buffers a "very low value". It seems >> outrageously high to me. I'd be pissed if that much memory got wasted >> on network buffers on one of our $work platforms with so little memory. >> >> So the fact that you think it's crazy-low and I think it's crazy-high >> may be a sign that it's auto-tuned to a reasonable compromise, and in >> both our cases the right fix would be to use the available knobs to tune >> things for our particular uses. >> > > Well, which limit is actually being hit here? 20% of 32mb is still a lot > of memory buffers.. > > Now, for sizing up the needed buffers for wifi: > > assuming 512 tx, 512 rx buffers for two ath NICs. > > another 512+512 buffers for each arge NICs. > > So, 4096 mbufs here, 2k each, so ~ 8mb of RAM. > And we are only getting 6mb of maxmbufmem with current setup. Index: mips/include/vmparam.h === --- mips/include/vmparam.h (revision 255320) +++ mips/include/vmparam.h (working copy) @@ -119,7 +119,7 @@ * is the total KVA space allocated for kmem_map. */ #ifndef VM_KMEM_SIZE_SCALE -#defineVM_KMEM_SIZE_SCALE (3) +#defineVM_KMEM_SIZE_SCALE (1) #endif /* As I mentioned on another reply in the same thread, VM_KMEM_SIZE_SCALE is 1 for amd64. If I do the same for mips as above, we get # sysctl -a | grep maxmbuf kern.ipc.maxmbufmem: 14407680 Now, do we want to have this much rams assigned to mbufs is another question. cheers, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Exposing sysctls for ixgbe
$ sysctl hw.igb hw.igb.rxd: 4096 hw.igb.txd: 4096 hw.igb.enable_aim: 1 hw.igb.enable_msix: 1 hw.igb.max_interrupt_rate: 8000 hw.igb.buf_ring_size: 4096 hw.igb.header_split: 0 hw.igb.num_queues: 1 hw.igb.rx_process_limit: 100 $ sysctl hw.ix sysctl: unknown oid 'hw.ix': No such file or directory I thought it would be nice to have these things exposed. So I copied them from igb: http://people.freebsd.org/~hiren/ixgbe_sysctls.txt Changes for if_igb.c is to expose correct auto-tuned value for a running system for "hw.igb.num_queues", which is not the case right now. Thanks to markj@ for help/pointers. Please let me know if the diffs look okay. cheers, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
netmap: understanding pkg-gen.c
I am new to netmap so thought of confirming my understanding.
I was trying to associate ixgbe interface with netmap and blast pkts to it
using tools/tools/netmap/pkg-gen.c
My setup looks like this:
FreeBSD 10.0-ALPHA1 #2: Sun Sep 22 18:08:18 UTC 2013
-bash-4.2$ sysctl hw.physmem
hw.physmem: 51505954816
-bash-4.2$ sysctl hw.ncpu
hw.ncpu: 24
-bash-4.2$ sysctl hw.ix
hw.ix.enable_aim: 1
hw.ix.max_interrupt_rate: 31250
hw.ix.rx_process_limit: 256
hw.ix.tx_process_limit: 256
hw.ix.enable_msix: 1
hw.ix.num_queues: 8
hw.ix.txd: 2048
hw.ix.rxd: 2048
-bash-4.2$
On this box, I have 2 interfaces igb0 (10.73.149.28) and ix1 (10.73.149.17)
and this is how I am using this binary:
-bash-4.2$ sudo ./pkt-gen -i ix1 -f tx -n 1 -c 8 -p 8 -d
10.73.149.17 -s 10.73.149.28
extract_ip_range [143] extract IP range from 10.73.149.28
extract_ip_range [178] range is 10.73.149.28 0 to 10.73.149.28 0
extract_ip_range [143] extract IP range from 10.73.149.17
extract_ip_range [178] range is 10.73.149.17 0 to 10.73.149.17 0
extract_mac_range [184] extract MAC range from 90:e2:ba:30:68:c5
extract_mac_range [199] 90:e2:ba:30:68:c5 starts at 90:e2:ba:30:68:c5
extract_mac_range [184] extract MAC range from ff:ff:ff:ff:ff:ff
extract_mac_range [199] ff:ff:ff:ff:ff:ff starts at ff:ff:ff:ff:ff:ff
main [1530] map size is 334980 Kb
main [1552] mapping 334980 Kbytes
Sending on ix1: 8 queues, 8 threads and 8 cpus.
10.73.149.28 -> 10.73.149.17 (90:e2:ba:30:68:c5 -> ff:ff:ff:ff:ff:ff)
main [1622] Sending 512 packets every 0.0 ns
main [1624] Wait 2 secs for phy reset
main [1626] Ready...
sender_body [775] start
sender_body [775] start
sender_body [775] start
sender_body [775] start
sender_body [775] start
sender_body [775] start
sender_body [775] start
sender_body [775] start
sender_body [848] drop copy
sender_body [848] drop copy
sender_body [848] drop copy
sender_body [848] drop copy
sender_body [848] drop copy
sender_body [848] drop copy
sender_body [848] drop copy
sender_body [848] drop copy
main_thread [1192] 15024157 pps (15050104 pkts in 1001727 usec)
main_thread [1192] 14882290 pps (14900223 pkts in 1001205 usec)
main_thread [1192] 14879515 pps (14903798 pkts in 1001632 usec)
main_thread [1192] 14880924 pps (15795952 pkts in 1061490 usec)
main_thread [1192] 14881411 pps (15821633 pkts in 1063181 usec)
main_thread [1192] 14880095 pps (15427549 pkts in 1036791 usec)
main_thread [1192] 7986707 pps (8100741 pkts in 1014278 usec)
Sent 1 packets, 60 bytes each, in 6.71 seconds.
Speed: 14.90 Mpps Bandwidth: 7.15 Gbps (raw 10.01 Gbps)
$ top -H shows:
25853 root 240 348M 35692K select 16 0:01 7.28%
pkt-gen{pkt-gen}
25853 root 250 348M 35692K select 21 0:01 7.28%
pkt-gen{pkt-gen}
25853 root 250 348M 35692K select 15 0:01 7.28%
pkt-gen{pkt-gen}
25853 root 230 348M 35692K select 12 0:01 6.40%
pkt-gen{pkt-gen}
25853 root 240 348M 35692K select 22 0:01 6.30%
pkt-gen{pkt-gen}
25853 root 230 348M 35692K select 9 0:01 5.66%
pkt-gen{pkt-gen}
25853 root 230 348M 35692K select 7 0:01 5.57%
pkt-gen{pkt-gen}
25853 root 230 348M 35692K CPU00 0:01 5.27%
pkt-gen{pkt-gen}
12 root -92- 0K 1184K WAIT6 0:10 5.08% intr{irq290:
ix1:que }
12 root -92- 0K 1184K WAIT7 0:09 4.98% intr{irq291:
ix1:que }
12 root -92- 0K 1184K WAIT5 0:08 4.79% intr{irq289:
ix1:que }
12 root -92- 0K 1184K WAIT2 0:15 4.69% intr{irq286:
ix1:que }
12 root -92- 0K 1184K WAIT3 0:08 4.69% intr{irq287:
ix1:que }
12 root -92- 0K 1184K WAIT4 0:14 4.59% intr{irq288:
ix1:que }
12 root -92- 0K 1184K WAIT1 0:06 3.96% intr{irq285:
ix1:que }
12 root -92- 0K 1184K WAIT0 0:05 0.98% intr{irq284:
ix1:que }
I can only specify -p (threads) upto 8 because it cannot be more than the
hw.ix.num_queues=8, is that correct?
Cheers,
Hiren
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Exposing sysctls for ixgbe
Any comments? cheers, Hiren On Sun, Sep 22, 2013 at 12:01 PM, hiren panchasara wrote: > $ sysctl hw.igb > hw.igb.rxd: 4096 > hw.igb.txd: 4096 > hw.igb.enable_aim: 1 > hw.igb.enable_msix: 1 > hw.igb.max_interrupt_rate: 8000 > hw.igb.buf_ring_size: 4096 > hw.igb.header_split: 0 > hw.igb.num_queues: 1 > hw.igb.rx_process_limit: 100 > $ sysctl hw.ix > sysctl: unknown oid 'hw.ix': No such file or directory > > I thought it would be nice to have these things exposed. So I copied them > from igb: > http://people.freebsd.org/~hiren/ixgbe_sysctls.txt > > Changes for if_igb.c is to expose correct auto-tuned value for a running > system for "hw.igb.num_queues", which is not the case right now. > > Thanks to markj@ for help/pointers. > > Please let me know if the diffs look okay. > > cheers, > Hiren > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
netmap: traffic distribution
I am providing line rate traffic (via pkg-gen.c) to my 10gig ix interface. Now on receiving side, is there a way to sub-divide the traffic into multiple workloads using netmap? For example, can I get two 5G flows from 10Gbps traffic? cheers, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: netmap: traffic distribution
On Wed, Sep 25, 2013 at 1:22 AM, Luigi Rizzo wrote: > On Wed, Sep 25, 2013 at 10:07 AM, hiren panchasara > wrote: > > > > I am providing line rate traffic (via pkg-gen.c) to my 10gig ix > interface. > > > > Now on receiving side, is there a way to sub-divide the traffic into > > multiple workloads using netmap? > > > > For example, can I get two 5G flows from 10Gbps traffic? > > not directly. You'd need to send packets with different addresses that > match > the way the filters on the NIC (RSS or similar) are programmed. > Thanks for quick responses, Liugi. So, FreeBSD needs PF_RING like thing? Any other way we can do it? Someone pointed me to multiqueue bpf too. Not sure if I can use that to achieve what I am looking for. cheers, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: netmap: traffic distribution
On Wed, Sep 25, 2013 at 2:05 AM, Luigi Rizzo wrote: > On Wed, Sep 25, 2013 at 10:53 AM, hiren panchasara > wrote: > > > > > > > > On Wed, Sep 25, 2013 at 1:22 AM, Luigi Rizzo wrote: > >> > >> On Wed, Sep 25, 2013 at 10:07 AM, hiren panchasara > >> wrote: > >> > > >> > I am providing line rate traffic (via pkg-gen.c) to my 10gig ix > >> > interface. > >> > > >> > Now on receiving side, is there a way to sub-divide the traffic into > >> > multiple workloads using netmap? > >> > > >> > For example, can I get two 5G flows from 10Gbps traffic? > >> > >> not directly. You'd need to send packets with different addresses that > >> match > >> the way the filters on the NIC (RSS or similar) are programmed. > > > > > > Thanks for quick responses, Liugi. > > > > So, FreeBSD needs PF_RING like thing? Any other way we can do it? > > no, > PF_RING does nothing more than netmap. > Okay. > > the partitioning of traffic into queues is done by the NIC's hardware, > through some filters that i mentioned and are NIC specific. > They are often named RSS (receive side scaling), RFS (receive flow > steering), > Flow Director, and so on. Some NICs compute a hash of various header > fields > and use the result to direct packets to specific queues. Others have > "exact match" filters where you can map certain mac headers to > specific queues, and so on. > Alright. I will investigate more about RSS/RFS for ixgbe. Thanks a bunch, Hiren > > A software demultiplexer that sits on top of a netmap ring > may certainly be useful, but i have not yet designed it. > > > cheers > luigi > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: netmap: traffic distribution
On Thu, Sep 26, 2013 at 12:58 AM, Michio Honda wrote: > Hi, > > The handiest way to try flexible flow distribution is using Flow Director. > I've confirmed that the patch posted to this list two years ago works with > netmap/ixgbe. > > http://freebsd.1045724.n5.nabble.com/Adding-Flow-Director-sysctls-to-ixgbe-4-td4769489.html > Thanks a lot for the link, Michio! It seems this work is yet not committed?!? cheers, Hiren > > Cheers, > - Michio > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: netmap: traffic distribution
On Thu, Sep 26, 2013 at 2:27 PM, chintu hetam wrote: > Hiren, > > https://www.kernel.org/doc/Documentation/networking/scaling.txt must read > to understand nuances of each of this features. None of this techniques are > used for mostly none other than performance reasons. > Thanks for the link. So, RFS (Receive Flow Steering) is equivalent to "flow director" mentioned in FreeBSD's ixgbe drivers? > > Michio, personally i am interested to know performance results in netmap > mode with RFS patch you just mentioned. > Takuya/Luigi might have some numbers. Thanks, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Adding Flow Director sysctls to ixgbe(4) (was: netmap: traffic distribution)
On Thu, Sep 26, 2013 at 10:38 AM, hiren panchasara < hiren.panchas...@gmail.com> wrote: > > > > On Thu, Sep 26, 2013 at 12:58 AM, Michio Honda wrote: > >> Hi, >> >> The handiest way to try flexible flow distribution is using Flow Director. >> I've confirmed that the patch posted to this list two years ago works >> with netmap/ixgbe. >> >> http://freebsd.1045724.n5.nabble.com/Adding-Flow-Director-sysctls-to-ixgbe-4-td4769489.html >> > > Thanks a lot for the link, Michio! > > It seems this work is yet not committed?!? > Takuya, I see a lot of responses/comments on proposed changes. Was anything decided at the end of it? As far as I can tell, its still not committed to the tree. Thanks, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: netmap: traffic distribution
I think you meant "reply-all" :-) On Fri, Sep 27, 2013 at 7:53 AM, chintu hetam wrote: > As far as i know, flow director is Intel terminology it addresses both RSS > and RFS. I think FreeBSD implementation is RFS. > > Luigi, you touched upon SW de-multiplexer, i would like to know why it's > necessary. > let say i have 82599 ixgbe driver (RSS enabled)configured with 5 tuple > hash. My application reads from netmap queue 0-7(1-8), i know for sure that > each hash will be filtered to specific hw queue(0-7), is it safe to assume > netmap will provide packets in same order. > > Michio, reason i asked for performance values > http://arxiv.org/ftp/arxiv/papers/1106/1106.0443.pdf > I would like to test the accuracy of RFS,RSS and others in netmap mode.. > > Thanks > Hardik > > > On Fri, Sep 27, 2013 at 2:59 AM, hiren panchasara < > hiren.panchas...@gmail.com> wrote: > >> >> >> >> On Thu, Sep 26, 2013 at 2:27 PM, chintu hetam wrote: >> >>> Hiren, >>> >>> https://www.kernel.org/doc/Documentation/networking/scaling.txt must >>> read to understand nuances of each of this features. None of this >>> techniques are used for mostly none other than performance reasons. >>> >> >> Thanks for the link. >> So, RFS (Receive Flow Steering) is equivalent to "flow director" >> mentioned in FreeBSD's ixgbe drivers? >> >>> >>> Michio, personally i am interested to know performance results in netmap >>> mode with RFS patch you just mentioned. >>> >> Takuya/Luigi might have some numbers. >> >> Thanks, >> Hiren >> >> >> >> > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Adding Flow Director sysctls to ixgbe(4) (was: netmap: traffic distribution)
On Fri, Sep 27, 2013 at 1:58 AM, Takuya ASADA wrote: > 2013/9/27 Adrian Chadd > >> On 27 September 2013 00:43, hiren panchasara >> wrote: >> >> >>> Takuya, >>> >>> I see a lot of responses/comments on proposed changes. Was anything >>> decided >>> at the end of it? As far as I can tell, its still not committed to the >>> tree. >>> >> >> I'd rather see an ioctl API for that chipset and then have a separate >> tool program it for now. >> > > Ah, like cxgbetool and cxgbe? (it has device specific tool and ioctls) > http://svnweb.freebsd.org/base/head/tools/tools/cxgbetool/ > Something like this for ixgbe would be nice to start with, imo. Cheers, Hiren > http://svnweb.freebsd.org/base/head/sys/dev/cxgb/ > > >> So, how bout we hack that up? :) >> > > Sound's interesting ;-) > Could you tell me more detail about your idea? > > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Adding Flow Director sysctls to ixgbe(4) (was: netmap: traffic distribution)
On Sep 30, 2013 5:08 AM, "Takuya ASADA" wrote: > > Hi, > > This is updated version of the patch. I will give this a try today. Cheers Hiren > Signature filter list feature is added. > > Here're usage of ixgbetool: > - add a filter > ixgbetool ix0 add_sig_filter tcpv4 10.1.0.1 34763 10.1.0.2 22 3 > - show filters > ixgbetool ix0 show_sig_filter > - del a filter > ixgbetool ix0 del_sig_filter 1 > > > > 2013/9/30 Takuya ASADA >> >> Hi, >> >> I just implemented device specific ioctl with device specific configuration tool. >> It still doesn't support some important features such as: >> - FDIR enable / disable via sysctl or tunable params >> - ATR enable / disable via sysctl or tunable params >> - IPv6 support on signature filter >> - signature filter list >> - support perfect filter >> But, at least it can configure signature filter manually. >> >> Usage is as follows: >> Usage: ixgbetool [operation] >> add_sig_filter >> del_sig_filter >> >> >> 2013/9/28 hiren panchasara >>> >>> >>> >>> >>> On Fri, Sep 27, 2013 at 1:58 AM, Takuya ASADA wrote: >>>> >>>> 2013/9/27 Adrian Chadd >>>>> >>>>> On 27 September 2013 00:43, hiren panchasara < hiren.panchas...@gmail.com> wrote: >>>>> >>>>>> >>>>>> Takuya, >>>>>> >>>>>> I see a lot of responses/comments on proposed changes. Was anything decided >>>>>> at the end of it? As far as I can tell, its still not committed to the >>>>>> tree. >>>>> >>>>> >>>>> I'd rather see an ioctl API for that chipset and then have a separate tool program it for now. >>>> >>>> >>>> Ah, like cxgbetool and cxgbe? (it has device specific tool and ioctls) >>>> http://svnweb.freebsd.org/base/head/tools/tools/cxgbetool/ >>> >>> >>> Something like this for ixgbe would be nice to start with, imo. >>> >>> Cheers, >>> Hiren >>>> >>>> http://svnweb.freebsd.org/base/head/sys/dev/cxgb/ >>>> >>>>> >>>>> So, how bout we hack that up? :) >>>> >>>> >>>> Sound's interesting ;-) >>>> Could you tell me more detail about your idea? >>>> >>> >> > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Exposing sysctls for ixgbe
+ jfv On Wed, Sep 25, 2013 at 5:35 PM, Adrian Chadd wrote: > please cc jfv and get them into his driver. :) > > -a > > > On 24 September 2013 23:53, hiren panchasara wrote: > >> Any comments? >> >> cheers, >> Hiren >> >> On Sun, Sep 22, 2013 at 12:01 PM, hiren panchasara > >wrote: >> >> > $ sysctl hw.igb >> > hw.igb.rxd: 4096 >> > hw.igb.txd: 4096 >> > hw.igb.enable_aim: 1 >> > hw.igb.enable_msix: 1 >> > hw.igb.max_interrupt_rate: 8000 >> > hw.igb.buf_ring_size: 4096 >> > hw.igb.header_split: 0 >> > hw.igb.num_queues: 1 >> > hw.igb.rx_process_limit: 100 >> > $ sysctl hw.ix >> > sysctl: unknown oid 'hw.ix': No such file or directory >> > >> > I thought it would be nice to have these things exposed. So I copied >> them >> > from igb: >> > http://people.freebsd.org/~hiren/ixgbe_sysctls.txt >> > >> > Changes for if_igb.c is to expose correct auto-tuned value for a running >> > system for "hw.igb.num_queues", which is not the case right now. >> > >> > Thanks to markj@ for help/pointers. >> > >> > Please let me know if the diffs look okay. >> > >> > cheers, >> > Hiren >> > >> ___ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" >> > > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Flow Director statistics for ixgbe(4)
On Mon, Sep 30, 2013 at 12:02 PM, Takuya ASADA wrote: > Hi, > > This is originally part of "ixgbetool" patch, but I think it can be discuss > separately: > > http://freebsd.1045724.n5.nabble.com/Adding-Flow-Director-sysctls-to-ixgbe-4-was-netmap-traffic-distribution-tp5847066p5847789.html > > I implemented sysctls to expose Flow Director statistics. > It works like this: > $ sysctl dev.ix.0.mac_stats|grep fdir > dev.ix.0.mac_stats.fdirfree_free: 8192 > dev.ix.0.mac_stats.fdirfree_coll: 0 > dev.ix.0.mac_stats.fdirustat_add: 0 > dev.ix.0.mac_stats.fdirustat_remove: 0 > dev.ix.0.mac_stats.fdirfstat_fadd: 0 > dev.ix.0.mac_stats.fdirfstat_fremove: 0 > dev.ix.0.mac_stats.fdirmatch: 0 > dev.ix.0.mac_stats.fdirmiss: 23 > I am running this with the ixgbetool patch you have and only 1 issue I've seen so far: fdirustat_add increments on adding a filter but fdirustat_remove does not on deleting one (if thats how its supposed to work) Can you please populate "description" for all the sysctls you are adding? :-) Cheers, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Flow Director statistics for ixgbe(4)
On Mon, Sep 30, 2013 at 1:48 PM, Takuya ASADA wrote: > Hi, > > descriptions are added. > Great. My minor suggestions (you can ignore them :-)) from "Number of filters addition events that do not change the number of free" to "Number of failed filter addition events" (I believe, "do not change the number of free" part is given when addition is failing) from "Number of packets that missed matched any flow director filter" to "Number of packets that didn't match any flow director filter" > > 2013/10/1 hiren panchasara > >> >> >> >> On Mon, Sep 30, 2013 at 12:02 PM, Takuya ASADA wrote: >> >>> Hi, >>> >>> This is originally part of "ixgbetool" patch, but I think it can be >>> discuss >>> separately: >>> >>> http://freebsd.1045724.n5.nabble.com/Adding-Flow-Director-sysctls-to-ixgbe-4-was-netmap-traffic-distribution-tp5847066p5847789.html >>> >>> I implemented sysctls to expose Flow Director statistics. >>> It works like this: >>> $ sysctl dev.ix.0.mac_stats|grep fdir >>> dev.ix.0.mac_stats.fdirfree_free: 8192 >>> dev.ix.0.mac_stats.fdirfree_coll: 0 >>> dev.ix.0.mac_stats.fdirustat_add: 0 >>> dev.ix.0.mac_stats.fdirustat_remove: 0 >>> dev.ix.0.mac_stats.fdirfstat_fadd: 0 >>> dev.ix.0.mac_stats.fdirfstat_fremove: 0 >>> dev.ix.0.mac_stats.fdirmatch: 0 >>> dev.ix.0.mac_stats.fdirmiss: 23 >>> >> >> I am running this with the ixgbetool patch you have and only 1 issue I've >> seen so far: fdirustat_add increments on adding a filter but >> fdirustat_remove does not on deleting one (if thats how its supposed to >> work) >> > As we talked on another thread, yes, problem is just the counter not getting updated. The functionality is fine. Appreciate your awesome work. Cheers, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: netmap: understanding pkg-gen.c
Thanks Luigi. Coming back to this thread to actually understand what's going on. On Tue, Sep 24, 2013 at 8:37 PM, Luigi Rizzo wrote: > > > > On this box, I have 2 interfaces igb0 (10.73.149.28) and ix1 > (10.73.149.17) > > and this is how I am using this binary: > > > > -bash-4.2$ sudo ./pkt-gen -i ix1 -f tx -n 1 -c 8 -p 8 -d > > 10.73.149.17 -s 10.73.149.28 > So, my intention is to *send* 10gbps data to ix1 and see the card use all of its 8 queues. Above command is the correct one? I kldunloaded/loaded ixbge to clear out all the stats and tested it again: -bash-4.2$ sudo ./pkt-gen -i ix1 -f tx -n 1 -c 8 -p 8 -d 10.73.149.17 -s 10.73.149.28 extract_ip_range [143] extract IP range from 10.73.149.28 extract_ip_range [178] range is 10.73.149.28 0 to 10.73.149.28 0 extract_ip_range [143] extract IP range from 10.73.149.17 extract_ip_range [178] range is 10.73.149.17 0 to 10.73.149.17 0 extract_mac_range [184] extract MAC range from 90:e2:ba:30:68:c5 extract_mac_range [199] 90:e2:ba:30:68:c5 starts at 90:e2:ba:30:68:c5 extract_mac_range [184] extract MAC range from ff:ff:ff:ff:ff:ff extract_mac_range [199] ff:ff:ff:ff:ff:ff starts at ff:ff:ff:ff:ff:ff main [1530] map size is 334980 Kb main [1552] mapping 334980 Kbytes Sending on ix1: 8 queues, 8 threads and 8 cpus. 10.73.149.28 -> 10.73.149.17 (90:e2:ba:30:68:c5 -> ff:ff:ff:ff:ff:ff) main [1622] Sending 512 packets every 0.0 ns main [1624] Wait 2 secs for phy reset main [1626] Ready... sender_body [775] start sender_body [775] start sender_body [775] start sender_body [775] start sender_body [775] start sender_body [775] start sender_body [775] start sender_body [848] drop copy sender_body [775] start sender_body [848] drop copy sender_body [848] drop copy sender_body [848] drop copy sender_body [848] drop copy sender_body [848] drop copy sender_body [848] drop copy main_thread [1192] 15122963 pps (15130434 pkts in 1000494 usec) main_thread [1192] 14881444 pps (14896266 pkts in 1000996 usec) sender_body [841] poll error/timeout on queue 1 main_thread [1192] 14880708 pps (15659371 pkts in 1052327 usec) main_thread [1192] 14878611 pps (14888684 pkts in 1000677 usec) main_thread [1192] 14882655 pps (14897538 pkts in 1001000 usec) main_thread [1192] 11900044 pps (12029754 pkts in 1010900 usec) main_thread [1212] ouch, thread 1 exited with error Sent 87502047 packets, 60 bytes each, in 5.86 seconds. Speed: 14.92 Mpps Bandwidth: 7.16 Gbps (raw 10.03 Gbps) -bash-4.2$ But looking at the queue stats: -bash-4.2$ sysctl -a | grep ix.1 | grep queue | grep rx_packets dev.ix.1.queue0.rx_packets: 171 dev.ix.1.queue1.rx_packets: 0 dev.ix.1.queue2.rx_packets: 0 dev.ix.1.queue3.rx_packets: 0 dev.ix.1.queue4.rx_packets: 0 dev.ix.1.queue5.rx_packets: 0 dev.ix.1.queue6.rx_packets: 0 dev.ix.1.queue7.rx_packets: 0 And after a few seconds: -bash-4.2$ sysctl -a | grep ix.1 | grep queue | grep rx_packets dev.ix.1.queue0.rx_packets: 310 dev.ix.1.queue1.rx_packets: 0 dev.ix.1.queue2.rx_packets: 0 dev.ix.1.queue3.rx_packets: 0 dev.ix.1.queue4.rx_packets: 8 dev.ix.1.queue5.rx_packets: 0 dev.ix.1.queue6.rx_packets: 0 dev.ix.1.queue7.rx_packets: 0 -bash-4.2$ What is going on here? Should I be seeing more pkts in rx_packets? Should I see more queues being used? I am using stock ixgbe at this point. I believe RSS is enabled by default? I apologize if I am asking obvious/answered questions here. cheers, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: netmap: understanding pkg-gen.c
On Wed, Oct 2, 2013 at 1:18 PM, hiren panchasara wrote:
>
> Thanks Luigi.
>
> Coming back to this thread to actually understand what's going on.
>
>
> On Tue, Sep 24, 2013 at 8:37 PM, Luigi Rizzo wrote:
>
>> >
>> > On this box, I have 2 interfaces igb0 (10.73.149.28) and ix1
>> (10.73.149.17)
>> > and this is how I am using this binary:
>> >
>> > -bash-4.2$ sudo ./pkt-gen -i ix1 -f tx -n 1 -c 8 -p 8 -d
>> > 10.73.149.17 -s 10.73.149.28
>>
>
> So, my intention is to *send* 10gbps data to ix1 and see the card use all
> of its 8 queues.
>
> Above command is the correct one?
>
> I kldunloaded/loaded ixbge to clear out all the stats and tested it again:
>
>
> -bash-4.2$ sudo ./pkt-gen -i ix1 -f tx -n 1 -c 8 -p 8 -d
> 10.73.149.17 -s 10.73.149.28
> extract_ip_range [143] extract IP range from 10.73.149.28
> extract_ip_range [178] range is 10.73.149.28 0 to 10.73.149.28 0
> extract_ip_range [143] extract IP range from 10.73.149.17
> extract_ip_range [178] range is 10.73.149.17 0 to 10.73.149.17 0
> extract_mac_range [184] extract MAC range from 90:e2:ba:30:68:c5
> extract_mac_range [199] 90:e2:ba:30:68:c5 starts at 90:e2:ba:30:68:c5
> extract_mac_range [184] extract MAC range from ff:ff:ff:ff:ff:ff
> extract_mac_range [199] ff:ff:ff:ff:ff:ff starts at ff:ff:ff:ff:ff:ff
> main [1530] map size is 334980 Kb
> main [1552] mapping 334980 Kbytes
> Sending on ix1: 8 queues, 8 threads and 8 cpus.
> 10.73.149.28 -> 10.73.149.17 (90:e2:ba:30:68:c5 -> ff:ff:ff:ff:ff:ff)
> main [1622] Sending 512 packets every 0.0 ns
> main [1624] Wait 2 secs for phy reset
> main [1626] Ready...
> sender_body [775] start
> sender_body [775] start
> sender_body [775] start
> sender_body [775] start
> sender_body [775] start
> sender_body [775] start
> sender_body [775] start
> sender_body [848] drop copy
>
> sender_body [775] start
> sender_body [848] drop copy
> sender_body [848] drop copy
> sender_body [848] drop copy
> sender_body [848] drop copy
> sender_body [848] drop copy
> sender_body [848] drop copy
> main_thread [1192] 15122963 pps (15130434 pkts in 1000494 usec)
> main_thread [1192] 14881444 pps (14896266 pkts in 1000996 usec)
> sender_body [841] poll error/timeout on queue 1
> main_thread [1192] 14880708 pps (15659371 pkts in 1052327 usec)
> main_thread [1192] 14878611 pps (14888684 pkts in 1000677 usec)
> main_thread [1192] 14882655 pps (14897538 pkts in 1001000 usec)
> main_thread [1192] 11900044 pps (12029754 pkts in 1010900 usec)
> main_thread [1212] ouch, thread 1 exited with error
> Sent 87502047 packets, 60 bytes each, in 5.86 seconds.
> Speed: 14.92 Mpps Bandwidth: 7.16 Gbps (raw 10.03 Gbps)
> -bash-4.2$
>
> But looking at the queue stats:
>
>
> -bash-4.2$ sysctl -a | grep ix.1 | grep queue | grep rx_packets
> dev.ix.1.queue0.rx_packets: 171
> dev.ix.1.queue1.rx_packets: 0
> dev.ix.1.queue2.rx_packets: 0
> dev.ix.1.queue3.rx_packets: 0
> dev.ix.1.queue4.rx_packets: 0
> dev.ix.1.queue5.rx_packets: 0
> dev.ix.1.queue6.rx_packets: 0
> dev.ix.1.queue7.rx_packets: 0
>
> And after a few seconds:
>
> -bash-4.2$ sysctl -a | grep ix.1 | grep queue | grep rx_packets
> dev.ix.1.queue0.rx_packets: 310
> dev.ix.1.queue1.rx_packets: 0
> dev.ix.1.queue2.rx_packets: 0
> dev.ix.1.queue3.rx_packets: 0
> dev.ix.1.queue4.rx_packets: 8
> dev.ix.1.queue5.rx_packets: 0
> dev.ix.1.queue6.rx_packets: 0
> dev.ix.1.queue7.rx_packets: 0
> -bash-4.2$
>
> What is going on here? Should I be seeing more pkts in rx_packets? Should
> I see more queues being used?
>
> I am using stock ixgbe at this point. I believe RSS is enabled by default?
>
fdir(flow director)/atr is also enabled by default.
I tried to turn that off by following change in /sys/modules/ixgbe/Makefile
-CFLAGS+= -I${.CURDIR}/../../dev/ixgbe -DSMP -DIXGBE_FDIR
+CFLAGS+= -I${.CURDIR}/../../dev/ixgbe -DSMP
But, now interface would not attach to netmap:
sudo ./pkt-gen -i ix1 -f tx -n 1 -c 8 -p 8 -d 10.73.149.17 -s
10.73.149.28
extract_ip_range [143] extract IP range from 10.73.149.28
extract_ip_range [178] range is 10.73.149.28 0 to 10.73.149.28 0
extract_ip_range [143] extract IP range from 10.73.149.17
extract_ip_range [178] range is 10.73.149.17 0 to 10.73.149.17 0
extract_mac_range [184] extract MAC range from 90:e2:ba:30:68:c5
extract_mac_range [199] 90:e2:ba:30:68:c5 starts at 90:e2:ba:30:68:c5
extract_mac_range [184] extract MAC range from ff:ff:ff:ff:ff:ff
extract_mac_range [199] ff:ff:ff:ff:ff:ff starts at ff:ff:ff:ff:ff:ff
main [1530] map size is 334980 Kb
main [1536] Unable to get if info for ix1
main [1543] bad nthreads 8, have 0 queues
main [1552] mapping 0 Kbytes
main [1558] Unable to mmap
Re: netmap: understanding pkg-gen.c
On Wed, Oct 2, 2013 at 3:11 PM, hiren panchasara wrote:
>
>
>
> On Wed, Oct 2, 2013 at 1:18 PM, hiren panchasara <
> hiren.panchas...@gmail.com> wrote:
>
>>
>> Thanks Luigi.
>>
>> Coming back to this thread to actually understand what's going on.
>>
>>
>> On Tue, Sep 24, 2013 at 8:37 PM, Luigi Rizzo wrote:
>>
>>> >
>>> > On this box, I have 2 interfaces igb0 (10.73.149.28) and ix1
>>> (10.73.149.17)
>>> > and this is how I am using this binary:
>>> >
>>> > -bash-4.2$ sudo ./pkt-gen -i ix1 -f tx -n 1 -c 8 -p 8 -d
>>> > 10.73.149.17 -s 10.73.149.28
>>>
>>
>> So, my intention is to *send* 10gbps data to ix1 and see the card use all
>> of its 8 queues.
>>
>> Above command is the correct one?
>>
>> I kldunloaded/loaded ixbge to clear out all the stats and tested it again:
>>
>>
>> -bash-4.2$ sudo ./pkt-gen -i ix1 -f tx -n 1 -c 8 -p 8 -d
>> 10.73.149.17 -s 10.73.149.28
>> extract_ip_range [143] extract IP range from 10.73.149.28
>> extract_ip_range [178] range is 10.73.149.28 0 to 10.73.149.28 0
>> extract_ip_range [143] extract IP range from 10.73.149.17
>> extract_ip_range [178] range is 10.73.149.17 0 to 10.73.149.17 0
>> extract_mac_range [184] extract MAC range from 90:e2:ba:30:68:c5
>> extract_mac_range [199] 90:e2:ba:30:68:c5 starts at 90:e2:ba:30:68:c5
>> extract_mac_range [184] extract MAC range from ff:ff:ff:ff:ff:ff
>> extract_mac_range [199] ff:ff:ff:ff:ff:ff starts at ff:ff:ff:ff:ff:ff
>> main [1530] map size is 334980 Kb
>> main [1552] mapping 334980 Kbytes
>> Sending on ix1: 8 queues, 8 threads and 8 cpus.
>> 10.73.149.28 -> 10.73.149.17 (90:e2:ba:30:68:c5 -> ff:ff:ff:ff:ff:ff)
>> main [1622] Sending 512 packets every 0.0 ns
>> main [1624] Wait 2 secs for phy reset
>> main [1626] Ready...
>> sender_body [775] start
>> sender_body [775] start
>> sender_body [775] start
>> sender_body [775] start
>> sender_body [775] start
>> sender_body [775] start
>> sender_body [775] start
>> sender_body [848] drop copy
>>
>> sender_body [775] start
>> sender_body [848] drop copy
>> sender_body [848] drop copy
>> sender_body [848] drop copy
>> sender_body [848] drop copy
>> sender_body [848] drop copy
>> sender_body [848] drop copy
>> main_thread [1192] 15122963 pps (15130434 pkts in 1000494 usec)
>> main_thread [1192] 14881444 pps (14896266 pkts in 1000996 usec)
>> sender_body [841] poll error/timeout on queue 1
>> main_thread [1192] 14880708 pps (15659371 pkts in 1052327 usec)
>> main_thread [1192] 14878611 pps (14888684 pkts in 1000677 usec)
>> main_thread [1192] 14882655 pps (14897538 pkts in 1001000 usec)
>> main_thread [1192] 11900044 pps (12029754 pkts in 1010900 usec)
>> main_thread [1212] ouch, thread 1 exited with error
>> Sent 87502047 packets, 60 bytes each, in 5.86 seconds.
>> Speed: 14.92 Mpps Bandwidth: 7.16 Gbps (raw 10.03 Gbps)
>> -bash-4.2$
>>
>> But looking at the queue stats:
>>
>>
>> -bash-4.2$ sysctl -a | grep ix.1 | grep queue | grep rx_packets
>> dev.ix.1.queue0.rx_packets: 171
>> dev.ix.1.queue1.rx_packets: 0
>> dev.ix.1.queue2.rx_packets: 0
>> dev.ix.1.queue3.rx_packets: 0
>> dev.ix.1.queue4.rx_packets: 0
>> dev.ix.1.queue5.rx_packets: 0
>> dev.ix.1.queue6.rx_packets: 0
>> dev.ix.1.queue7.rx_packets: 0
>>
>> And after a few seconds:
>>
>> -bash-4.2$ sysctl -a | grep ix.1 | grep queue | grep rx_packets
>> dev.ix.1.queue0.rx_packets: 310
>> dev.ix.1.queue1.rx_packets: 0
>> dev.ix.1.queue2.rx_packets: 0
>> dev.ix.1.queue3.rx_packets: 0
>> dev.ix.1.queue4.rx_packets: 8
>> dev.ix.1.queue5.rx_packets: 0
>> dev.ix.1.queue6.rx_packets: 0
>> dev.ix.1.queue7.rx_packets: 0
>> -bash-4.2$
>>
>> What is going on here? Should I be seeing more pkts in rx_packets? Should
>> I see more queues being used?
>>
>> I am using stock ixgbe at this point. I believe RSS is enabled by
>> default?
>>
>
> fdir(flow director)/atr is also enabled by default.
>
> I tried to turn that off by following change in /sys/modules/ixgbe/Makefile
>
> -CFLAGS+= -I${.CURDIR}/../../dev/ixgbe -DSMP -DIXGBE_FDIR
> +CFLAGS+= -I${.CURDIR}/../../dev/ixgbe -DSMP
>
> But, now interface would not attach to netmap:
>
>
> sudo ./pkt-gen -i ix1 -f tx -n 1 -c 8 -p 8 -d 10.73.149.17 -s
> 10.73.149.28
> extract_ip_range [143] extract IP range from 10.73.149.28
> extract_ip_range [178]
Re: netmap: understanding pkg-gen.c
On Wed, Oct 2, 2013 at 4:15 PM, hiren panchasara wrote: > > > > On Wed, Oct 2, 2013 at 3:11 PM, hiren panchasara < > hiren.panchas...@gmail.com> wrote: > >> >> >> >> On Wed, Oct 2, 2013 at 1:18 PM, hiren panchasara < >> hiren.panchas...@gmail.com> wrote: >> >>> >>> Thanks Luigi. >>> >>> Coming back to this thread to actually understand what's going on. >>> >>> >>> On Tue, Sep 24, 2013 at 8:37 PM, Luigi Rizzo wrote: >>> >>>> > >>>> > On this box, I have 2 interfaces igb0 (10.73.149.28) and ix1 >>>> (10.73.149.17) >>>> > and this is how I am using this binary: >>>> > >>>> > -bash-4.2$ sudo ./pkt-gen -i ix1 -f tx -n 1 -c 8 -p 8 -d >>>> > 10.73.149.17 -s 10.73.149.28 >>>> >>> >>> So, my intention is to *send* 10gbps data to ix1 and see the card use >>> all of its 8 queues. >>> >>> Above command is the correct one? >>> >>> I kldunloaded/loaded ixbge to clear out all the stats and tested it >>> again: >>> >>> >>> -bash-4.2$ sudo ./pkt-gen -i ix1 -f tx -n 1 -c 8 -p 8 -d >>> 10.73.149.17 -s 10.73.149.28 >>> extract_ip_range [143] extract IP range from 10.73.149.28 >>> extract_ip_range [178] range is 10.73.149.28 0 to 10.73.149.28 0 >>> extract_ip_range [143] extract IP range from 10.73.149.17 >>> extract_ip_range [178] range is 10.73.149.17 0 to 10.73.149.17 0 >>> extract_mac_range [184] extract MAC range from 90:e2:ba:30:68:c5 >>> extract_mac_range [199] 90:e2:ba:30:68:c5 starts at 90:e2:ba:30:68:c5 >>> extract_mac_range [184] extract MAC range from ff:ff:ff:ff:ff:ff >>> extract_mac_range [199] ff:ff:ff:ff:ff:ff starts at ff:ff:ff:ff:ff:ff >>> main [1530] map size is 334980 Kb >>> main [1552] mapping 334980 Kbytes >>> Sending on ix1: 8 queues, 8 threads and 8 cpus. >>> 10.73.149.28 -> 10.73.149.17 (90:e2:ba:30:68:c5 -> ff:ff:ff:ff:ff:ff) >>> main [1622] Sending 512 packets every 0.0 ns >>> main [1624] Wait 2 secs for phy reset >>> main [1626] Ready... >>> sender_body [775] start >>> sender_body [775] start >>> sender_body [775] start >>> sender_body [775] start >>> sender_body [775] start >>> sender_body [775] start >>> sender_body [775] start >>> sender_body [848] drop copy >>> >>> sender_body [775] start >>> sender_body [848] drop copy >>> sender_body [848] drop copy >>> sender_body [848] drop copy >>> sender_body [848] drop copy >>> sender_body [848] drop copy >>> sender_body [848] drop copy >>> main_thread [1192] 15122963 pps (15130434 pkts in 1000494 usec) >>> main_thread [1192] 14881444 pps (14896266 pkts in 1000996 usec) >>> sender_body [841] poll error/timeout on queue 1 >>> main_thread [1192] 14880708 pps (15659371 pkts in 1052327 usec) >>> main_thread [1192] 14878611 pps (14888684 pkts in 1000677 usec) >>> main_thread [1192] 14882655 pps (14897538 pkts in 1001000 usec) >>> main_thread [1192] 11900044 pps (12029754 pkts in 1010900 usec) >>> main_thread [1212] ouch, thread 1 exited with error >>> Sent 87502047 packets, 60 bytes each, in 5.86 seconds. >>> Speed: 14.92 Mpps Bandwidth: 7.16 Gbps (raw 10.03 Gbps) >>> -bash-4.2$ >>> >>> But looking at the queue stats: >>> >>> >>> -bash-4.2$ sysctl -a | grep ix.1 | grep queue | grep rx_packets >>> dev.ix.1.queue0.rx_packets: 171 >>> dev.ix.1.queue1.rx_packets: 0 >>> dev.ix.1.queue2.rx_packets: 0 >>> dev.ix.1.queue3.rx_packets: 0 >>> dev.ix.1.queue4.rx_packets: 0 >>> dev.ix.1.queue5.rx_packets: 0 >>> dev.ix.1.queue6.rx_packets: 0 >>> dev.ix.1.queue7.rx_packets: 0 >>> >>> And after a few seconds: >>> >>> -bash-4.2$ sysctl -a | grep ix.1 | grep queue | grep rx_packets >>> dev.ix.1.queue0.rx_packets: 310 >>> dev.ix.1.queue1.rx_packets: 0 >>> dev.ix.1.queue2.rx_packets: 0 >>> dev.ix.1.queue3.rx_packets: 0 >>> dev.ix.1.queue4.rx_packets: 8 >>> dev.ix.1.queue5.rx_packets: 0 >>> dev.ix.1.queue6.rx_packets: 0 >>> dev.ix.1.queue7.rx_packets: 0 >>> -bash-4.2$ >>> >>> What is going on here? Should I be seeing more pkts in rx_packets? >>> Should I see more queues being used? >>> >>> I am using stock ixgbe at this point. I believe
Re: netmap: understanding pkg-gen.c
On Wed, Oct 2, 2013 at 4:39 PM, hiren panchasara wrote: > > > > On Wed, Oct 2, 2013 at 4:15 PM, hiren panchasara < > hiren.panchas...@gmail.com> wrote: > >> >> >> >> On Wed, Oct 2, 2013 at 3:11 PM, hiren panchasara < >> hiren.panchas...@gmail.com> wrote: >> >>> >>> >>> >>> On Wed, Oct 2, 2013 at 1:18 PM, hiren panchasara < >>> hiren.panchas...@gmail.com> wrote: >>> >>>> >>>> Thanks Luigi. >>>> >>>> Coming back to this thread to actually understand what's going on. >>>> >>>> >>>> On Tue, Sep 24, 2013 at 8:37 PM, Luigi Rizzo wrote: >>>> >>>>> > >>>>> > On this box, I have 2 interfaces igb0 (10.73.149.28) and ix1 >>>>> (10.73.149.17) >>>>> > and this is how I am using this binary: >>>>> > >>>>> > -bash-4.2$ sudo ./pkt-gen -i ix1 -f tx -n 1 -c 8 -p 8 -d >>>>> > 10.73.149.17 -s 10.73.149.28 >>>>> >>>> Thanks to Juli, I realized that I was doing it wrong. Trying to _send_ pkts from ix1 via netmap and looking at ix1's _receive_ buffers. I am setting up another machine with ixgbe to have 2 different machines for proper testing. Apologies for the noise. cheers, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: netmap: understanding pkg-gen.c
On Wed, Oct 2, 2013 at 11:05 PM, Luigi Rizzo wrote: > > > > On Thu, Oct 3, 2013 at 6:34 AM, hiren panchasara < > hiren.panchas...@gmail.com> wrote: > >> >> Thanks Luigi. >>>>>> >>>>>> Coming back to this thread to actually understand what's going on. >>>>>> >>>>>> >>>>>> On Tue, Sep 24, 2013 at 8:37 PM, Luigi Rizzo wrote: >>>>>> >>>>>>> > >>>>>>> > On this box, I have 2 interfaces igb0 (10.73.149.28) and ix1 >>>>>>> (10.73.149.17) >>>>>>> > and this is how I am using this binary: >>>>>>> > >>>>>>> > -bash-4.2$ sudo ./pkt-gen -i ix1 -f tx -n 1 -c 8 -p 8 -d >>>>>>> > 10.73.149.17 -s 10.73.149.28 >>>>>>> >>>>>> >> Thanks to Juli, I realized that I was doing it wrong. >> >> Trying to _send_ pkts from ix1 via netmap and looking at ix1's _receive_ >> buffers. >> >> I am setting up another machine with ixgbe to have 2 different machines >> for proper testing. >> > > since you have a dual port card, you can actually run the experiment > on a single machine, connecting the two ports with a > cross cable and run the sender on ix1 and the receiver on ix0. > Thanks but for now I have 2 machines with ixgbe to play with. > > But you will still see traffic only to one queue, because > pkt-gen by default uses the same DST-MAC address so the > way you configure RSS is irrelevant. > What/where is the exact logic/code of how card determines what traffic goes to what queue? Is it based on DST-MAC always? > What you could do is, when prefilling the buffers, use > different mac or ip addresses. There is some unfinished > code in pkt-gen.c to implement that. > I see we are not playing with g.dst_mac.name much. Let me know if you have unfinished code sitting somewhere I can look. Thanks, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Exposing sysctls for ixgbe
I am going to commit this change in the weekend. Let me know if there are any objections. Thanks, Hiren On Mon, Sep 30, 2013 at 8:51 AM, hiren panchasara wrote: > + jfv > > > On Wed, Sep 25, 2013 at 5:35 PM, Adrian Chadd wrote: > >> please cc jfv and get them into his driver. :) >> >> -a >> >> >> On 24 September 2013 23:53, hiren panchasara wrote: >> >>> Any comments? >>> >>> cheers, >>> Hiren >>> >>> On Sun, Sep 22, 2013 at 12:01 PM, hiren panchasara >> >wrote: >>> >>> > $ sysctl hw.igb >>> > hw.igb.rxd: 4096 >>> > hw.igb.txd: 4096 >>> > hw.igb.enable_aim: 1 >>> > hw.igb.enable_msix: 1 >>> > hw.igb.max_interrupt_rate: 8000 >>> > hw.igb.buf_ring_size: 4096 >>> > hw.igb.header_split: 0 >>> > hw.igb.num_queues: 1 >>> > hw.igb.rx_process_limit: 100 >>> > $ sysctl hw.ix >>> > sysctl: unknown oid 'hw.ix': No such file or directory >>> > >>> > I thought it would be nice to have these things exposed. So I copied >>> them >>> > from igb: >>> > http://people.freebsd.org/~hiren/ixgbe_sysctls.txt >>> > >>> > Changes for if_igb.c is to expose correct auto-tuned value for a >>> running >>> > system for "hw.igb.num_queues", which is not the case right now. >>> > >>> > Thanks to markj@ for help/pointers. >>> > >>> > Please let me know if the diffs look okay. >>> > >>> > cheers, >>> > Hiren >>> > >>> ___ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" >>> >> >> > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Exposing sysctls for ixgbe
Thanks. Committed via: http://svnweb.freebsd.org/base?view=revision&revision=256069 Cheers, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Adding Flow Director sysctls to ixgbe(4) (was: netmap: traffic distribution)
On Mon, Oct 7, 2013 at 12:01 AM, Takuya ASADA wrote: > Hi, > > This is updated version of "ixgbetool" patch. I will try to give this a try tomorrow. Cheers, Hiren > Here's improved feature list: > - signature filter list feature available > - user-defined filter can be use with an ATR. > To enable it, add "hw.ixgbe.cooperative_atr=1" on /boot/loader.conf > > Usage is as follows: > ixgbetool [operation] > add_sig_filter > > show_sig_filter > del_sig_filter > > > 2013/9/30 Takuya ASADA > >> Hi, >> >> I just implemented device specific ioctl with device specific >> configuration tool. >> It still doesn't support some important features such as: >> - FDIR enable / disable via sysctl or tunable params >> - ATR enable / disable via sysctl or tunable params >> - IPv6 support on signature filter >> - signature filter list >> - support perfect filter >> But, at least it can configure signature filter manually. >> >> Usage is as follows: >> Usage: ixgbetool [operation] >> add_sig_filter >> del_sig_filter >> >> >> 2013/9/28 hiren panchasara >> >>> >>> >>> >>> On Fri, Sep 27, 2013 at 1:58 AM, Takuya ASADA wrote: >>> >>>> 2013/9/27 Adrian Chadd >>>> >>>>> On 27 September 2013 00:43, hiren panchasara < >>>>> hiren.panchas...@gmail.com> wrote: >>>>> >>>>> >>>>>> Takuya, >>>>>> >>>>>> I see a lot of responses/comments on proposed changes. Was anything >>>>>> decided >>>>>> at the end of it? As far as I can tell, its still not committed to the >>>>>> tree. >>>>>> >>>>> >>>>> I'd rather see an ioctl API for that chipset and then have a separate >>>>> tool program it for now. >>>>> >>>> >>>> Ah, like cxgbetool and cxgbe? (it has device specific tool and ioctls) >>>> http://svnweb.freebsd.org/base/head/tools/tools/cxgbetool/ >>>> >>> >>> Something like this for ixgbe would be nice to start with, imo. >>> >>> Cheers, >>> Hiren >>> >>>> http://svnweb.freebsd.org/base/head/sys/dev/cxgb/ >>>> >>>> >>>>> So, how bout we hack that up? :) >>>>> >>>> >>>> Sound's interesting ;-) >>>> Could you tell me more detail about your idea? >>>> >>>> >>> >> > > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: igb(4) panic: already enqueue
Jack, I am also seeing similar panics at $work on a couple weeks old STABLE-9. Can you please look into this issue? cheers, Hiren 1) HP DL360e Gen8, 2 x Xeon E5-2430 2.20GHz panic: buf=0xfe002810d700 already enqueue at 995 prod=997 cons=995 cpuid = 17 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame 0xff868637b030 kdb_backtrace() at kdb_backtrace+0x37/frame 0xff868637b0f0 panic() at panic+0x1d8/frame 0xff868637b1f0 igb_mq_start() at igb_mq_start+0x1cb/frame 0xff868637b240 ether_output_frame() at ether_output_frame+0x33/frame 0xff868637b260 ether_output() at ether_output+0x52d/frame 0xff868637b2f0 ip_output() at ip_output+0xe38/frame 0xff868637b3e0 tcp_output() at tcp_output+0x122c/frame 0xff868637b5a0 tcp_do_segment() at tcp_do_segment+0x306c/frame 0xff868637b6c0 tcp_input() at tcp_input+0x909/frame 0xff868637b7f0 ip_input() at ip_input+0xbd/frame 0xff868637b840 netisr_dispatch_src() at netisr_dispatch_src+0x152/frame 0xff868637b8a0 ether_demux() at ether_demux+0x17d/frame 0xff868637b8d0 ether_nh_input() at ether_nh_input+0x208/frame 0xff868637b910 netisr_dispatch_src() at netisr_dispatch_src+0x152/frame 0xff868637b970 igb_rxeof() at igb_rxeof+0x394/frame 0xff868637b9e0 igb_handle_que() at igb_handle_que+0x9b/frame 0xff868637ba20 taskqueue_run_locked() at taskqueue_run_locked+0x93/frame 0xff868637ba80 taskqueue_thread_loop() at taskqueue_thread_loop+0x3e/frame 0xff868637baa0 fork_exit() at fork_exit+0x135/frame 0xff868637baf0 fork_trampoline() at fork_trampoline+0xe/frame 0xff868637baf0 2) HP DL160 G6, 2 x Xeon E5620 2.40GHz panic: buf=0xfe01b6334700 already enqueue at 42 prod=43 cons=42 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame 0xff800037a620 kdb_backtrace() at kdb_backtrace+0x37/frame 0xff800037a6e0 panic() at panic+0x1d8/frame 0xff800037a7e0 igb_mq_start() at igb_mq_start+0x1cb/frame 0xff800037a830 ether_output_frame() at ether_output_frame+0x33/frame 0xff800037a850 ether_output() at ether_output+0x52d/frame 0xff800037a8e0 ip_output() at ip_output+0xe38/frame 0xff800037a9d0 syncache_respond() at syncache_respond+0x462/frame 0xff800037aa90 syncache_timer() at syncache_timer+0xdf/frame 0xff800037aac0 softclock() at softclock+0x2c6/frame 0xff800037ab60 intr_event_execute_handlers() at intr_event_execute_handlers+0x6a/frame 0xff800037ab90 ithread_loop() at ithread_loop+0xac/frame 0xff800037abe0 fork_exit() at fork_exit+0x135/frame 0xff800037ac30 fork_trampoline() at fork_trampoline+0xe/frame 0xff800037ac30 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: TCP Initial Window 10 MFC
On Wed, Aug 14, 2013 at 8:46 PM, Lawrence Stewart wrote: > On 08/15/13 02:44, Andre Oppermann wrote: >> On 14.08.2013 04:36, Lawrence Stewart wrote: >>> Hi Andre, >>> >>> [RE team is BCCed so they're aware of this discussion] >>> >>> On 07/06/13 00:58, Andre Oppermann wrote: Author: andre Date: Fri Jul 5 14:58:24 2013 New Revision: 252789 URL: http://svnweb.freebsd.org/changeset/base/252789 Log: MFC r242266: Increase the initial CWND to 10 segments as defined in IETF TCPM draft-ietf-tcpm-initcwnd-05. It explains why the increased initial window improves the overall performance of many web services without risking congestion collapse. As long as it remains a draft it is placed under a sysctl marking it as experimental: net.inet.tcp.experimental.initcwnd10 = 1 When it becomes an official RFC soon the sysctl will be changed to the RFC number and moved to net.inet.tcp. This implementation differs from the RFC draft in that it is a bit more conservative in the case of packet loss on SYN or SYN|ACK because we haven't reduced the default RTO to 1 second yet. Also the restart window isn't yet increased as allowed. Both will be adjusted with upcoming changes. Is is enabled by default. In Linux it is enabled since kernel 3.0. >>> >>> I haven't been fully alert to FreeBSD happenings this year so apologies >>> for bringing this up so long after the MFC. >>> >>> I don't think this change should have been MFCed, at least not in its >>> current form. Enabling the switch to IW=10 on a stable branch is >>> inappropriate IMO. I also think the "net.inet.tcp.experimental" sysctl >>> branch is poorly named as per the important discussion we had back in >>> February [1]. I would really prefer we didn't get stuck having to keep >>> it around by making a stable release with it being present. >>> >>> I think this commit should be backed out of stable/9 and more >>> importantly, 9.2-RELEASE. >> >> Backing out the patch isn't really necessary, just flip the switch to >> off having it revert to the RFC5681 defaults. Those who want it anyway >> can simply enable it again. > > That doesn't address the sysctl tree naming concern or mechanism issue - > please refer back to the Feb discussion; specifically the proposal to > rename the experimental branch to "net.inet.tcp.nonstandard" and add an > "allowed" leaf which takes a list of non-standard behaviours to allow > tweaking in the stack. > > Leaving the sysctl branch named "experimental" conveys that the things > which live under the branch are being evaluated in some way for becoming > a default, which is very different to "nonstandard" which conveys that > the user is twiddling things in a way which normally shouldn't be. IW=10 > may become a FreeBSD default at some point, but the mechanism for > enabling it should be to specify the initial window as a value in > segments, and as such by allowing any non-standard value (IW=7, IW=50), > I strongly argue in favour for changing the branch name from > "experimental" to "nonstandard". > > In order to continue this discussion in the context of what we started > in Feb, I still request that this change be backed out of releng/9.2 so > that 9.2-RELEASE doesn't ship with it. We can continue discussion for > it's future in stable/9 and head after the backout so that 9.2 isn't > held up. > >> IW10 has become RFC6928 (experimental) in April 2013. > > Great for the draft authors, but irrelevant for this discussion. > >>> As an aside, I am intending to follow up to the Feb discussion with a >>> patch that implements the basic infrastructure I proposed so that we can >>> continue that discussion. >> >> Again I'm deeply concerned and opposed to giving end users direct control >> over the IW value. I've had and seen too many cases of totally bogus >> "tuning" >> by cranking up random sysctls to insane values and then complaining about >> FreeBSD being slow compared to Linux (and then ditching FreeBSD). > > Sorry, but referring to unspecified cases of stupidity resulting in loss > of unquantified numbers of users as a reason against providing a > controlled mechanism to change a default system parameter in a > potentially harmful way is not a rational argument. I do not subscribe to the idea of "Let's not make life of 98% of users better because 2% may do something stupid". I am revisiting this thread because at $work, we need to tweak initcwnd (other than 10) to see how it behaves but there is no easy way to tune it. (or am I missing something?) Can we please make initcwnd a sysctl tunable? cheers, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: TCP Initial Window 10 MFC
On Tue, Mar 4, 2014 at 7:38 PM, Lawrence Stewart wrote: > I lost the battle of wills on this topic and 10.0 shipped with IW10 > enabled by default :( > > As for having it configurable, it is a trivial patch which perhaps, > Hiren, you might be willing to take a stab at? I obviously did not > manage to carve out the time last year to push forward with the agenda I > proposed in this thread, but I will get back to it at some point. Hi Lawrence, Let's fix it the right way if possible. Below is a rough/untested quick patch I came up with. Is this how you were planning to have "nonstandard" sysctl knob designed? Index: sys/netinet/tcp_input.c === --- sys/netinet/tcp_input.c (revision 260833) +++ sys/netinet/tcp_input.c (working copy) @@ -164,6 +164,19 @@ &VNET_NAME(tcp_do_initcwnd10), 0, "Enable RFC 6928 (Increasing initial CWND to 10)"); +SYSCTL_NODE(_net_inet_tcp, OID_AUTO, nonstandard, CTLFLAG_RW, 0, +"Nonstandard TCP extensions"); + +VNET_DEFINE(int, tcp_nonstandard_allowed) = 0; +SYSCTL_VNET_INT(_net_inet_tcp_nonstandard, OID_AUTO, allowed, CTLFLAG_RW, +&VNET_NAME(tcp_nonstandard_allowed), 0, +"Allow nonstandard TCP extensions"); + +VNET_DEFINE(int, tcp_nonstandard_initcwnd) = 0; +SYSCTL_VNET_INT(_net_inet_tcp_nonstandard, OID_AUTO, initcwnd, CTLFLAG_RW, +&VNET_NAME(tcp_nonstandard_initcwnd), 0, +"Slow-start flight size (initial congestion window)"); + VNET_DEFINE(int, tcp_do_rfc3465) = 1; SYSCTL_VNET_INT(_net_inet_tcp, OID_AUTO, rfc3465, CTLFLAG_RW, &VNET_NAME(tcp_do_rfc3465), 0, @@ -368,6 +381,8 @@ */ if (tp->snd_cwnd == 1) tp->snd_cwnd = tp->t_maxseg;/* SYN(-ACK) lost */ + else if (V_tcp_nonstandard_allowed && V_tcp_nonstandard_initcwnd) + tp->snd_cwnd = V_tcp_nonstandard_initcwnd * tp->t_maxseg; else if (V_tcp_do_initcwnd10) tp->snd_cwnd = min(10 * tp->t_maxseg, max(2 * tp->t_maxseg, 14600)); Index: sys/netinet/tcp_var.h === --- sys/netinet/tcp_var.h (revision 260833) +++ sys/netinet/tcp_var.h (working copy) @@ -610,6 +610,7 @@ VNET_DECLARE(int, tcp_delack_enabled); VNET_DECLARE(int, tcp_do_rfc3390); VNET_DECLARE(int, tcp_do_initcwnd10); +VNET_DECLARE(int, tcp_nonstandard_allowed); +VNET_DECLARE(int, tcp_nonstandard_initcwnd); VNET_DECLARE(int, tcp_sendspace); VNET_DECLARE(int, tcp_recvspace); VNET_DECLARE(int, path_mtu_discovery); @@ -622,6 +623,7 @@ #defineV_tcp_delack_enabledVNET(tcp_delack_enabled) #defineV_tcp_do_rfc3390VNET(tcp_do_rfc3390) #defineV_tcp_do_initcwnd10 VNET(tcp_do_initcwnd10) +#defineV_tcp_nonstandard_allowed VNET(tcp_nonstandard_allowed) +#defineV_tcp_nonstandard_initcwnd VNET(tcp_nonstandard_initcwnd) #defineV_tcp_sendspace VNET(tcp_sendspace) #defineV_tcp_recvspace VNET(tcp_recvspace) #defineV_path_mtu_discoveryVNET(path_mtu_discovery) ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Include port number in "Listen queue overflow" messages
I am thinking of committing following change that includes port number
in "Listen queue overflow" messages.
New message would look something like:
sonewconn: pcb 0xf8001b155760: Listen queue overflow on port
13120: 1 already in queue awaiting acceptance (454 occurrences)
I've recently ran into a situation at $work where I could not catch
the culprit application via "netstat -A" and had to dive into kgdb to
find the port from pcb where this application was listening to.
IMO, this change will make debugging easier.
cheers,
Hiren
Index: sys/kern/uipc_socket.c
===
--- sys/kern/uipc_socket.c (revision 262861)
+++ sys/kern/uipc_socket.c (working copy)
@@ -136,6 +136,7 @@
#include
#include
#include
+#include
#include
@@ -491,8 +492,11 @@
static int overcount;
struct socket *so;
+ struct inpcb *inp;
int over;
+ inp = sotoinpcb(head);
+
ACCEPT_LOCK();
over = (head->so_qlen > 3 * head->so_qlimit / 2);
ACCEPT_UNLOCK();
@@ -504,10 +508,12 @@
overcount++;
if (ratecheck(&lastover, &overinterval)) {
- log(LOG_DEBUG, "%s: pcb %p: Listen queue overflow: "
- "%i already in queue awaiting acceptance "
+ log(LOG_DEBUG, "%s: pcb %p: Listen queue overflow on "
+ "port %d: %i already in queue awaiting acceptance "
"(%d occurrences)\n",
- __func__, head->so_pcb, head->so_qlen, overcount);
+ __func__, head->so_pcb,
+ ntohs(inp->inp_inc.inc_lport), head->so_qlen,
+ overcount);
overcount = 0;
}
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Include port number in "Listen queue overflow" messages
On Wed, Mar 19, 2014 at 4:35 PM, Navdeep Parhar wrote:
> On Tue, Mar 18, 2014 at 11:05:23PM -0700, Julian Elischer wrote:
>> On 3/18/14, 8:33 PM, George Neville-Neil wrote:
>> >On Mar 7, 2014, at 1:23 , hiren panchasara
>> >wrote:
>> >
>> >>I am thinking of committing following change that includes port number
>> >>in "Listen queue overflow" messages.
>> I think it's a good idea. There is even more information available
>> but this is probably enough.
>> >>
>> >I like it.
>> >
>> >Best,
>> >George
>> >
>
> I think the suggested change isn't correct as is assumes every socket's pcb is
> an inpcb.
You are right. I'd need to think a bit more about a possible solution.
Thanks for your help.
cheers,
Hiren
>
> Navdeep
>
>> >>New message would look something like:
>> >>sonewconn: pcb 0xf8001b155760: Listen queue overflow on port
>> >>13120: 1 already in queue awaiting acceptance (454 occurrences)
>> >>
>> >>I've recently ran into a situation at $work where I could not catch
>> >>the culprit application via "netstat -A" and had to dive into kgdb to
>> >>find the port from pcb where this application was listening to.
>> >>
>> >>IMO, this change will make debugging easier.
>> >>
>> >>cheers,
>> >>Hiren
>> >>
>> >>Index: sys/kern/uipc_socket.c
>> >>===
>> >>--- sys/kern/uipc_socket.c (revision 262861)
>> >>+++ sys/kern/uipc_socket.c (working copy)
>> >>@@ -136,6 +136,7 @@
>> >>#include
>> >>#include
>> >>#include
>> >>+#include
>> >>
>> >>#include
>> >>
>> >>@@ -491,8 +492,11 @@
>> >>static int overcount;
>> >>
>> >>struct socket *so;
>> >>+ struct inpcb *inp;
>> >>int over;
>> >>
>> >>+ inp = sotoinpcb(head);
>> >>+
>> >>ACCEPT_LOCK();
>> >>over = (head->so_qlen > 3 * head->so_qlimit / 2);
>> >>ACCEPT_UNLOCK();
>> >>@@ -504,10 +508,12 @@
>> >>overcount++;
>> >>
>> >>if (ratecheck(&lastover, &overinterval)) {
>> >>- log(LOG_DEBUG, "%s: pcb %p: Listen queue overflow:
>> >>"
>> >>- "%i already in queue awaiting acceptance "
>> >>+ log(LOG_DEBUG, "%s: pcb %p: Listen queue overflow
>> >>on "
>> >>+ "port %d: %i already in queue awaiting
>> >>acceptance "
>> >>"(%d occurrences)\n",
>> >>- __func__, head->so_pcb, head->so_qlen,
>> >>overcount);
>> >>+ __func__, head->so_pcb,
>> >>+ ntohs(inp->inp_inc.inc_lport), head->so_qlen,
>> >>+ overcount);
>> >>
>> >>overcount = 0;
>> >>}
>> >>___
>> >>freebsd-net@freebsd.org mailing list
>> >>http://lists.freebsd.org/mailman/listinfo/freebsd-net
>> >>To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
>> >___
>> >freebsd-net@freebsd.org mailing list
>> >http://lists.freebsd.org/mailman/listinfo/freebsd-net
>> >To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
>> >
>>
>> ___
>> freebsd-net@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
hostcache's effect on initcwnd calculation
Host A:1 talks to Host B:2 (1 and 2 being ports) and it gets logged in tcp's hostcache. Now if a new connection happens between A:10001 and Host B:2, the initcwnd (initial congestion window) would not look at the CWND from hostcache but will always use what we've set as tp->snd_cwnd in cc_conn_init() of tcp_input.c - is this a correct assumption? What I want to confirm is, whether hostcache has any effect on initial congestion window of a new connection being setup. >From my reading of the code, cc_conn_init() always happens before we call tcp_hc_get() to get data out of hostcache to update other parameters of a connection. I do not see hc_entry->rmx_cwnd being actually used anywhere in tcp_input.c while connection bring up. Am I missing anything? cheers, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: questions about (system) dhcp
On Mon, Mar 31, 2014 at 6:31 AM, Robert Huff wrote: > Hello: > Is this the correct place to ask? Yes. Cheers, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: DCTCP implementation
On Sun, Mar 30, 2014 at 10:37 PM, Midori Kato wrote: > Hi FreeBSD developpers, > > I'm Midori Kato. I'm working on the DCTCP implementation in the FreeBSD with > Lars Eggert. I mail you because I would like to ask you a code review and > testing. The attached patch is not good enough to test our code. Please give > me your message. I will send an ECN marking implmenetation in dummynet and > test scripts personally to you. Hi Midori, Thank you for your work and I'd like to test this. Please let me know how you setup the dummynet testing cluster and I'll try it. cheers, Hiren ccing gnn@ as he was also asking for the same (testing details). ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: DCTCP implementation
On Sun, Mar 30, 2014 at 10:37 PM, Midori Kato wrote: > Hi FreeBSD developpers, > > I'm Midori Kato. I'm working on the DCTCP implementation in the FreeBSD with > Lars Eggert. I mail you because I would like to ask you a code review and > testing. The attached patch is not good enough to test our code. Please give > me your message. I will send an ECN marking implmenetation in dummynet and > test scripts personally to you. Midori, First thing I noticed in your dctcp.patch is that you are dropping r256920 which adds a new argument tlen to DELAY_ACK() macro. I also see you removed and re-added that macro definition without any changes to it. Is that intentional? If not, can you please fix that and resend the patch? It is usually a good idea to work on -HEAD for such things so patching/committing is easier. cheers, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: DCTCP implementation
On Thu, Apr 3, 2014 at 4:27 AM, Midori Kato wrote: > Hi Hiren, > > Yes, I intentionally replace the location of DELAY_ACK() macro. > A DCTCP receiver sends an immediate ACK when incoming packets sets CE and > non-CE bit by turns. To implement this processing, I prepare the > cc_ecnpkt_handler() function. This function calls the DEKAY_ACK() macro to > check if this packet is in delayed ack or not. This is why I replace the > macro position. That is fine but macro definition is also changed. This is how it looks on -HEAD right now: #define DELAY_ACK(tp, tlen) \ ((!tcp_timer_active(tp, TT_DELACK) && \ (tp->t_flags & TF_RXWIN0SENT) == 0) && \ (tlen <= tp->t_maxopd) && \ (V_tcp_delack_enabled || (tp->t_flags & TF_NEEDSYN))) We need to pass this new argument "tlen" when calling DELAY_ACK() from cc_ecnpkt_handler() function. We can probably pass that to cc_encpkg_handler() while calling it from tcp_do_segment(). I'll make that change and see how it goes. cheers, Hiren > > Regards, > -- Midori > > > (4/3/14, 10:24 AM), hiren panchasara wrote: >> >> On Sun, Mar 30, 2014 at 10:37 PM, Midori Kato >> wrote: >>> >>> Hi FreeBSD developpers, >>> >>> I'm Midori Kato. I'm working on the DCTCP implementation in the FreeBSD >>> with >>> Lars Eggert. I mail you because I would like to ask you a code review and >>> testing. The attached patch is not good enough to test our code. Please >>> give >>> me your message. I will send an ECN marking implmenetation in dummynet >>> and >>> test scripts personally to you. >> >> Midori, >> >> First thing I noticed in your dctcp.patch is that you are dropping >> r256920 which adds a new argument tlen to DELAY_ACK() macro. I also >> see you removed and re-added that macro definition without any changes >> to it. >> >> Is that intentional? If not, can you please fix that and resend the patch? >> >> It is usually a good idea to work on -HEAD for such things so >> patching/committing is easier. >> >> cheers, >> Hiren >> ___ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: netisr 0 : %100 and other netisr threads are waiting
On Thu, Apr 3, 2014 at 9:54 PM, Özkan KIRIK wrote: > Hi, > > I am trying to use suricata on FreeBSD 10 amd64. > FreeBSD behaves as a VLAN router and NAT Box. > > Traffic is about 400Mbps. > When i diverted traffic to suricata, swi: netisr 0 thread gets %100 cpu. > other netisr threads are %0. And Even I remove the divert rule, netisr > still eats %100 cpu. I think that something looping :) To be clear, this happens only *after* you divert traffic to suricata, right? > And after 1-2 minutes, one of igb0 and igb1 stops working. > Only reboot solves problem. > > Hardware has 8 cores, 24GB Ram > > My loader.conf : > > hw.igb.txd="4096" > hw.igb.rxd="4096" > hw.igb.rx_process_limit=1024 > hw.igb.num_queues=3 > net.isr.maxthreads=3 > net.isr.bindthreads=1 > net.isr.defaultqlimit=4096 > net.isr.maxqlimit=20480 > net.link.ifqmaxlen=10240 > > How can I debug this situation? > Any suggestions? I am not an expert here but please upload o/p for "sysctl net.isr" and "sysctl dev.igb" which would show error counters to get some idea about why igb0 or igb1 stops working. Whether we are running out of some resources or something else is going on. cheers, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: ECN marking implenetation for dummynet
On Tue, Apr 8, 2014 at 8:46 PM, Adrian Chadd wrote: > Hi! Cool! can you file a FreeBSD PR with this? I'm testing this patch right now. I will make sure it doesn't get lost. :-) cheers, Hiren > > > -a > > > On 2 April 2014 04:48, Midori Kato wrote: >> Hi FreeBSD developers, >> >> I'm Midori Kato. I was working with Lars Eggert about DCTCP. >> I would like to share our patch for an ECN marking mechanism on >> dummynet, which I used for DCTCP testing. >> >> My implementation allows to set ECN with RED as an AQM scheme. The >> following command is an example: >> $ ipfw pipe config red 1/10/10/0.0 ecn >> >> Our implementation includes both DCTCP and RFC 3168 ECN marking methodology. >> >> If you are interested in our ECN implemention, I'm very happy to receive >> your review! (I have already submitted my patch to Luigi and hope he >> will merge ours in near future.) >> >> Regards, >> -- Midori >> >> ___ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
netisr observations
(Note: This may seem more like a rant than an actual problem report.)
I am on a stable-10ish box with igb0. Workload is mainly inbound nfs
traffic. About 2K connections at any point in time.
device igb # Intel PRO/1000 PCIE Server Gigabit Family
hw.igb.rxd: 4096
hw.igb.txd: 4096
hw.igb.enable_aim: 1
hw.igb.enable_msix: 1
hw.igb.max_interrupt_rate: 32768
hw.igb.buf_ring_size: 4096
hw.igb.header_split: 0
hw.igb.num_queues: 0
hw.igb.rx_process_limit: 100
dev.igb.0.%desc: Intel(R) PRO/1000 Network Connection version - 2.4.0
dev.igb.0.%driver: igb
dev.igb.0.%location: slot=0 function=0
dev.igb.0.%pnpinfo: vendor=0x8086 device=0x10c9 subvendor=0x103c
subdevice=0x323f class=0x02
-bash-4.2$ netstat -I igb0 -i 1
input igb0 output
packets errs idrops bytespackets errs bytes colls
18332 0 0 19096474 22946 0 18211000 0
19074 0 0 11408912 28280 0 29741195 0
15753 0 0 15499238 21234 0 16779695 0
12914 0 09583719 17945 0 14599603 0
13677 0 0 10818359 19050 0 15069889 0
-bash-4.2$ sysctl net.isr
net.isr.dispatch: direct
net.isr.maxthreads: 8
net.isr.bindthreads: 0
net.isr.maxqlimit: 10240
net.isr.defaultqlimit: 256
net.isr.maxprot: 16
net.isr.numthreads: 8
-bash-4.2$ sysctl -a | grep igb.0 | grep rx_bytes
dev.igb.0.queue0.rx_bytes: 65473003127
dev.igb.0.queue1.rx_bytes: 73982776038
dev.igb.0.queue2.rx_bytes: 57669494795
dev.igb.0.queue3.rx_bytes: 57830053867
dev.igb.0.queue4.rx_bytes: 75087429774
dev.igb.0.queue5.rx_bytes: 69252615374
dev.igb.0.queue6.rx_bytes: 70565370833
dev.igb.0.queue7.rx_bytes: 90210083223
I am seeing something interesting in "top":
PID USERNAME THR PRI NICE SIZERES STATE C TIMEWCPU COMMAND
12 root 68 -72-0K 1088K WAIT0
279:36 65.77% intr
I see "intr" in on of top 3 slots almost all the time.
turning on -H (thread view) shows me:
12 root-72- 0K 1088K WAIT2 69:04 20.36%
intr{swi1: netisr 3}
(Does this mean netisr has swi (software interrupt) on cpu3?)
also, I see this process jumping to all different CPUs (so its not
sticking to 1 cpu)
-bash-4.2$ vmstat -i
interrupt total rate
irq4: uart0 1538 0
cpu0:timer 23865486 1108
irq256: igb0:que 0 46111948 2140
irq257: igb0:que 1 49820986 2313
irq258: igb0:que 2 41914519 1945
irq259: igb0:que 3 40926921 1900
irq260: igb0:que 4 49549124 2300
irq261: igb0:que 5 47066777 2185
irq262: igb0:que 6 50945395 2365
irq263: igb0:que 7 47147662 2188
irq264: igb0:link 2 0
irq274: ahci0:ch0 196869 9
cpu1:timer 23866170 1108
cpu10:timer 23805794 1105
cpu4:timer 23870757 1108
cpu11:timer 23806733 1105
cpu13:timer 23806644 1105
cpu2:timer 23858811 1107
cpu3:timer 23862250 1107
cpu15:timer 23805634 1105
cpu7:timer 23863865 1107
cpu9:timer 23810503 1105
cpu5:timer 23864136 1107
cpu12:timer 23808397 1105
cpu8:timer 23806059 1105
cpu6:timer 23874612 1108
cpu14:timer 23807698 1105
Total 755065290 35055
So, i seems all queues are being used uniformly.
-bash-4.2$ netstat -Q
Configuration:
SettingCurrentLimit
Thread count 88
Default queue limit25610240
Dispatch policy direct n/a
Threads bound to CPUs disabled n/a
Protocols:
Name Proto QLimit Policy Dispatch Flags
ip 1 1024 flow default ---
igmp 2256 source default ---
rtsock 3256 source default ---
arp7256 source default ---
ether 9256 source direct ---
ip6 10256 flow default ---
But the *interesting* part from it:
-bash-4.2$ netstat -Q | grep "ip " (looking at just ip in workstreams)
Workstreams:
WSID CPU Name Len WMark Disp'd HDisp'd QDrops Queued Handled
0 0 ip 0 0 7381526700
0 73815267
1 1 ip 0 0 6897508400
068975084
2 2 ip 0 0 4894396000
0 48943960
3 3 ip 0
Re: Patches for RFC6937 and draft-ietf-tcpm-newcwv-00
On Fri, Apr 11, 2014 at 4:15 AM, Eggert, Lars wrote: > Hi, > > since folks are playing with Midori's DCTCP patch, I wanted to make sure that > you were also aware of the patches that Aris did for PRR and NewCWV... >> >> Lars, There are no actual patches attached here. (Or the mailing-list dropped them.) cheers, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Patches for RFC6937 and draft-ietf-tcpm-newcwv-00
On Fri, Apr 11, 2014 at 4:16 PM, hiren panchasara wrote: > On Fri, Apr 11, 2014 at 4:15 AM, Eggert, Lars wrote: >> Hi, >> >> since folks are playing with Midori's DCTCP patch, I wanted to make sure >> that you were also aware of the patches that Aris did for PRR and NewCWV... > >>> >>> > > Lars, > > There are no actual patches attached here. (Or the mailing-list dropped them.) Ah, my bad. I think you are referring to the patches in original email. I can see them. cheers, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: netisr observations
On Fri, Apr 11, 2014 at 11:30 AM, Patrick Kelsey wrote:
>
> The output of netstat -Q shows IP dispatch is set to default, which is
> direct (NETISR_DISPATCH_DIRECT). That means each IP packet will be
> processed on the same CPU that the Ethernet processing for that packet was
> performed on, so CPU selection for IP packets will not be based on flowid.
> The output of netstat -Q shows Ethernet dispatch is set to direct
> (NETISR_DISPATCH_DIRECT if you wind up reading the code), so the Ethernet
> processing for each packet will take place on the same CPU that the driver
> receives that packet on.
>
> For the igb driver with queues autoconfigured and msix enabled, as the
> sysctl output shows you have, the driver will create a number of queues
> subject to device limitations, msix message limitations, and the number of
> CPUs in the system, establish a separate interrupt handler for each one, and
> bind each of those interrupt handlers to a separate CPU. It also creates a
> separate single-threaded taskqueue for each queue. Each queue interrupt
> handler sends work to its associated taskqueue when the interrupt fires.
> Those taskqueues are where the Ethernet packets are received and processed
> by the driver. The question is where those taskqueue threads will be run.
> I don't see anything in the driver that makes an attempt to bind those
> taskqueue threads to specific CPUs, so really the location of all of the
> packet processing is up to the scheduler (i.e., arbitrary).
>
> The summary is:
>
> 1. the hardware schedules each received packet to one of its queues and
> raises the interrupt for that queue
> 2. that queue interrupt is serviced on the same CPU all the time, which is
> different from the CPUs for all other queues on that interface
> 3. the interrupt handler notifies the corresponding task queue, which runs
> its task in a thread on whatever CPU the scheduler chooses
> 4. that task dispatches the packet for Ethernet processing via netisr, which
> processes it on whatever the current CPU is
> 5. Ethernet processing dispatches that packet for IP processing via netisr,
> which processes it on whatever the current CPU is
I really appreciate you taking time and explaining this. Thank you.
I am specially confused with ip "Queued" column from netstat -Q
showing 203888563 only for cpu3. Does this mean that cpu3 queues
everything and then distributes among other cpus? Where does this
queuing on cpu3 happens out of 5 stages you mentioned above?
This value gets populated in snwp->snw_queued field for each cpu
inside sysctl_netisr_work().
>
> You might want to try changing the default netisr dispatch policy to
> 'deferred' (sysctl net.isr.dispatch=deferred). If you do that, the Ethernet
> processing will still happen on an arbitrary CPU chosen by the scheduler,
> but the IP processing should then get mapped to a CPU based on the flowid
> assigned by the driver. Since igb assigns flowids based on received queue
> number, all IP (and above) processing for that packet should then be
> performed on the same CPU the queue interrupt was bound to.
I will give this a try and see how things behave.
I was also thinking about net.isr.bindthreads. netisr_start_swi() does
intr_event_bind() if we have it bindthreads set to 1. What would that
gain me, if anything?
Would it stop moving intr{swi1: netisr 3} on to different cpus (as I
am seeing in 'top' o/p) and bind it to a single cpu?
I've came across a thread discussing some side-effects of this though:
http://lists.freebsd.org/pipermail/freebsd-hackers/2012-January/037597.html
Thanks a ton, again.
cheers,
Hiren
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/184311: [bge] [panic] kernel panic with bge(4) on SunFire X2100
The following reply was made to PR kern/184311; it has been noted by GNATS. From: hiren panchasara To: bug-follo...@freebsd.org, benjamin.st...@ub.uni-tuebingen.de Cc: Subject: Re: kern/184311: [bge] [panic] kernel panic with bge(4) on SunFire X2100 Date: Mon, 19 May 2014 13:08:14 -0700 I just hit this on FreeBSD10. vgapci0: mem 0xc900-0xc9ff,0xd000-0xd7ff irq 16 at device 5.0 on pci1 vgapci0: Boot video device pcib2: at device 12.0 on pci0 pci2: on pcib2 bge0: mem 0xca00-0xca00 irq 16 at device 0.0 on pci2 bge0: CHIP ID 0x4101; ASIC REV 0x04; CHIP REV 0x41; PCI-E miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: Ethernet address: 00:17:08:92:b6:e9 pcib3: at device 13.0 on pci0 pci3: on pcib3 bge1: mem 0xca10-0xca10 irq 19 at device 0.0 on pci3 bge1: CHIP ID 0x4101; ASIC REV 0x04; CHIP REV 0x41; PCI-E miibus1: on bge1 brgphy1: PHY 1 on miibus1 brgphy1: no media present ifmedia_set: no match for 0x0/0xfff panic: ifmedia_set cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0x81a3f1b0 kdb_backtrace() at kdb_backtrace+0x39/frame 0x81a3f260 vpanic() at vpanic+0x126/frame 0x81a3f2a0 panic() at panic+0x43/frame 0x81a3f300 ifmedia_set() at ifmedia_set+0x5a/frame 0x81a3f310 brgphy_attach() at brgphy_attach+0x3a4/frame 0x81a3f350 device_attach() at device_attach+0x3a2/frame 0x81a3f3b0 bus_generic_attach() at bus_generic_attach+0x4a/frame 0x81a3f3d0 miibus_attach() at miibus_attach+0xbd/frame 0x81a3f410 device_attach() at device_attach+0x3a2/frame 0x81a3f470 bus_generic_attach() at bus_generic_attach+0x4a/frame 0x81a3f490 mii_attach() at mii_attach+0x435/frame 0x81a3f520 bge_attach() at bge_attach+0x4151/frame 0x81a3f600 device_attach() at device_attach+0x3a2/frame 0x81a3f660 bus_generic_attach() at bus_generic_attach+0x4a/frame 0x81a3f680 acpi_pci_attach() at acpi_pci_attach+0x15f/frame 0x81a3f6d0 device_attach() at device_attach+0x3a2/frame 0x81a3f730 bus_generic_attach() at bus_generic_attach+0x4a/frame 0x81a3f750 acpi_pcib_attach() at acpi_pcib_attach+0x23d/frame 0x81a3f7a0 acpi_pcib_pci_attach() at acpi_pcib_pci_attach+0x9f/frame 0x81a3f7e0 device_attach() at device_attach+0x3a2/frame 0x81a3f840 bus_generic_attach() at bus_generic_attach+0x4a/frame 0x81a3f860 acpi_pci_attach() at acpi_pci_attach+0x15f/frame 0x81a3f8b0 device_attach() at device_attach+0x3a2/frame 0x81a3f910 bus_generic_attach() at bus_generic_attach+0x4a/frame 0x81a3f930 acpi_pcib_attach() at acpi_pcib_attach+0x23d/frame 0x81a3f980 acpi_pcib_acpi_attach() at acpi_pcib_acpi_attach+0x2a9/frame 0x81a3f9d0 device_attach() at device_attach+0x3a2/frame 0x81a3fa30 bus_generic_attach() at bus_generic_attach+0x4a/frame 0x81a3fa50 acpi_attach() at acpi_attach+0xdd4/frame 0x81a3fb10 device_attach() at device_attach+0x3a2/frame 0x81a3fb70 bus_generic_attach() at bus_generic_attach+0x4a/frame 0x81a3fb90 nexus_acpi_attach() at nexus_acpi_attach+0x76/frame 0x81a3fbc0 device_attach() at device_attach+0x3a2/frame 0x81a3fc20 bus_generic_new_pass() at bus_generic_new_pass+0x116/frame 0x81a3fc50 bus_set_pass() at bus_set_pass+0x8f/frame 0x81a3fc80 configure() at configure+0xa/frame 0x81a3fc90 mi_startup() at mi_startup+0x118/frame 0x81a3fcb0 btext() at btext+0x2c Uptime: 1s Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/190102: [tcp] net.inet.tcp.drop_synfin=1 no longer works on FreeBSD 10+ [regression]
On Wed, May 28, 2014 at 10:46 PM, Eygene Ryabinkin wrote: > I assume that your pf(4) is enabled during these tests, you have > "scrub" statements in the ruleset and removing "scrub" will restore > the expected behaviour on 10.x? I can confirm that I see exactly what you are saying on a stable/10 box. cheers, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/190102: [tcp] net.inet.tcp.drop_synfin=1 no longer works on FreeBSD 10+ [regression]
The following reply was made to PR kern/190102; it has been noted by GNATS. From: hiren panchasara To: Eygene Ryabinkin Cc: FreeBSD GNATS followup , "freebsd-net@freebsd.org" Subject: Re: kern/190102: [tcp] net.inet.tcp.drop_synfin=1 no longer works on FreeBSD 10+ [regression] Date: Wed, 28 May 2014 23:52:51 -0700 On Wed, May 28, 2014 at 10:46 PM, Eygene Ryabinkin wrote: > I assume that your pf(4) is enabled during these tests, you have > "scrub" statements in the ruleset and removing "scrub" will restore > the expected behaviour on 10.x? I can confirm that I see exactly what you are saying on a stable/10 box. cheers, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/190102: [tcp] net.inet.tcp.drop_synfin=1 no longer works on FreeBSD 10+ [regression]
- bugs (as this is not related to it) On Wed, May 28, 2014 at 10:46 PM, Eygene Ryabinkin wrote: > clearing FIN bit for SYN packets was > the standard behaviour of pf since approximately at least 10 years, > > http://svnweb.freebsd.org/base/vendor-sys/pf/dist/sys/contrib/pf/net/pf_norm.c?view=markup&pathrev=126258#l1242 I am curious, what's the rationale for this behavior? Why does PF clear the FIN bit for such a packet being a firewall? Cheers, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: ECN marking implenetation for dummynet
On Tue, Apr 8, 2014 at 9:14 PM, hiren panchasara wrote: > On Tue, Apr 8, 2014 at 8:46 PM, Adrian Chadd wrote: >> Hi! Cool! can you file a FreeBSD PR with this? > > I'm testing this patch right now. > > I will make sure it doesn't get lost. :-) Committed as r266941. cheers, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: ECN marking implenetation for dummynet
On Sun, Jun 1, 2014 at 2:08 AM, Luigi Rizzo wrote: > > > On Sunday, June 1, 2014, hiren panchasara > wrote: >> >> On Tue, Apr 8, 2014 at 9:14 PM, hiren panchasara >> wrote: >> > On Tue, Apr 8, 2014 at 8:46 PM, Adrian Chadd wrote: >> >> Hi! Cool! can you file a FreeBSD PR with this? >> > >> > I'm testing this patch right now. >> > >> > I will make sure it doesn't get lost. :-) >> >> Committed as r266941. >> > > I don't think we need the DNOLD_IS_ECN flag and translation. That stuff is > meant for old binaries Thanks for pointing it out. Committed as r266955. cheers, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: ECN marking implenetation for dummynet
On Sun, Jun 1, 2014 at 12:31 AM, hiren panchasara wrote: > On Tue, Apr 8, 2014 at 9:14 PM, hiren panchasara > wrote: >> On Tue, Apr 8, 2014 at 8:46 PM, Adrian Chadd wrote: >>> Hi! Cool! can you file a FreeBSD PR with this? >> >> I'm testing this patch right now. >> >> I will make sure it doesn't get lost. :-) > > Committed as r266941. I wish to MFC this change and following actual dctcp changes (which I'll commit to -head in coming weeks) to 10. Let me know if there is any objection to it. cheers, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: ECN marking implenetation for dummynet
On Mon, Jun 9, 2014 at 1:31 AM, Lawrence Stewart wrote: > On 6/8/2014 9:07 PM, hiren panchasara wrote: >> I wish to MFC this change and following actual dctcp changes (which >> I'll commit to -head in coming weeks) to 10. >> >> Let me know if there is any objection to it. > > > Please don't MFC the DCTCP stuff until I've had a chance to consider the KPI > changes. Prodding me to do so is likely a good idea. I am in no rush to MFC. But I didn't quite get what you are talking about wrt KPI changes. cheers, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: LEDBAT (RFC-6817)i n FreeBSD as mod_cc(9)?
On Mon, Jun 16, 2014 at 6:25 AM, Lev Serebryakov wrote: > Hello, Freebsd-net. > > It looks like, that some TCP connections could benefit from LEDBAT > (RFC-6871) cognestion control algorithm (not all, of course, it should not > be default). > > Also, it looks like Apple implements one > > (http://www.opensource.apple.com/source/xnu/xnu-1699.32.7/bsd/netinet/tcp_ledbat.c), > but it uses much more "callbacks" from TCP/SCTP core to CC module, that > FreeBSD has. > > Does somebody evaluate, is it possible to bring LEDBAT to FreeBSD? I'd guess there is nothing wrong in having this as a cc module. Someone has to do the necessary legwork :-) cheers, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
getpeername returning ENOTCONN for a connected socket
Reviving an old thread where Steve found this problem: A call to
getpeername on a connected tcp socket returns ENOTCONN with no prior
errors being reported by previous socket calls.
Please look at
http://lists.freebsd.org/pipermail/freebsd-net/2011-January/027647.html
for more details.
Here is a proposed patch derived from
$src/sys/netsmb/smb_trantcp.c:nbssn_recv()'s way of handling a similar
situation:
Index: sys/kern/uipc_syscalls.c
===
--- sys/kern/uipc_syscalls.c(revision 267693)
+++ sys/kern/uipc_syscalls.c(working copy)
@@ -1755,6 +1755,12 @@
if (error != 0)
return (error);
so = fp->f_data;
+ if ((so->so_state & (SS_ISDISCONNECTED|SS_ISDISCONNECTING)) ||
+ (so->so_rcv.sb_state & SBS_CANTRCVMORE)) {
+ error = ECONNRESET;
+ goto done;
+ }
if ((so->so_state & (SS_ISCONNECTED|SS_ISCONFIRMING)) == 0) {
error = ENOTCONN;
goto done;
Does this look correct?
cheers,
Hiren
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: getpeername returning ENOTCONN for a connected socket
On Sat, Jun 21, 2014 at 9:00 AM, Sean Bruno wrote:
> On Fri, 2014-06-20 at 16:21 -0700, hiren panchasara wrote:
>> Reviving an old thread where Steve found this problem: A call to
>> getpeername on a connected tcp socket returns ENOTCONN with no prior
>> errors being reported by previous socket calls.
>>
>> Please look at
>> http://lists.freebsd.org/pipermail/freebsd-net/2011-January/027647.html
>> for more details.
>>
>> Here is a proposed patch derived from
>> $src/sys/netsmb/smb_trantcp.c:nbssn_recv()'s way of handling a similar
>> situation:
>>
>> Index: sys/kern/uipc_syscalls.c
>> ===
>> --- sys/kern/uipc_syscalls.c(revision 267693)
>> +++ sys/kern/uipc_syscalls.c(working copy)
>> @@ -1755,6 +1755,12 @@
>> if (error != 0)
>> return (error);
>> so = fp->f_data;
>> + if ((so->so_state & (SS_ISDISCONNECTED|SS_ISDISCONNECTING)) ||
>> + (so->so_rcv.sb_state & SBS_CANTRCVMORE)) {
>> + error = ECONNRESET;
>> + goto done;
>> + }
>> if ((so->so_state & (SS_ISCONNECTED|SS_ISCONFIRMING)) == 0) {
>> error = ENOTCONN;
>> goto done;
>>
>> Does this look correct?
>>
>> cheers,
>> Hiren
>
> Has this been tested in "anger" anywhere?
No. This patch is from code observation after looking at the problem.
I should at least writeup a small module to do local testing as Steve
did in original report. I'll do that and get back.
I'd appreciate if someone can point me to a better way of testing
this. (specially in "anger" ;-))
cheers,
Hiren
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Add netbw option to systat
On Wed, Jul 2, 2014 at 4:50 PM, Bryan Venteicher wrote: > Awhile back, DragonlyFlyBSD added a netbw option to systat that I've ported > to FreeBSD and found handy at various times: > >netbw Display aggregate and per-connection TCP receive and transmit > rates. Only active TCP connections are shown. > > Leading to output such as: > > tcp acceptsconnects rcv 1.192G snd 15.77K rexmit > > 192.168.10.80:22 192.168.10.20:23103 rcvsnd 415.7 [ NTSX ] > 192.168.10.80:22 192.168.10.20:46560 rcv 19.80M snd 14.47K [ NTSX ] > 192.168.10.80:22 192.168.10.20:60699 rcvsnd 886.3 [ NTSX ] > 192.168.10.81:5201192.168.10.51:60844 rcv 293.2M snd[R TSX ] > 192.168.10.81:5201192.168.10.51:60845 rcv 293.5M snd[R TSX ] > 192.168.10.81:5201192.168.10.51:60846 rcv 293.2M snd[R TSX ] > 192.168.10.81:5201192.168.10.51:60847 rcv 292.9M snd[R TSX ] > > It uses the sequences number from the 'struct tcpcb' to derive the rates, > which is usually good but certainly not perfect (i.e., don't set the > interval too long). > > I'd like to commit this if anybody else thinks they'd find it useful. > > http://people.freebsd.org/~bryanv/patches/systat-netbw.patch I like the idea. A few things about the patch: 1) You may want to remove the code hidden behind "#if 0" at 2 places. 2) I am not entirely clear on why/if we need the last column with flags but if we keep it (for compatibility of any other reason), It would be nice to have those flags explained in the manpage: + mvwprintw(wnd, LINES-2, 0, + "Rate/sec, " + "R=rxpend T=txpend N=nodelay T=tstmp " + "S=sack X=winscale F=fastrec"); 3) I feel that the header line for o/p (specially 'tcp accepts and connects' terminology) can be improved but I do not have a better suggestion :-) It looks okay me otherwise and thanks for your work. cheers, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: r256920 missing in stable/9 and releng/9.3
+ freebsd-net@, On Mon, Jul 7, 2014 at 4:37 AM, Harald Schmalzbauer wrote: > Bezüglich Jan Mikkelsen's Nachricht vom 24.06.2014 04:49 (localtime): >> Hi, >> >> I’m bringing 9.3-RC1 into our local Perforce depot and moving our local >> patches to 9.2 forward. >> >> I noticed that r256920 (changing sys/netinet/tcp_input.c) has not been >> MFC’d. It was listed as “MFC after 3 days” back in October 2013. >> >> Is this patch missing for a reason? > > I'm wondering too if there's any good reason not to MFC? I also don't see any obvious reason. If nobody objects on -net@, I can do it. cheers, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: r256920 missing in stable/9 and releng/9.3
On Thu, Jul 10, 2014 at 10:36 AM, John Baldwin wrote: > On Monday, July 07, 2014 12:58:53 pm hiren panchasara wrote: >> + freebsd-net@, >> >> On Mon, Jul 7, 2014 at 4:37 AM, Harald Schmalzbauer >> wrote: >> > Bezüglich Jan Mikkelsen's Nachricht vom 24.06.2014 04:49 (localtime): >> >> Hi, >> >> >> >> I’m bringing 9.3-RC1 into our local Perforce depot and moving our local > patches to 9.2 forward. >> >> >> >> I noticed that r256920 (changing sys/netinet/tcp_input.c) has not been > MFC’d. It was listed as “MFC after 3 days” back in October 2013. >> >> >> >> Is this patch missing for a reason? >> > >> > I'm wondering too if there's any good reason not to MFC? >> >> I also don't see any obvious reason. >> >> If nobody objects on -net@, I can do it. > > I think this looks fine to merge. Thanks John for confirming. Committed as r268506 to stable/9. It's a bit too late for 9.3-R. cheers, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Why is r250764 not in 9.3?
+ Alexander On Tue, Jul 15, 2014 at 2:32 AM, Kajetan Staszkiewicz wrote: > The time has come to upgrade my routers to FreeBSD 9.3. > > While going through list of patches I had on 9.1, I've noticed that r248070 > got > into 9.3 but r250764 did not. Why is that? Probably just missed it. cheers, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
UDP sendto() returning ENOBUFS - "No buffer space available"
Return values in sendto() manpage says: [ENOBUFS] The system was unable to allocate an internal buffer. The operation may succeed when buffers become avail- able. [ENOBUFS] The output queue for a network interface was full. This generally indicates that the interface has stopped sending, but may be caused by transient con- gestion. If I hit the first condition, it should reflect as failures in "netstat -m". Is that a correct assumption? I want to understand what happens when/if we hit the second condition. And how to prevent that from happening. Is it just application's job to rate-limit data it sends to the n/w interface card so that it doesn't saturate? Does kernel do any sort of queuing in the case of ENOBUFS? OR does the message just gets dropped? For an application sending a lot of UDP data and returning ENOBUFS, what all udp and other tunables I should tweak? I can only think of: - number of tx ring descriptors - increasing this will get us more txds. - kern.ipc.maxsockbuf: Increasing this will increase buffer size allocated for sockets. what else? Any comments/suggestions/corrections? cheers, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: UDP sendto() returning ENOBUFS - "No buffer space available"
On Wed, Jul 16, 2014 at 11:00 AM, Adrian Chadd wrote: > Hi! > > So the UDP transmit path is udp_usrreqs->pru_send() == udp_send() -> > udp_output() -> ip_output() > > udp_output() does do a M_PREPEND() which can return ENOBUFS. ip_output > can also return ENOBUFS. > > it doesn't look like the socket code (eg sosend_dgram()) is doing any > buffering - it's just copying the frame and stuffing it up to the > driver. No queuing involved before the NIC. Right. Thanks for confirming. > > So a _well behaved_ driver will return ENOBUFS _and_ not queue the > frame. However, it's entirely plausible that the driver isn't well > behaved - the intel drivers screwed up here and there with transmit > queue and failure to queue vs failure to transmit. > > So yeah, try tweaking the tx ring descriptor for the driver your'e > using and see how big a bufring it's allocating. Yes, so I am dealing with Broadcom BCM5706/BCM5708 Gigabit Ethernet, i.e. bce(4). I bumped up tx_pages from 2 (default) to 8 where each page is 255 buffer descriptors. I am seeing quite nice improvement on stable/10 where I can send *more* stuff :-) cheers, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Why is r250764 not in 9.3?
On Sat, Jul 19, 2014 at 2:26 AM, Alexander V. Chernikov wrote: > On 15.07.2014 21:03, hiren panchasara wrote: >> >> + Alexander >> >> On Tue, Jul 15, 2014 at 2:32 AM, Kajetan Staszkiewicz >> wrote: >>> >>> The time has come to upgrade my routers to FreeBSD 9.3. >>> >>> While going through list of patches I had on 9.1, I've noticed that >>> r248070 got >>> into 9.3 but r250764 did not. Why is that? >> >> Probably just missed it. > > Yes, I've missed it. > Unfortunately, I'm unable to merge it until 26July, feel free to do so if > you wish. Committed to stable/9 as r268906. cheers, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Fwd: bridge interface type
Is this the correct mailer for such questions? -- Forwarded message -- From: hiren panchasara Date: Sat, Mar 3, 2012 at 12:47 AM Subject: bridge interface type To: freebsd-hack...@freebsd.org I created bridge1 this way: $ sudo ifconfig bridge create Password: bridge1 $ ifconfig bridge1 bridge1: flags=8802 metric 0 mtu 1500 ether 02:32:c8:92:b6:01 nd6 options=29 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 0 ifcost 0 port 0 but when I try to look at the interface via "struct sockaddr_dl", sdl = (struct sockaddr_dl *) ifa->ifa_addr; sdl->sdl_type is "IFT_ETHER" for that interface. Shouldn't it be "IFT_BRIDGE"? What am I missing here? Thanks in advance, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: bridge interface type
On Sun, Mar 4, 2012 at 11:14 PM, Andrew Thompson wrote:
> Here is a patch that changes it but I do not know what may break.
>
Thanks a lot Andrew. So, someone might be relying on interface type of
bridge being IFT_ETHER?
Who can confirm if this is a good patch?
>
> Index: if_bridge.c
> ===
> --- if_bridge.c (revision 232321)
> +++ if_bridge.c (working copy)
> @@ -568,6 +568,7 @@ bridge_clone_create(struct if_clone *ifc, int unit
> {
>struct bridge_softc *sc, *sc2;
>struct ifnet *bifp, *ifp;
> + struct sockaddr_dl *sdl;
>int fb, retry;
>unsigned long hostid;
>
> @@ -642,6 +643,8 @@ bridge_clone_create(struct if_clone *ifc, int unit
>/* Now undo some of the damage... */
>ifp->if_baudrate = 0;
>ifp->if_type = IFT_BRIDGE;
> + sdl = (struct sockaddr_dl *)ifp->if_addr->ifa_addr;
> + sdl->sdl_type = IFT_BRIDGE;
>
>mtx_lock(&bridge_list_mtx);
>LIST_INSERT_HEAD(&bridge_list, sc, sc_list);
>
Appreciate your help,
Hiren
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Difference between "struct addr" and "struct addrs"
What is the difference between following 2 structs? /src/sys/net/if_var.h: struct ifaddr (from the comments seems like it contains a particular address (of probably many) information for an interface.) /src/include/ifaddrs.h: struct ifaddrs Thanks in advance, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Difference between "struct addr" and "struct addrs"
On Mon, Mar 5, 2012 at 10:57 PM, Sergey Kandaurov wrote: > struct ifaddr is the in-kernel representation of the interface address. > In kernel each network interface consists of a linked list of interface > addresses, described by ifaddr structures. > See man ifnet(9): http://man.freebsd.org/ifnet > > struct ifaddrs is used in the userland BSD API getifaddrs(3). This > interface > is used to get interface addresses in userland programs. See how it is > used in e.g. ifconfig(8) sources: /usr/src/sbin/ifconfig/ifconfig.c > See man getifaddrs(3): http://man.freebsd.org/getifaddrs > Thanks Sergey, appreciate your help. Are they connected in any way? Can I get one if I have another? Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Difference between "struct addr" and "struct addrs"
On Tue, Mar 6, 2012 at 12:03 AM, Sergey Kandaurov wrote: > On 6 March 2012 11:08, hiren panchasara > wrote: > > > > > > On Mon, Mar 5, 2012 at 10:57 PM, Sergey Kandaurov > wrote: > >> > >> struct ifaddr is the in-kernel representation of the interface address. > >> In kernel each network interface consists of a linked list of interface > >> addresses, described by ifaddr structures. > >> See man ifnet(9): http://man.freebsd.org/ifnet > >> > >> struct ifaddrs is used in the userland BSD API getifaddrs(3). This > >> interface > >> is used to get interface addresses in userland programs. See how it is > >> used in e.g. ifconfig(8) sources: /usr/src/sbin/ifconfig/ifconfig.c > >> See man getifaddrs(3): http://man.freebsd.org/getifaddrs > > > > Thanks Sergey, appreciate your help. > > > > Are they connected in any way? Can I get one if I have another? > > Well, not strictly. > getifaddrs() collects addresses on all network interfaces using > sysctl interface to the routine table with NET_RT_IFLIST[L] argument. > NET_RT_IFLIST[L] does what you would expect: it runs through the linked > list of network interfaces and gathers all struct ifaddr on each of them. > You can see how that works in /usr/src/sys/net/rtsock.c:sysctl_iflist(). > See also man sysctl(3) w.r.t. NET_RT_IFLIST / NET_RT_IFLISTL. > Thanks a bunch, Sergey! This is *exactly* what I was looking for. :-) Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Network Interface configuration
Do we store network interfaces configuration information in any file that survives reboots? (as Linux does it in /etc/network/interfaces) Only thing I could find was when an interface needs address from DHCP, rc.conf says ifconfig_em0="DHCP". I know getifaddrs() can get you list of interfaces but I wanted to know if there is any such file. Thanks, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Network Interface configuration
On Wed, Mar 7, 2012 at 12:08 AM, Damien Fleuriot wrote: > > In /etc/rc.conf > > See the man page for rc.conf for a more detailed use. > See the small example bellow: > > ifconfig_re0="inet 192.168.0.30/24 up" > defaultrouter="192.168.0.254" > > These are the very basics ;) > Thanks Damien. I looked at the man page. I did "ifconfig" on my box and found an interface named fwe0. I do not see any entry for that in any /etc/rc.conf or /etc/defaults/rc.conf Where is that coming from? Am I missing anything? Appreciate your help, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Network Interface configuration
On Wed, Mar 7, 2012 at 12:49 AM, Juli Mallett wrote: > In general, interfaces do > not come from the configuration files like rc.conf, however the way > that those interfaces are set up on boot is configured by files like > rc.conf. > Thanks Juli. So, does it mean that looking at getifaddrs() is the best way (as ifconfig is doing) to get the correct state of network interfaces at any point in time? And for the interface of your interest, you can check if rc.conf is specifying any persistent configuration or not. Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Use of network_interfaces in rc.conf
Looking at man rc.conf, network_interfaces (str) Set to the list of network interfaces to configure on this host or “AUTO” (the default) for all current interfaces. Setting the network_interfaces variable to anything other than the default is deprecated. Interfaces that the adminis‐ trator wishes to store configuration for, but not start at boot should be configured with the “NOAUTO” keyword in their ifconfig_⟨interface⟩ variables as described below. For example, in my rc.conf I have ifconfig_em0="dhcp" What difference does it make when I have each (separately) in my rc.conf: 1) no network_interfaces at all 2) network_interfaces="AUTO" 3) network_interfaces="em0" 4) network_interfaces="NOAUTO" It seems, all but 2 are deprecated. Thanks in advance, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Use of network_interfaces in rc.conf
Can someone please help? :-) On Mar 12, 2012 9:04 AM, "hiren panchasara" wrote: > Looking at man rc.conf, > > network_interfaces > (str) Set to the list of network interfaces to configure > on > this host or “AUTO” (the default) for all current > interfaces. > Setting the network_interfaces variable to anything other > than the default is deprecated. Interfaces that the > adminis‐ > trator wishes to store configuration for, but not start at > boot should be configured with the “NOAUTO” keyword in > their > ifconfig_⟨interface⟩ variables as described below. > > For example, in my rc.conf I have > > ifconfig_em0="dhcp" > > What difference does it make when I have each (separately) in my rc.conf: > > 1) no network_interfaces at all > 2) network_interfaces="AUTO" > 3) network_interfaces="em0" > 4) network_interfaces="NOAUTO" > > It seems, all but 2 are deprecated. > > Thanks in advance, > Hiren > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Use of network_interfaces in rc.conf
Thanks Chuck for getting back. I have a question inlined: On Tue, Mar 13, 2012 at 10:32 PM, Chuck Swiger wrote: > On Mar 13, 2012, at 10:18 PM, hiren panchasara wrote: > >> What difference does it make when I have each (separately) in my > rc.conf: > >> > >> 1) no network_interfaces at all > >> 2) network_interfaces="AUTO" > > These two are the same. > Okay. So, if my system has 4 interfaces: em0, iwn0, fwp0, wlan0 Does the above mean following? ifconfig_em0="AUTO" ifconfig_iwn0="AUTO" ifconfig_fwp0="AUTO" ifconfig_wlan0="AUTO" Also, if we say an interface is auto configured, it needs some sort of configuration to "auto-configure" it with, right? i.e. for em0 something like: ifconfig_em0="DHCP" Thanks, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Use of network_interfaces in rc.conf
On Wed, Mar 14, 2012 at 4:19 AM, Eugene Grosbein wrote: > 14.03.2012 13:19, hiren panchasara пишет: > > Thanks Chuck for getting back. I have a question inlined: > > > > On Tue, Mar 13, 2012 at 10:32 PM, Chuck Swiger wrote: > > > >> On Mar 13, 2012, at 10:18 PM, hiren panchasara wrote: > >>>> What difference does it make when I have each (separately) in my > >> rc.conf: > >>>> > >>>> 1) no network_interfaces at all > >>>> 2) network_interfaces="AUTO" > >> > >> These two are the same. > >> > > Okay. So, if my system has 4 interfaces: em0, iwn0, fwp0, wlan0 > > > > Does the above mean following? > > > > ifconfig_em0="AUTO" > > ifconfig_iwn0="AUTO" > > ifconfig_fwp0="AUTO" > > ifconfig_wlan0="AUTO" > > No. > > network_interfaces is basically historic rudiment > used in 2.2.x FreeBSD version and alike. > > In general, you should not use it in modern version at all. > Thanks Eugene. So, the only way to specify boottime configuration (that survives reboots) for an interface in rc.conf is: ifconfig_em0="dhcp" ? Thanks, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Why wpa_supplicant doesn't start with ndis0 interface?
On Fri, Sep 14, 2012 at 11:32 AM, Yuri wrote: > On 09/14/2012 10:54, Glen Barber wrote: > >> Ok. Thanks for letting us know. >> > > Now wpa_supplicant starts and is operational, however '/etc/rc.d/netif > start' always issues this warning: > Starting wpa_supplicant > /etc/rc.d/wpa_supplicant: WARNING: failed to start wpa_supplicant > Starting Network: lo0 ndis0 re0. > > Also (as a result) dhclient isn't started, but succeeds when started > manually. > wpa_supplicant started by hand doesn't print any errors. > > I can't find any option in wpa_supplicant.conf making it to write a log > what is wrong. On linux it seems to be -f option for the log file. > Any way to make netif more verbose? Not sure if you looked at - man wpa_supplicant, which has -d for debugging -s for pumping messages to syslog Thanks, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: A problem on TCP in High RTT Environment.
On Sat, Aug 9, 2014 at 12:51 PM, Michael Tuexen wrote: > > On 09 Aug 2014, at 20:42, John-Mark Gurney wrote: > >> Niu Zhixiong wrote this message on Fri, Aug 08, 2014 at 20:34 +0800: >>> Dear all, >>> >>> Last month, I send problems related to FTP/TCP in a high RTT environment. >>> After that, I setup a simulation environment(Dummynet) to test TCP and SCTP >>> in high delay environment. After finishing the test, I can see TCP is >>> always slower than SCTP. But, I think it is not possible. (Plz see the >>> figure in the attachment). When the delay is 200ms(means RTT=400ms). >>> Besides, the TCP is extremely slow. >>> >>> ALL BW=20Mbps, DELAY= 0 ~ 200MS, Packet LOSS = 0 (by dummynet) >>> >>> This is my parameters: >>> FreeBSD vfreetest0 10.0-RELEASE FreeBSD 10.0-RELEASE #0: Thu Aug 7 >>> 11:04:15 HKT 2014 >>> >>> sysctl net.inet.tcp >> >> [...] >> >>> net.inet.tcp.recvbuf_auto: 0 >> >> [...] >> >>> net.inet.tcp.sendbuf_auto: 0 >> >> Try enabling this... This should allow the buffer to grow large enough >> to deal w/ the higher latency... >> >> Also, make sure your program isn't setting the recv buffer size as that >> will disable the auto growing... > I think the program sets the buffer to 2MB, which it also does for SCTP. > So having both statically at the same size makes sense for the comparison. > I remember that there was a bug in the combination of LRO and delayed ACK, > which was fixed, but I don't remember it was fixed before 10.0... If you are thinking of r256920, I believe it did make it into 10.0R. cheers, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: TCP Rx window auto sizing relies on TCP timestamp option?
On Mon, Aug 11, 2014 at 5:16 AM, Vlad Zolotarov wrote: > Hi, I have the most strange question about the TCP Rx window auto sizing > implementation in a FreeBSD networking stack. > When I looked at the FreeBSD code (hash > 9abce0e567c9a5a0520cdd94d5c633c7baf9a184) I noticed that > the mentioned above feature will not be "enabled" if there isn't a TCP > timestamp option present in the current TCP session: > > See sys/netinet/tcp_input.c: line 1813 in tcp_do_segment() function: > > if (V_tcp_do_autorcvbuf && > *to.to_tsecr* && < this is what I'm > talking about > (so->so_rcv.sb_flags & SB_AUTOSIZE)) > > So, if i read the code correctly, if there isn't a TS option (negotiated and > thus present in every received packet) the receive socket buffer won't grow > thus preventing the growth of the Rx window. > If that's the case this is very strange since TS option is not promised and > even more - in many cases it won't be present. > For example in Linux this feature is disabled by default (controlled by > /proc/sys/net/ipv4/tcp_timestamps). > This is how I actually noticed the problem the first place: I ran iperf test > where Linux was an initiator and a transmitter (iperf -c) FreeBSD box was a > receiver (iperf -s) and I noticed that the Rx window wasn't opening up > because Linux box hasn't negotiated the TS option in the SYN. As a result, > the throughput numbers were significantly lower compared to Linux-to-Linux > setup (Linux uses a Dynamic Right-Sizing (DRS) algorithm > http://public.lanl.gov/radiant/pubs.html#DRS, which doesn't rely on TS). > > Could anybody comment on this, pls.? > Did I miss anything? > Is it true that FreeBSD assumes that TS option is always present and if not > how can I cause an Rx Window to open up when TS option hasn't been > negotiated? In my limited understanding, we (FreeBSD) want to base Rx window size increase on accurate RTT which is not possible if TS option is not negotiated. And that's why this requirement. Do you know how does it work in Linux? cheers, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: A problem on TCP in High RTT Environment.
On Mon, Aug 11, 2014 at 12:59 PM, Michael Tuexen wrote: > On 11 Aug 2014, at 21:40, Eggert, Lars wrote: > >> Hi, >> >> On 2014-8-11, at 21:27, Michael Tuexen >> wrote: >>> On 11 Aug 2014, at 14:12, Eggert, Lars wrote: 544/57/8194 requests for mbufs denied (mbufs/clusters/mbuf+clusters) >>> I guess the above is the problem. The card wants a lot of mbufs... >>> So the problem should go away if you increase the number of mbufs/clusters, >>> which means no requests are denied and you don't experience any performance >>> issue. >> >> And I have six of those ports in that box... >> >> So I bump kern.ipc.nmbclusters? Any additional sysctls I should bump? > If I remember correctly, I increased > kern.ipc.nmbufs and kern.ipc.nmbclusters in /boot/loader.conf I believe, you just need to set kern.ipc.nmbclusters (max mbuf clusters allowed) and kern.ipc.nmbufs (max mbufs allowed) should be adjusted based on that. cheers, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: zero window and persist timer not set
On Mon, Aug 11, 2014 at 2:20 PM, John Baldwin wrote: > On Wednesday, August 06, 2014 5:25:38 pm Jeremiah Lott wrote: >> Hello, >> >> We've been seeing a problem where a tcp connection is stuck in a zero >> window condition and even though the client has opened more window space, >> our FreeBSD box never sends any more. After some analysis it appears that >> the FreeBSD box is not sending zero window probes, because the persist >> timer did not get set (we can see in kgdb that the tcpcb shows 0 window, >> there is data in the socket buffer, but the persist timer is not active). >> >> After looking over the code for a while, I think I see the problem. When >> tcp_output chooses to send a packet, it never arms the persist timer. This >> causes a problem in the following scenario: >> >> 1. A --> B: packet containing enough data to fill the window >> 2. B --> A: ACK for #1 + new data (0 window advertisement) >> 3. A --> B: ACK for #2, 0 len packet >> >> In this case, A will not activate the persist timer, because it chose to >> send a packet. Unless tcp_output is called for some other reason (delayed >> ack timer, another input packet from B, socket syscall), A will not send >> zero window probes. I was finally able to recreate this condition by >> setting an very small window and running programs that send very specific >> sequences of packets without calling recv (purposefully forcing a zero >> window condition). Here is a packet capture that shows the sequence: >> >> A == 10.2.15.69 == FreeBSD 9.2 >> B == 10.2.14.61 == FreeBSD 8.2 >> >> 16:19:49.664790 IP 10.2.14.61.23133 > 10.2.15.69.12345: Flags [S], seq >> 2362665163, win 4300, options [mss 1460,nop,wscale 6,sackOK,TS val 88804503 >> ecr 0], length 0 >> 16:19:49.664821 IP 10.2.15.69.12345 > 10.2.14.61.23133: Flags [S.], seq >> 3306387947, ack 2362665164, win 65535, options [mss 1460,nop,wscale >> 6,sackOK,TS val 1605043666 ecr 88804503], length 0 >> 16:19:49.664859 IP 10.2.14.61.23133 > 10.2.15.69.12345: Flags [.], ack 1, >> win 67, options [nop,nop,TS val 88804503 ecr 1605043666], length 0 >> 16:19:49.664921 IP 10.2.14.61.23133 > 10.2.15.69.12345: Flags [P.], seq >> 1:101, ack 1, win 67, options [nop,nop,TS val 88804503 ecr 1605043666], >> length 100 >> 16:19:49.665137 IP 10.2.15.69.12345 > 10.2.14.61.23133: Flags [P.], seq >> 1:3001, ack 101, win 2046, options [nop,nop,TS val 1605043666 ecr >> 88804503], length 3000 >> 16:19:49.665208 IP 10.2.14.61.23133 > 10.2.15.69.12345: Flags [P.], seq >> 101:1321, ack 1449, win 45, options [nop,nop,TS val 88804503 ecr >> 1605043666], length 1220 >> 16:19:49.666195 IP 10.2.14.61.23133 > 10.2.15.69.12345: Flags [.], seq >> 1321:2769, ack 3001, win 21, options [nop,nop,TS val 88804504 ecr >> 1605043666], length 1448 >> 16:19:49.666205 IP 10.2.15.69.12345 > 10.2.14.61.23133: Flags [.], ack >> 2769, win 2004, options [nop,nop,TS val 1605043667 ecr 88804503], length 0 >> 16:19:49.666207 IP 10.2.14.61.23133 > 10.2.15.69.12345: Flags [P.], seq >> 2769:2771, ack 3001, win 21, options [nop,nop,TS val 88804504 ecr >> 1605043666], length 2 >> 16:19:49.667183 IP 10.2.14.61.23133 > 10.2.15.69.12345: Flags [.], seq >> 2771:4219, ack 3001, win 21, options [nop,nop,TS val 88804505 ecr >> 1605043667], length 1448 >> 16:19:49.667190 IP 10.2.15.69.12345 > 10.2.14.61.23133: Flags [.], seq >> 3001:4345, ack 4219, win 1982, options [nop,nop,TS val 1605043668 ecr >> 88804504], length 1344 >> 16:19:49.667193 IP 10.2.14.61.23133 > 10.2.15.69.12345: Flags [P.], seq >> 4219:4221, ack 3001, win 21, options [nop,nop,TS val 88804505 ecr >> 1605043667], length 2 >> 16:19:49.766487 IP 10.2.14.61.23133 > 10.2.15.69.12345: Flags [P.], seq >> 4221:4321, ack 4345, win 0, options [nop,nop,TS val 88804605 ecr >> 1605043668], length 100 >> 16:19:49.766499 IP 10.2.15.69.12345 > 10.2.14.61.23133: Flags [.], ack >> 4321, win 1980, options [nop,nop,TS val 1605043768 ecr 88804505], length 0 >> >> The important packets are the last four: >> >> 1. A --> B: length 1344, fills the remaining window >> 2. B --> A: length 2, does not ack additional data, delayed ack timer is set >> 3. B --> A: length 100, acks #1, immediate ack (delayed ack timer >> cancelled, tcp_output called with ACKNOW) >> 4. A --> B: length 0, acks #1 and #2, because a packet is sent tcp_output >> does not activate the persist timer. >> >> I would normally expect A to begin sending zero-window probes, but (since >> it didn't activate the persist timer) it does not. Using kgdb, I can see >> that the persist timer is not set, only the keep timer is set. This is >> kgdb on "A": >> >> (kgdb) print ((struct tcpcb*)(0xfe02ae289b70))->snd_nxt >> $5 = 3306392292 >> (kgdb) print ((struct tcpcb*)(0xfe02ae289b70))->snd_max >> $6 = 3306392292 >> (kgdb) print ((struct tcpcb*)(0xfe02ae289b70))->snd_una >> $7 = 3306392292 >> (kgdb) print ((struct tcpcb*)(0xfe02ae289b70))->snd_wnd >> $8 = 0 >> (kgdb) print ((struct tcpcb*)(0xfe02ae289b70))->snd_cwnd >> $9 = 4380 >> (kgdb) pri
Regression test suite for TCP
I was looking for one and found https://wiki.freebsd.org/SummerOfCode2008#TCP.2FIP_regression_test_suite_.28tcptest.29 which is a good start but needs a lot of love (work). Please share if you are aware of any covering basic scenarios. cheers, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: SPAN port doesn't pick up locally generated traffic
On Tue, Aug 12, 2014 at 7:27 PM, Joseph Ward wrote: > I found a workaround that is acceptable. > > First, I want to thank Hiren Panchasara for recommending the work-around > that I hadn't thought about trying. > > For the archives and anyone struggling with the same issue: > > I altered the setup below by giving the LAN IP to the wired interface re1 as > opposed to bridge0. Doing that magically made the span port (re2) get all > the traffic, both passing through in re1 and out ath0 (and vice versa) as > well as the packets that originate inside the system and are passed to the > bridge. > > This isn't ideal as it means that if the physical interface re1 goes down, > clients on ath0 will lose connectivity to the system, and I had always > understood that when bridging it's ideal to give the IPs to the bridge > itself to protect against that possibility. However, I can give each > interface another IP on a different subnet that will at least allow for > remote connectivity in that scenario. > > Does anyone know if this is known/expected behavior? If no one knows I'll > file a bug ticket on the scenario as it certainly doesn't seem kosher to me. I am not sure if this one case of "packets originating from one of the bridge members not showing up on the bridge's span port" is the only one not getting handled correctly or there is more to it. Please file a bug with your testing scenarios and all the details. CC me on the bug and I'll try to take a look. cheers, Hiren [skip] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Regression test suite for TCP
On Mon, Aug 18, 2014 at 4:59 PM, Anuranjan Shukla wrote: > If you're willing to shell out some $$, Ixia's ANVL is a fairly detailed > test suite for TCP and other protocols. It's available as a software you > can install on lnx/windows. I'd used it at Juniper while working with > Robert for the connection groups work a couple years or so back. Thanks Anu. It looks pretty good but I am looking for something more on open source side. cheers, Hiren > > Regards, > -Anu > > On 8/11/14, 5:07 PM, "hiren panchasara" wrote: > >>I was looking for one and found >>https://wiki.freebsd.org/SummerOfCode2008#TCP.2FIP_regression_test_suite_. >>28tcptest.29 >>which is a good start but needs a lot of love (work). >> >>Please share if you are aware of any covering basic scenarios. >> >>cheers, >>Hiren >>___ >>freebsd-net@freebsd.org mailing list >>http://lists.freebsd.org/mailman/listinfo/freebsd-net >>To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: igb "requests for mbufs denied"
On Thu, Aug 28, 2014 at 4:27 AM, Eggert, Lars wrote: > On 2014-8-28, at 10:31, Eggert, Lars wrote: >> 73/3831/3091 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > > I just noticed that these are already there just after boot, and then also > don't seem to be increasing anymore (or only very slowly.) Just in case that > gives someone an idea. > Very weird. I guess a hackish way is to try removing cards or disabling interfaces one by one and see how it changes the behavior on boot? cheers, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Multipath TCP for FreeBSD v0.4
On Tue, Sep 16, 2014 at 3:48 PM, Sean Bruno wrote: > On Mon, 2014-09-08 at 11:32 +1000, Nigel Williams wrote: >> Hi, >> >> We recently released a new tech report "Design Overview of Multipath TCP >> version 0.4 for FreeBSD-11" [1]. The report provides some details on >> various aspects of the implementation (session management, data-level >> retransmission etc), as of the most recent v0.4 patch [2]. >> >> cheers, >> nigel >> >> [1] http://caia.swin.edu.au/reports/140822A/CAIA-TR-140822A.pdf >> [2] http://caia.swin.edu.au/urp/newtcp/mptcp/tools.html >> > > > Nigel: > > Hi! Are you folks interested in having this patchset incorporated into > the main line of FreeBSD? I'm open to putting up a phabricator review > for you folks at https://reviews.freebsd.org if that's something you > guys want to do? > > sean > Sean, We should not move it to phabricator as contributors without freebsd.org email address (like the patch author himself and patch tester Nils) would not be able to comment on the review as phabricator is still read-only for them. my 2 cents. cheers, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
igb update - 2.4.0 -> 2.4.2
Jack/ Eric, When do you guys plan to bring this in the tree? https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=15815 cheers, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [jci...@ulb.ac.be: Listen queue overflow: 8 already in queue awaiting acceptance]
On Thu, Oct 2, 2014 at 9:42 AM, Julien Cigar wrote:
> sorry for cross-posting, I'm forwarding this as it seems that part of
> the problem is also related to:
> https://lists.freebsd.org/pipermail/freebsd-net/2014-September/039664.html
Umm, this looks like a different problem than the subject of this email.
>
> I also wonder if something has been fixed in -STABLE in this area ..
>
> (please keep me in CC as I'm not subscribed on freebsd-net@ an
> freebsd-stable@)
>
> --
> Julien Cigar
> Belgian Biodiversity Platform (http://www.biodiversity.be)
> PGP fingerprint: EEF9 F697 4B68 D275 7B11 6A25 B2BB 3710 A204 23C0
> No trees were killed in the creation of this message.
> However, many electrons were terribly inconvenienced.
>
>
> -- Forwarded message --
> From: Julien Cigar
> To: freebsd-questi...@freebsd.org
> Cc:
> Date: Thu, 2 Oct 2014 11:52:06 +0200
> Subject: Listen queue overflow: 8 already in queue awaiting acceptance
> Hello,
>
> I'm running 10-RELEASE on a HP Proliant DL160 Gen8 and I'm seeing the
> following in my kernel logs:
> sonewconn: pcb 0xf8010e561310: Listen queue overflow: 8 already in
> queue awaiting acceptance
This usually means the application is not keeping up with the incoming
connections.
>
> I already raised kern.ipc.soacceptqueue to 1024 and netstat -naA | grep
> "f8010e561310" returns nothing
This is the usual way of finding the culprit process. If this doesn't
return anything, it probably means that it is a short-lived process.
Here is an example of what you could do:
sonewconn: pcb 0xf8008f40cb10: Listen queue overflow: 1 already in queue
awaiting acceptance
>From kgdb,
(kgdb) p ((struct inpcb *)0xf8008f40cb10)->inp_inc
$3 = {inc_flags = 0 '\0', inc_len = 0 '\0', inc_fibnum = 0, inc_ie = {ie_fport
= 0, ie_lport = 10295, ie_dependfaddr = {
ie46_foreign = {ia46_pad32 = {0, 0, 0}, ia46_addr4 = {s_addr = 0}},
ie6_foreign = {__u6_addr = {
__u6_addr8 = '\0' , __u6_addr16 = {0, 0, 0, 0, 0,
0, 0, 0}, __u6_addr32 = {0, 0, 0, 0,
ie_dependladdr = {ie46_local = {ia46_pad32 = {0, 0, 0}, ia46_addr4 =
{s_addr = 0}}, ie6_local = {__u6_addr = {
__u6_addr8 = '\0' , __u6_addr16 = {0, 0, 0, 0, 0,
0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}
Here, ie_lport = 10295 which is in n/w byte order and converting it to host
byte order, 10295 -> 0x2837 and swapping them gives us 0x3728 which is 14120.
Now, use sockstat to find out what process is on that port:
$ sockstat -l | grep 14120
cheers,
Hiren
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [jci...@ulb.ac.be: Listen queue overflow: 8 already in queue awaiting acceptance]
On Thu, Oct 2, 2014 at 11:19 AM, Julien Cigar wrote:
> On Thu, Oct 02, 2014 at 10:24:13AM -0700, hiren panchasara wrote:
>> On Thu, Oct 2, 2014 at 9:42 AM, Julien Cigar wrote:
>> > sorry for cross-posting, I'm forwarding this as it seems that part of
>> > the problem is also related to:
>> > https://lists.freebsd.org/pipermail/freebsd-net/2014-September/039664.html
>>
>> Umm, this looks like a different problem than the subject of this email.
>
> yes and no, seems the same hardware (HP and igb) and I have also some
> "requests for mbufs denied" (https://dpaste.de/t8kJ/raw) without any
> reasons. I should add that the box hanged a week ago and I had to do a
> hard reboot, I have the feeling that it's somewhat related to this
> problem ..
>
I suggest you try to debug these 2 problems separately. Did you get a
chance to look at kgdb to find the culprit process as I suggested
below?
cheers,
Hiren
>> >
>> > I also wonder if something has been fixed in -STABLE in this area ..
>> >
>> > (please keep me in CC as I'm not subscribed on freebsd-net@ an
>> > freebsd-stable@)
>> >
>> > --
>> > Julien Cigar
>> > Belgian Biodiversity Platform (http://www.biodiversity.be)
>> > PGP fingerprint: EEF9 F697 4B68 D275 7B11 6A25 B2BB 3710 A204 23C0
>> > No trees were killed in the creation of this message.
>> > However, many electrons were terribly inconvenienced.
>> >
>> >
>> > -- Forwarded message --
>> > From: Julien Cigar
>> > To: freebsd-questi...@freebsd.org
>> > Cc:
>> > Date: Thu, 2 Oct 2014 11:52:06 +0200
>> > Subject: Listen queue overflow: 8 already in queue awaiting acceptance
>> > Hello,
>> >
>> > I'm running 10-RELEASE on a HP Proliant DL160 Gen8 and I'm seeing the
>> > following in my kernel logs:
>> > sonewconn: pcb 0xf8010e561310: Listen queue overflow: 8 already in
>> > queue awaiting acceptance
>>
>> This usually means the application is not keeping up with the incoming
>> connections.
>> >
>> > I already raised kern.ipc.soacceptqueue to 1024 and netstat -naA | grep
>> > "f8010e561310" returns nothing
>>
>> This is the usual way of finding the culprit process. If this doesn't
>> return anything, it probably means that it is a short-lived process.
>>
>> Here is an example of what you could do:
>>
>> sonewconn: pcb 0xf8008f40cb10: Listen queue overflow: 1 already in queue
>> awaiting acceptance
>>
>> From kgdb,
>> (kgdb) p ((struct inpcb *)0xf8008f40cb10)->inp_inc
>> $3 = {inc_flags = 0 '\0', inc_len = 0 '\0', inc_fibnum = 0, inc_ie =
>> {ie_fport
>> = 0, ie_lport = 10295, ie_dependfaddr = {
>> ie46_foreign = {ia46_pad32 = {0, 0, 0}, ia46_addr4 = {s_addr = 0}},
>> ie6_foreign = {__u6_addr = {
>> __u6_addr8 = '\0' , __u6_addr16 = {0, 0, 0, 0, 0,
>> 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0,
>> ie_dependladdr = {ie46_local = {ia46_pad32 = {0, 0, 0}, ia46_addr4 =
>> {s_addr = 0}}, ie6_local = {__u6_addr = {
>> __u6_addr8 = '\0' , __u6_addr16 = {0, 0, 0, 0, 0,
>> 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}
>>
>> Here, ie_lport = 10295 which is in n/w byte order and converting it to host
>> byte order, 10295 -> 0x2837 and swapping them gives us 0x3728 which is 14120.
>>
>> Now, use sockstat to find out what process is on that port:
>>
>> $ sockstat -l | grep 14120
>>
>> cheers,
>> Hiren
>
> --
> Julien Cigar
> Belgian Biodiversity Platform (http://www.biodiversity.be)
> PGP fingerprint: EEF9 F697 4B68 D275 7B11 6A25 B2BB 3710 A204 23C0
> No trees were killed in the creation of this message.
> However, many electrons were terribly inconvenienced.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [jci...@ulb.ac.be: Listen queue overflow: 8 already in queue awaiting acceptance]
On Fri, Oct 3, 2014 at 1:01 AM, Julien Cigar wrote:
> On Thu, Oct 02, 2014 at 04:36:49PM -0700, hiren panchasara wrote:
>> On Thu, Oct 2, 2014 at 11:19 AM, Julien Cigar wrote:
>> > On Thu, Oct 02, 2014 at 10:24:13AM -0700, hiren panchasara wrote:
>> >> On Thu, Oct 2, 2014 at 9:42 AM, Julien Cigar wrote:
>> >> > sorry for cross-posting, I'm forwarding this as it seems that part of
>> >> > the problem is also related to:
>> >> > https://lists.freebsd.org/pipermail/freebsd-net/2014-September/039664.html
>> >>
>> >> Umm, this looks like a different problem than the subject of this email.
>> >
>> > yes and no, seems the same hardware (HP and igb) and I have also some
>> > "requests for mbufs denied" (https://dpaste.de/t8kJ/raw) without any
>> > reasons. I should add that the box hanged a week ago and I had to do a
>> > hard reboot, I have the feeling that it's somewhat related to this
>> > problem ..
>> >
>> I suggest you try to debug these 2 problems separately. Did you get a
>> chance to look at kgdb to find the culprit process as I suggested
>> below?
>
> I tried what you suggested, but I get a "No struct type named inpcb"
> Any idea ? :)
Is your kernel not build with debug symbols? Can you share your kernconf?
I have following in my kernconf:
makeoptions DEBUG=-g
options KDB
options KDB_TRACE
options DDB
cheers,
Hiren
>>
>> cheers,
>> Hiren
>> >> >
>> >> > I also wonder if something has been fixed in -STABLE in this area ..
>> >> >
>> >> > (please keep me in CC as I'm not subscribed on freebsd-net@ an
>> >> > freebsd-stable@)
>> >> >
>> >> > --
>> >> > Julien Cigar
>> >> > Belgian Biodiversity Platform (http://www.biodiversity.be)
>> >> > PGP fingerprint: EEF9 F697 4B68 D275 7B11 6A25 B2BB 3710 A204 23C0
>> >> > No trees were killed in the creation of this message.
>> >> > However, many electrons were terribly inconvenienced.
>> >> >
>> >> >
>> >> > -- Forwarded message --
>> >> > From: Julien Cigar
>> >> > To: freebsd-questi...@freebsd.org
>> >> > Cc:
>> >> > Date: Thu, 2 Oct 2014 11:52:06 +0200
>> >> > Subject: Listen queue overflow: 8 already in queue awaiting acceptance
>> >> > Hello,
>> >> >
>> >> > I'm running 10-RELEASE on a HP Proliant DL160 Gen8 and I'm seeing the
>> >> > following in my kernel logs:
>> >> > sonewconn: pcb 0xf8010e561310: Listen queue overflow: 8 already in
>> >> > queue awaiting acceptance
>> >>
>> >> This usually means the application is not keeping up with the incoming
>> >> connections.
>> >> >
>> >> > I already raised kern.ipc.soacceptqueue to 1024 and netstat -naA | grep
>> >> > "f8010e561310" returns nothing
>> >>
>> >> This is the usual way of finding the culprit process. If this doesn't
>> >> return anything, it probably means that it is a short-lived process.
>> >>
>> >> Here is an example of what you could do:
>> >>
>> >> sonewconn: pcb 0xf8008f40cb10: Listen queue overflow: 1 already in
>> >> queue
>> >> awaiting acceptance
>> >>
>> >> From kgdb,
>> >> (kgdb) p ((struct inpcb *)0xf8008f40cb10)->inp_inc
>> >> $3 = {inc_flags = 0 '\0', inc_len = 0 '\0', inc_fibnum = 0, inc_ie =
>> >> {ie_fport
>> >> = 0, ie_lport = 10295, ie_dependfaddr = {
>> >> ie46_foreign = {ia46_pad32 = {0, 0, 0}, ia46_addr4 = {s_addr = 0}},
>> >> ie6_foreign = {__u6_addr = {
>> >> __u6_addr8 = '\0' , __u6_addr16 = {0, 0, 0,
>> >> 0, 0,
>> >> 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0,
>> >> ie_dependladdr = {ie46_local = {ia46_pad32 = {0, 0, 0}, ia46_addr4 =
>> >> {s_addr = 0}}, ie6_local = {__u6_addr = {
>> >> __u6_addr8 = '\0' , __u6_addr16 = {0, 0, 0,
>> >> 0, 0,
>> >> 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}
>> >>
>> >> Here, ie_lport = 10295 which is in n/w byte order and converting it to
>> >> host
>> >> byte order, 10295 -> 0x2837 and swapping them gives us 0x3728 which is
>> >> 14120.
>> >>
>> >> Now, use sockstat to find out what process is on that port:
>> >>
>> >> $ sockstat -l | grep 14120
>> >>
>> >> cheers,
>> >> Hiren
>> >
>> > --
>> > Julien Cigar
>> > Belgian Biodiversity Platform (http://www.biodiversity.be)
>> > PGP fingerprint: EEF9 F697 4B68 D275 7B11 6A25 B2BB 3710 A204 23C0
>> > No trees were killed in the creation of this message.
>> > However, many electrons were terribly inconvenienced.
>
> --
> Julien Cigar
> Belgian Biodiversity Platform (http://www.biodiversity.be)
> PGP fingerprint: EEF9 F697 4B68 D275 7B11 6A25 B2BB 3710 A204 23C0
> No trees were killed in the creation of this message.
> However, many electrons were terribly inconvenienced.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: FreeBSD && TCP stealth
I am not aware of any work but adding -net to get more "networking" eyeballs. On Mon, Oct 20, 2014 at 1:23 AM, Matthias Apitz wrote: > El día Monday, October 20, 2014 a las 09:25:28AM +0200, Matthias Apitz > escribió: > >> >> Hello, >> >> Is there any work started or in progress to implement TCP stealth in our >> kernel as proposed to IETF in >> >> https://datatracker.ietf.org/doc/draft-kirsch-ietf-tcp-stealth/ >> >> The idea is that the client put some magic value in the ISN of the first >> SYN pkg which is derived from a secret the client and the server share. >> The server can check the ISN and decide if it will answer the SYN pkg or >> do a RST, for example. > > For Linux wip see also: https://gnunet.org/knock > > matthias > -- > Matthias Apitz | /"\ ASCII Ribbon Campaign: > E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail > WWW: http://www.unixarea.de/ | X- No proprietary attachments > phone: +49-170-4527211 | / \ - Respect for open standards > | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign > ___ > freebsd-curr...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Media types in ifconfig
On Mon, Oct 20, 2014 at 4:53 PM, Eric Joyner wrote: > So, what are the two fields on the media line for? > > AFAICT, it looks like the first field is the media the user wants to use > (so the driver typically sets it to Ethernet autoselect by default?), and > the > second field is for the media that's active in the interface. Aren't those "type" and "subtype"? sys/net/if_media.h has more info. cheers, Hiren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: ntpd bind() failure: Can't assign requested address
I see this message on july 2014 time-frame -CURRENT. I tried to disable IPv6 in rc.conf via ipv6_activate_all_interfaces="NO" without success. Has this been fixed? Or any workarounds? ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
