Hello Friends,
On fresh installed FreeBSD 10.0-Release, there is an error on building
netmap from ports:
root@test01:/usr/ports/net/netmap # *make install clean*
===> Building for netmap-0.1.3_1
gmake[1]: Entering directory `/usr/ports/net/netmap/work/netmap-0.1.3'
gmake -C belgolib
gmake[2]: En
./pkt-gen -i eth1 -f rx -X
the print info shows slot->len is 2048? why?
the packets was sended with tcpreplay.
when Multiple packets len is 1514, pkt-gen receive avial >1, the slot->len is
2048
like this:
[2213]:slotlen[1514],curidx[189],bufidx[24767],avail[3],iwhile[475],ifor[16],buf_ofs[5603
On 19.03.2014, at 20:17, Christopher Forgeron wrote:
> Hello,
>
>
>
> I can report this problem as well on 10.0-RELEASE.
>
>
>
> I think it's the same as kern/183390?
Possible. We still see this on nfsclients only, but I’m not convinced that nfs
is the only trigger.
> I have two physic
what os, device driver ?
are you using emulated or native netmap mode ?
Do you have tso and receive side coalescing enabled ?
(you can disable them with ethtool).
cheers
luigi
On Thu, Mar 20, 2014 at 11:03 AM, mstian88 wrote:
> ./pkt-gen -i eth1 -f rx -X
> the print info shows slot->len is 20
I recently put a new server running 9.2 (with a local patches for NFS)
into production, and it's immediately started to fail in an odd way.
Since I pounded this server pretty heavily and never saw the error in
testing, I'm more than a little bit taken aback. We have identical
hardware in productio
turn off TSO
the problems sound similar to the one I reported a while back. truing off tso
fixed it.
danny
On Mar 20, 2014, at 3:26 PM, Garrett Wollman wrote:
> I recently put a new server running 9.2 (with a local patches for NFS)
> into production, and it's immediately started to fail in an
In article <21290.60558.750106.630...@hergotha.csail.mit.edu>, I wrote:
>Since we put this server into production, random network system calls
>have started failing with [EFBIG] or maybe sometimes [EIO]. I've
>observed this with a simple ping, but various daemons also log the
>errors:
>Mar 20 09:
Sure:
$ uname -a
FreeBSD SAN0.XX 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu Jan
16 22:34:59 UTC 2014 r...@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC
amd64
I normally run a slightly tweaked NFS kernel, but I'm back on the default
build for now until this problem is resolved.
On
On 20.03.2014, at 14:51, woll...@bimajority.org wrote:
> In article <21290.60558.750106.630...@hergotha.csail.mit.edu>, I wrote:
>
>> Since we put this server into production, random network system calls
>> have started failing with [EFBIG] or maybe sometimes [EIO]. I've
>> observed this with a
On Thu, Mar 20, 2014 at 7:40 AM, Markus Gebert
wrote:
>
>
> Possible. We still see this on nfsclients only, but I'm not convinced that
> nfs is the only trigger.
>
>
Just to clarify, I'm experiencing this error with NFS, but also with iSCSI
- I turned off my NFS server in rc.conf and rebooted, and
Markus,
I just wanted to clarify what dtrace will output in a 'no-error'
situation. I'm seeing the following during a normal ping (no errors) on
ix0, or even on a non-problematic bge NIC:
On Thu, Mar 20, 2014 at 7:40 AM, Markus Gebert
wrote:
> Also, if you have dtrace available:
>
> kldload
(Struggling with this mail client for some reason, sorry, here's the paste)
# dtrace -n 'fbt:::return / arg1 == EFBIG && execname == "ping" / {
stack(); }'
dtrace: description 'fbt:::return ' matched 24892 probes
CPU IDFUNCTION:NAME
19 29656 maybe_yield:retu
On 20.03.2014, at 16:50, Christopher Forgeron wrote:
> Markus,
>
> I just wanted to clarify what dtrace will output in a 'no-error'
> situation. I'm seeing the following during a normal ping (no errors) on
> ix0, or even on a non-problematic bge NIC:
>
>
This is expected. This dtrace probe w
Output from the patch you gave me (I have screens of it.. let me know what
you're hoping to see.
Mar 20 16:37:22 SAN0 kernel: after mbcnt=33 pklen=65538 actl=65538
Mar 20 16:37:22 SAN0 kernel: before pklen=65538 actl=65538
Mar 20 16:37:22 SAN0 kernel: after mbcnt=33 pklen=65538 actl=65538
Mar 20
BTW,
When I have the problem, this is what I see from netstat -m
4080/2956/7036/6127254 mbuf clusters in use (current/cache/total/max)
4080/2636 mbuf+clusters out of packet secondary zone in use (current/cache)
0/50/50/3063627 4k (page size) jumbo clusters in use
(current/cache/total/max)
32768/
Re: cpuset ping
I can report that I do not get any fails with this ping - I have screens of
failed flood pings on the ix0 nic, but these always pass (i have that
cpuset ping looping constantly).
I can't report about the dtrace yet, as I'm running Rick's ixgbe patch, and
there seems to be a .ko co
In article
,
csforge...@gmail.com writes:
>50/27433/0 requests for jumbo clusters denied (4k/9k/16k)
This is going to screw you. You need to make sure that no NIC driver
ever allocates 9k jumbo pages -- unless you are using one of those
mythical drivers that can't do scatter/gather DMA on receiv
I have found this:
http://lists.freebsd.org/pipermail/freebsd-net/2013-October/036955.html
I think what you're saying is that;
- a MTU of 9000 doesn't need to equal a 9k mbuf / jumbo cluster
- modern NIC drivers can gather 9000 bytes of data from various memory
locations
- The fact that I'm seein
Any recommendations on what to do? I'm experimenting with disabling TSO
right now, but it's too early to tell if it fixes my problem.
On my 9.2 box, we don't see this number climbing. With TSO off on 10.0, I
also see the number is not climbing.
I'd appreciate any links you may have so I can read
What he's saying is that the driver should not be using 9K mbuf clusters, I
thought
this had been changed but I see the code in HEAD is still using the larger
clusters
when you up the mtu. I will put it on my list to change with the next
update to HEAD.
What version of ixgbe are you using?
Jack
Hi Jack,
I'm on ixgbe 2.5.15
I see a few other threads about using MJUMPAGESIZE instead of MJUM9BYTES.
If you have a patch you'd like me to test, I'll compile it in and let you
know. I was just looking at Garrett's if_em.c patch and thinking about
applying it to ixgbe..
As it stands I seem
I strongly discourage anyone from disabling TSO on 10G, its necessary to
get the
performance one wants to see on the hardware.
Here is a patch to do what i'm talking about:
*** ixgbe.cFri Jan 10 18:12:20 2014
--- ixgbe.jfv.cThu Mar 20 23:04:15 2014
*** ixgbe_init_locked(struct
I agree, performance is noticeably worse with TSO off, but I thought it
would be a good step in troubleshooting. I'm glad you're a regular reader
of the list, so I don't have to settle for slow performance. :-)
I'm applying your patch now, I think it will fix it - but I'll report in
after it's run
Your 4K mbuf pool is not being used, make sure you increase the size once
you are
using that or you'll just be having the same issue with a different pool.
Oh, and that patch was against the code in HEAD, it might need some manual
hacking
if you're using anything older.
Not sure what you mean abo
Ah, good point about the 4k buff size : I will allocate more to
kern.ipc.nmbjumbop , perhaps taking it from 9 and 16.
Yes, I did have to tweak the patch slightly to work on 10.0, but it's
basically the same thing I was trying after looking at Garrett's notes.
I see this is part of a larger proble
Christopher Forgeron wrote:
>
> Output from the patch you gave me (I have screens of it.. let me know
> what you're hoping to see.
>
>
> Mar 20 16:37:22 SAN0 kernel: after mbcnt=33 pklen=65538 actl=65538
> Mar 20 16:37:22 SAN0 kernel: before pklen=65538 actl=65538
Hmm. I think this means that th
Christopher Forgeron wrote:
>
>
>
>
>
>
> On Thu, Mar 20, 2014 at 7:40 AM, Markus Gebert <
> markus.geb...@hostpoint.ch > wrote:
>
>
>
>
>
> Possible. We still see this on nfsclients only, but I’m not convinced
> that nfs is the only trigger.
>
>
Since Christopher is getting a bunch of
Yes, there is something broken in TSO for sure, as disabling it allows me
to run without error. It is possible that the drop in performance is
allowing me to stay under a critical threshold for the problem, but I'd
feel happier testing to make sure.
I understand what you're asking for in the patch
Markus Gebert wrote:
>
> On 20.03.2014, at 14:51, woll...@bimajority.org wrote:
>
> > In article <21290.60558.750106.630...@hergotha.csail.mit.edu>, I
> > wrote:
> >
> >> Since we put this server into production, random network system
> >> calls
> >> have started failing with [EFBIG] or maybe so
Christopher Forgeron wrote:
> Yes, there is something broken in TSO for sure, as disabling it
> allows me
> to run without error. It is possible that the drop in performance is
> allowing me to stay under a critical threshold for the problem, but
> I'd
> feel happier testing to make sure.
>
> I un
BTW - I think this will end up being a TSO issue, not the patch that Jack
applied.
When I boot Jack's patch (MJUM9BYTES removal) this is what netstat -m shows:
21489/2886/24375 mbufs in use (current/cache/total)
4080/626/4706/6127254 mbuf clusters in use (current/cache/total/max)
4080/587 mbuf+cl
Sorry Rick, what's the small change you wanted in sys/netinet/tcp_output.c
at 777-778? I see it's calc'ing length... or did you want me to take the
whole file back to 9.1-RELEASE ?
On Thu, Mar 20, 2014 at 11:47 PM, Rick Macklem wrote:
> Christopher Forgeron wrote:
> > Yes, there is something br
Pardon.. delay in recv'ing messages. I see your edits for 777-778 .. will
attempt tomorrow.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.or
33 matches
Mail list logo
