On 3/18/14, 12:30 AM, Mark van der Meulen wrote:
Hi,
I have noticed net graph has issues with device that have a period in their
name. Either that is the case or something similar.
I couldn’t enable netflow on lagg0.X devices and I also couldn’t use some of
mpd's features(such as LAC) either.
Ah yes, I see it now: Line #658
#if defined(INET) || defined(INET6)
/* Initialize to max value. */
if (ifp->if_hw_tsomax == 0)
ifp->if_hw_tsomax = IP_MAXPACKET;
KASSERT(ifp->if_hw_tsomax <= IP_MAXPACKET &&
ifp->if_hw_tsomax >= IP_MAXPACKET / 8,
No errors for 1h 46m - That's a record. This is using the 9.2-STABLE ixgbe
in a 10.0-RELEASE system, with Rick's suggested code below.
I decided this must be it, so I aborted, and modified the ixgbe driver from
10.0-STABLE with Rick's suggestion. Installed and rebooted. Here's the
extra values I p
Christopher Forgeron wrote:
> It may be a little early, but I think that's it!
>
> It's been running without error for nearly an hour - It's very rare
> it
> would go this long under this much load.
>
> I'm going to let it run longer, then abort and install the kernel
> with the
> extra printfs s
It may be a little early, but I think that's it!
It's been running without error for nearly an hour - It's very rare it
would go this long under this much load.
I'm going to let it run longer, then abort and install the kernel with the
extra printfs so I can see what value ifp->if_hw_tsomax is be
Old Synopsis: Ngctl strange behavior when adding more than 530 vlan through
nethraph
New Synopsis: ngctl(8) strange behavior when adding more than 530 vlan through
nethraph
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Sat Mar 22
Well I can tell you that your if statement in that patch is being
activated. I added a printf in there, and it showed up on my dmsg.
I still see bad things for netstat -m , but I'm starting a load run to see
if it makes a difference.
Next compile I'll add printouts of what ifp->if_hw_tsomax is on
Thanks Rick, trying it now. I'm currently working with the 9.2 ixgbe code
as a starting point, as I'm curious/encouraged by the lack of jumbo cluster
denials in netmap.
I'll let you know how it works out.
On Fri, Mar 21, 2014 at 8:44 PM, Rick Macklem wrote:
> Christopher Forgeron wrote:
> >
>
Christopher Forgeron wrote:
>
>
>
>
>
>
> Hello all,
>
> I ran Jack's ixgbe MJUM9BYTES removal patch, and let iometer hammer
> away at the NFS store overnight - But the problem is still there.
>
>
> From what I read, I think the MJUM9BYTES removal is probably good
> cleanup (as long as it
Good point - I'm printing where Rick asked, in the 'before' printf
statement, which comes before the m = m_defrag(*m_headp, M_NOWAIT); command
in ixgbe_xmit
I'm going to be adding more printf's to the code to see if I can find
anything interesting, your suggestions would be welcome.
..and I suppo
Ah, I appreciate your efforts Rick - If you have any final parting hints,
please let me know. I'm opening up access from my IDE so I can look at this
with something a bit more advanced than the default vi.
For the record, I was printing the flags out as an unsigned long, so that
should be decimal.
>Ok, so this isn't a TSO segment then, unless I don't understand how
>the csum flags are used, which is quite possible.
>Assuming that you printed this out in decimal:
>4116->0x1014
>Looking in mbuf.h, 0x1014 is
>CSUM_SCTP_VALID | CSUM_FRAGMENT | CSUM_UDP
>
>alternately, if 4116 is hex, then it is:
Christopher Forgeron wrote:
> (Pardon me, for some reason my gmail is sending on my cut-n-pastes if
> I cr
> down too fast)
>
> First set of logs:
>
> Mar 21 11:07:00 SAN0 kernel: before pklen=65542 actl=65542 csum=4116
Ok, so this isn't a TSO segment then, unless I don't understand how
the csum
Update:
I've noticed a fair number of differences in the ixgbe driver between 9.2
and 10.0-RELEASE, even though they have the same 2.5.15 version. Mostly
Netmap integration.
I've loaded up a 9.2-STABLE ixgbe driver from Dec 25th as it was handy (I
had to hack the source a bit since some #def's ha
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 inclu
* Jimmy Olgeni, 2013-12-03 :
> I cannot imagine any obvious reason for packets getting "lost" after enc0,
> so any hint would be much appreciated :)
Chances are "netstat -s -p udp" will show you an increasing count of
packets with bad checksum. See PRs kern/145737 and kern/146190.
Thomas.
_
Fair enough.
Have you tried disabling tso on the ix's ? That does fix the problem for
me, however there is a performance penalty to be paid.
I'm now regressing through the ixgbe drivers - I see there's been changes
to how the queues are drained between 9.1 - 10.0, will see if the older
ixgbe 2.4.
On 21.03.2014, at 15:49, Christopher Forgeron wrote:
> However, if you can make a spare tester of the same hardware, that's
> perfect - And you can generate all the load you need with benchmark
> software like iometer, large NFS copies, or perhaps a small replica of your
> network. Synthetic lo
On 21.03.2014, at 16:22, Christopher Forgeron wrote:
> Markus,
>
> I don't know why I didn't notice this before.. I copied your cpuset ping
> verbatim, not realizing that I should be using 172.16.0.x as that's my
> network on the ix's
>
> On this tester box, 10.0.0.1 goes out a different inter
On Fri, Mar 21, 2014 at 3:48 PM, Mark Delany wrote:
> Subject line says it all. I don't know what the convention is, but I
> presume everything should be declared const whenever possible, thus
> the appended patch.
>
>
yes makes sense.
cheers
luigi
__
Markus,
I don't know why I didn't notice this before.. I copied your cpuset ping
verbatim, not realizing that I should be using 172.16.0.x as that's my
network on the ix's
On this tester box, 10.0.0.1 goes out a different interface, thus it never
reported back any problems.
Now that I've corr
(Pardon me, for some reason my gmail is sending on my cut-n-pastes if I cr
down too fast)
First set of logs:
Mar 21 11:07:00 SAN0 kernel: before pklen=65542 actl=65542 csum=4116
Mar 21 11:07:00 SAN0 kernel: after mbcnt=33 pklen=65542 actl=65542
Mar 21 11:07:00 SAN0 kernel: before pklen=65542 actl
Rick:
Unfortunately your patch didn't work. I expected as much as soon as I saw
my boot time 'netstat -m', but I wanted to run the tests to make sure.
First, here is where I put in your additional line - Let me know if that's
what you were hoping for, as I'm using mmm->m_pkthdr.csum_flags, as m
Ah, I understand the difficulties of testing production systems.
However, if you can make a spare tester of the same hardware, that's
perfect - And you can generate all the load you need with benchmark
software like iometer, large NFS copies, or perhaps a small replica of your
network. Synthetic
Subject line says it all. I don't know what the convention is, but I
presume everything should be declared const whenever possible, thus
the appended patch.
Mark.
*** /usr/include/net/netmap_user.h Sun Mar 16 12:01:36 2014
--- /tmp/./netmap_user.hFri Mar 21 07:39:16 2014
*
On 21.03.2014, at 14:16, Christopher Forgeron wrote:
> Hi Markus,
>
> Yes, we may have different problems, or perhaps the same problem is
> manifesting itself in different ways in our systems.
>
> Have you tried a 10.0-RELEASE system yet? If we were on the same OS version,
> we could then
Hi Markus,
Yes, we may have different problems, or perhaps the same problem is
manifesting itself in different ways in our systems.
Have you tried a 10.0-RELEASE system yet? If we were on the same OS
version, we could then compare system specs a bit deeper, and see what is
different. Perhaps un
On 21.03.2014, at 12:47, Christopher Forgeron wrote:
> Hello all,
>
> I ran Jack's ixgbe MJUM9BYTES removal patch, and let iometer hammer away
> at the NFS store overnight - But the problem is still there.
>
> From what I read, I think the MJUM9BYTES removal is probably good cleanup
> (as lon
Hello all,
I ran Jack's ixgbe MJUM9BYTES removal patch, and let iometer hammer away
at the NFS store overnight - But the problem is still there.
>From what I read, I think the MJUM9BYTES removal is probably good cleanup
(as long as it doesn't trade performance on a lightly memory loaded system
On 21.03.2014, at 03:45, Rick Macklem wrote:
> 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
cal
30 matches
Mail list logo
