Hans Petter Selasky wrote:
> Hi,
>
> I've now MFC'ed r287775 to 10-stable and 9-stable. I hope this will
> resolve the issues with m_defrag() being called on too long mbuf chains
> due to an off-by-one in the driver TSO parameters and that it will be
> easier to maintain these parameters in the fu
Hi,
I've now MFC'ed r287775 to 10-stable and 9-stable. I hope this will
resolve the issues with m_defrag() being called on too long mbuf chains
due to an off-by-one in the driver TSO parameters and that it will be
easier to maintain these parameters in the future.
Some comments were made tha
> On Aug 24, 2015, at 3:25 PM, Rick Macklem wrote:
>
> Daniel Braniss wrote:
>>
>>> On 24 Aug 2015, at 10:22, Hans Petter Selasky wrote:
>>>
>>> On 08/24/15 01:02, Rick Macklem wrote:
The other thing is the degradation seems to cut the rate by about half
each time.
300-->150-->
Hi,
I've made some minor modifications to the patch from Rick, and made this
review:
https://reviews.freebsd.org/D3477
--HPS
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mai
Hi,
Some hand-waving suggestions:
* if you're running something before 10.2, please disable IXGBE_FDIR
in sys/conf/options and sys/modules/ixgbe/Makefile . It's buggy and it
caused a lot of issues.
* It sounds like some extra latency is happening, so I'd fiddle around
with interrupt settings. By
Daniel Braniss wrote:
>
> > On 24 Aug 2015, at 10:22, Hans Petter Selasky wrote:
> >
> > On 08/24/15 01:02, Rick Macklem wrote:
> >> The other thing is the degradation seems to cut the rate by about half
> >> each time.
> >> 300-->150-->70 I have no idea if this helps to explain it.
> >
> > Mig
> On 24 Aug 2015, at 10:22, Hans Petter Selasky wrote:
>
> On 08/24/15 01:02, Rick Macklem wrote:
>> The other thing is the degradation seems to cut the rate by about half each
>> time.
>> 300-->150-->70 I have no idea if this helps to explain it.
>
> Might be a NUMA binding issue for the proc
> On 24 Aug 2015, at 02:02, Rick Macklem wrote:
>
> Daniel Braniss wrote:
>>
>>> On 22 Aug 2015, at 14:59, Rick Macklem wrote:
>>>
>>> Daniel Braniss wrote:
> On Aug 22, 2015, at 12:46 AM, Rick Macklem wrote:
>
> Yonghyeon PYUN wrote:
>> On Wed, Aug 19, 2015 at 09:00:3
On 08/24/15 01:02, Rick Macklem wrote:
The other thing is the degradation seems to cut the rate by about half each
time.
300-->150-->70 I have no idea if this helps to explain it.
Might be a NUMA binding issue for the processes involved.
man cpuset
--HPS
_
Daniel Braniss wrote:
>
> > On 22 Aug 2015, at 14:59, Rick Macklem wrote:
> >
> > Daniel Braniss wrote:
> >>
> >>> On Aug 22, 2015, at 12:46 AM, Rick Macklem wrote:
> >>>
> >>> Yonghyeon PYUN wrote:
> On Wed, Aug 19, 2015 at 09:00:35AM -0400, Rick Macklem wrote:
> > Hans Petter Selas
On Sun, Aug 23, 2015 at 02:08:56PM +0300, Daniel Braniss wrote:
> >> send me the patch and I'll test it ASAP.
> >>danny
> >>
> > Patch is attached. The one for head will also include an update to the
> > comment
> > in sys/net/if_var.h, but that isn't needed for testing.
>
>
> well, the pl
> On 22 Aug 2015, at 14:59, Rick Macklem wrote:
>
> Daniel Braniss wrote:
>>
>>> On Aug 22, 2015, at 12:46 AM, Rick Macklem wrote:
>>>
>>> Yonghyeon PYUN wrote:
On Wed, Aug 19, 2015 at 09:00:35AM -0400, Rick Macklem wrote:
> Hans Petter Selasky wrote:
>> On 08/19/15 09:42, Yonghy
Daniel Braniss wrote:
>
> > On Aug 22, 2015, at 12:46 AM, Rick Macklem wrote:
> >
> > Yonghyeon PYUN wrote:
> >> On Wed, Aug 19, 2015 at 09:00:35AM -0400, Rick Macklem wrote:
> >>> Hans Petter Selasky wrote:
> On 08/19/15 09:42, Yonghyeon PYUN wrote:
> > On Wed, Aug 19, 2015 at 09:00:52
> On Aug 22, 2015, at 12:46 AM, Rick Macklem wrote:
>
> Yonghyeon PYUN wrote:
>> On Wed, Aug 19, 2015 at 09:00:35AM -0400, Rick Macklem wrote:
>>> Hans Petter Selasky wrote:
On 08/19/15 09:42, Yonghyeon PYUN wrote:
> On Wed, Aug 19, 2015 at 09:00:52AM +0200, Hans Petter Selasky wrote:
Yonghyeon PYUN wrote:
> On Wed, Aug 19, 2015 at 09:00:35AM -0400, Rick Macklem wrote:
> > Hans Petter Selasky wrote:
> > > On 08/19/15 09:42, Yonghyeon PYUN wrote:
> > > > On Wed, Aug 19, 2015 at 09:00:52AM +0200, Hans Petter Selasky wrote:
> > > >> On 08/18/15 23:54, Rick Macklem wrote:
> > > >>>
Yonghyeon PYUN wrote:
> On Wed, Aug 19, 2015 at 08:13:59AM -0400, Rick Macklem wrote:
> > Yonghyeon PYUN wrote:
> > > On Wed, Aug 19, 2015 at 09:51:44AM +0200, Hans Petter Selasky wrote:
> > > > On 08/19/15 09:42, Yonghyeon PYUN wrote:
> > > > >On Wed, Aug 19, 2015 at 09:00:52AM +0200, Hans Petter
Yonghyeon,
On Thu, Aug 20, 2015 at 11:30:24AM +0900, Yonghyeon PYUN wrote:
Y> > > >> Maybe it can be controlled by some kind of flag, if all the three TSO
Y> > > >> limits should include the TCP/IP/ethernet headers too. I'm pretty sure
Y> > > >> we want both versions.
Y> > > >>
Y> > > >
Y> > > >
On Wed, Aug 19, 2015 at 08:13:59AM -0400, Rick Macklem wrote:
> Yonghyeon PYUN wrote:
> > On Wed, Aug 19, 2015 at 09:51:44AM +0200, Hans Petter Selasky wrote:
> > > On 08/19/15 09:42, Yonghyeon PYUN wrote:
> > > >On Wed, Aug 19, 2015 at 09:00:52AM +0200, Hans Petter Selasky wrote:
> > > >>On 08/18/
On Wed, Aug 19, 2015 at 09:00:35AM -0400, Rick Macklem wrote:
> Hans Petter Selasky wrote:
> > On 08/19/15 09:42, Yonghyeon PYUN wrote:
> > > On Wed, Aug 19, 2015 at 09:00:52AM +0200, Hans Petter Selasky wrote:
> > >> On 08/18/15 23:54, Rick Macklem wrote:
> > >>> Ouch! Yes, I now see that the code
Daniel Braniss wrote:
>
> > On 19 Aug 2015, at 16:00, Rick Macklem wrote:
> >
> > Hans Petter Selasky wrote:
> >> On 08/19/15 09:42, Yonghyeon PYUN wrote:
> >>> On Wed, Aug 19, 2015 at 09:00:52AM +0200, Hans Petter Selasky wrote:
> On 08/18/15 23:54, Rick Macklem wrote:
> > Ouch! Yes, I
> On 19 Aug 2015, at 16:00, Rick Macklem wrote:
>
> Hans Petter Selasky wrote:
>> On 08/19/15 09:42, Yonghyeon PYUN wrote:
>>> On Wed, Aug 19, 2015 at 09:00:52AM +0200, Hans Petter Selasky wrote:
On 08/18/15 23:54, Rick Macklem wrote:
> Ouch! Yes, I now see that the code that counts the
Hans Petter Selasky wrote:
> On 08/19/15 09:42, Yonghyeon PYUN wrote:
> > On Wed, Aug 19, 2015 at 09:00:52AM +0200, Hans Petter Selasky wrote:
> >> On 08/18/15 23:54, Rick Macklem wrote:
> >>> Ouch! Yes, I now see that the code that counts the # of mbufs is before
> >>> the
> >>> code that adds the
Hans Petter Selasky wrote:
> On 08/19/15 09:42, Yonghyeon PYUN wrote:
> > On Wed, Aug 19, 2015 at 09:00:52AM +0200, Hans Petter Selasky wrote:
> >> On 08/18/15 23:54, Rick Macklem wrote:
> >>> Ouch! Yes, I now see that the code that counts the # of mbufs is before
> >>> the
> >>> code that adds the
Hans Petter Selasky wrote:
> On 08/19/15 09:42, Yonghyeon PYUN wrote:
> > On Wed, Aug 19, 2015 at 09:00:52AM +0200, Hans Petter Selasky wrote:
> >> On 08/18/15 23:54, Rick Macklem wrote:
> >>> Ouch! Yes, I now see that the code that counts the # of mbufs is before
> >>> the
> >>> code that adds the
Yonghyeon PYUN wrote:
> On Wed, Aug 19, 2015 at 09:51:44AM +0200, Hans Petter Selasky wrote:
> > On 08/19/15 09:42, Yonghyeon PYUN wrote:
> > >On Wed, Aug 19, 2015 at 09:00:52AM +0200, Hans Petter Selasky wrote:
> > >>On 08/18/15 23:54, Rick Macklem wrote:
> > >>>Ouch! Yes, I now see that the code
On Wed, Aug 19, 2015 at 09:51:44AM +0200, Hans Petter Selasky wrote:
> On 08/19/15 09:42, Yonghyeon PYUN wrote:
> >On Wed, Aug 19, 2015 at 09:00:52AM +0200, Hans Petter Selasky wrote:
> >>On 08/18/15 23:54, Rick Macklem wrote:
> >>>Ouch! Yes, I now see that the code that counts the # of mbufs is be
On 08/19/15 09:42, Yonghyeon PYUN wrote:
On Wed, Aug 19, 2015 at 09:00:52AM +0200, Hans Petter Selasky wrote:
On 08/18/15 23:54, Rick Macklem wrote:
Ouch! Yes, I now see that the code that counts the # of mbufs is before the
code that adds the tcp/ip header mbuf.
In my opinion, this should be
On 08/19/15 09:42, Yonghyeon PYUN wrote:
On Wed, Aug 19, 2015 at 09:00:52AM +0200, Hans Petter Selasky wrote:
On 08/18/15 23:54, Rick Macklem wrote:
Ouch! Yes, I now see that the code that counts the # of mbufs is before the
code that adds the tcp/ip header mbuf.
In my opinion, this should be
On Wed, Aug 19, 2015 at 09:00:52AM +0200, Hans Petter Selasky wrote:
> On 08/18/15 23:54, Rick Macklem wrote:
> >Ouch! Yes, I now see that the code that counts the # of mbufs is before the
> >code that adds the tcp/ip header mbuf.
> >
> >In my opinion, this should be fixed by setting if_hw_tsomaxse
On Tue, Aug 18, 2015 at 06:04:25PM -0400, Rick Macklem wrote:
> Hans Petter Selasky wrote:
> > On 08/18/15 14:53, Rick Macklem wrote:
> > > If this is just a test machine, maybe you could test with these lines (at
> > > about #880)
> > > in sys/netinet/tcp_output.c commented out? (It looks to me li
On 08/18/15 23:54, Rick Macklem wrote:
Ouch! Yes, I now see that the code that counts the # of mbufs is before the
code that adds the tcp/ip header mbuf.
In my opinion, this should be fixed by setting if_hw_tsomaxsegcount to whatever
the driver provides - 1. It is not the driver's responsibility
Daniel Braniss wrote:
>
> > On Aug 18, 2015, at 12:49 AM, Rick Macklem wrote:
> >
> > Daniel Braniss wrote:
> >>
> >>> On Aug 17, 2015, at 3:21 PM, Rick Macklem wrote:
> >>>
> >>> Daniel Braniss wrote:
>
> > On Aug 17, 2015, at 1:41 PM, Christopher Forgeron
> >
> > wrote:
>
Hans Petter Selasky wrote:
> On 08/18/15 14:53, Rick Macklem wrote:
> > If this is just a test machine, maybe you could test with these lines (at
> > about #880)
> > in sys/netinet/tcp_output.c commented out? (It looks to me like this will
> > disable TSO
> > for almost all the NFS writes.)
> > - a
Hans Petter Selasky wrote:
> On 08/18/15 14:53, Rick Macklem wrote:
> > 2572 ifp->if_hw_tsomax = 65518;
> >> >2573 ifp->if_hw_tsomaxsegcount =
> >> >IXGBE_82599_SCATTER;
> >> >2574 ifp->if_hw_tsomaxsegsize = 2048;
>
> Hi,
>
> If
On Tue, Aug 18, 2015 at 05:09:41PM +0300, Daniel Braniss wrote:
> sorry, it's been a tough day, we had a major meltdown, caused by a faulty
> gbic :-(
> anyways, could you tell me what to do?
> comment out, fix the off by one?
>
> the machine is not yet production.
Can you collect this informat
sorry, it’s been a tough day, we had a major meltdown, caused by a faulty gbic
:-(
anyways, could you tell me what to do?
comment out, fix the off by one?
the machine is not yet production.
thanks,
danny
> On 18 Aug 2015, at 16:32, Hans Petter Selasky wrote:
>
> On 08/18/15 14:53, Ric
On 08/18/15 14:53, Rick Macklem wrote:
2572 ifp->if_hw_tsomax = 65518;
>2573 ifp->if_hw_tsomaxsegcount = IXGBE_82599_SCATTER;
>2574 ifp->if_hw_tsomaxsegsize = 2048;
Hi,
If IXGBE_82599_SCATTER is the maximum scatter/gather ent
On 08/18/15 14:53, Rick Macklem wrote:
If this is just a test machine, maybe you could test with these lines (at about
#880)
in sys/netinet/tcp_output.c commented out? (It looks to me like this will
disable TSO
for almost all the NFS writes.)
- around line #880 in sys/netinet/tcp_output.c:
Daniel Braniss wrote:
>
> > On Aug 18, 2015, at 12:49 AM, Rick Macklem wrote:
> >
> > Daniel Braniss wrote:
> >>
> >>> On Aug 17, 2015, at 3:21 PM, Rick Macklem wrote:
> >>>
> >>> Daniel Braniss wrote:
>
> > On Aug 17, 2015, at 1:41 PM, Christopher Forgeron
> >
> > wrote:
>
> On Aug 18, 2015, at 12:49 AM, Rick Macklem wrote:
>
> Daniel Braniss wrote:
>>
>>> On Aug 17, 2015, at 3:21 PM, Rick Macklem wrote:
>>>
>>> Daniel Braniss wrote:
> On Aug 17, 2015, at 1:41 PM, Christopher Forgeron
> wrote:
>
> FYI, I can regularly hit 9.3 Gib/s with
Daniel Braniss wrote:
>
> > On Aug 17, 2015, at 3:21 PM, Rick Macklem wrote:
> >
> > Daniel Braniss wrote:
> >>
> >>> On Aug 17, 2015, at 1:41 PM, Christopher Forgeron
> >>> wrote:
> >>>
> >>> FYI, I can regularly hit 9.3 Gib/s with my Intel X520-DA2's and FreeBSD
> >>> 10.1. Before 10.1 it w
On Mon, Aug 17, 2015 at 05:44:37PM +0200, Alban Hertroys wrote:
> On 17 August 2015 at 13:54, Slawa Olhovchenkov wrote:
> > On Mon, Aug 17, 2015 at 01:49:27PM +0200, Alban Hertroys wrote:
> >
> >> On 17 August 2015 at 13:39, Slawa Olhovchenkov wrote:
> >>
> >> > In any case, for 10Gb expect abou
On 17 August 2015 at 13:54, Slawa Olhovchenkov wrote:
> On Mon, Aug 17, 2015 at 01:49:27PM +0200, Alban Hertroys wrote:
>
>> On 17 August 2015 at 13:39, Slawa Olhovchenkov wrote:
>>
>> > In any case, for 10Gb expect about 1200MGB/s.
>>
>> Your usage of units is confusing. Above you claim you expe
> On Aug 17, 2015, at 3:21 PM, Rick Macklem wrote:
>
> Daniel Braniss wrote:
>>
>>> On Aug 17, 2015, at 1:41 PM, Christopher Forgeron
>>> wrote:
>>>
>>> FYI, I can regularly hit 9.3 Gib/s with my Intel X520-DA2's and FreeBSD
>>> 10.1. Before 10.1 it was less.
>>>
>>
>> this is NOT iperf/3 w
On Mon, Aug 17, 2015 at 10:27:41AM +0300, Daniel Braniss wrote:
> hi,
> I have a host (Dell R730) with both cards, connected to an HP8200
> switch at 10Gb.
> when writing to the same storage (netapp) this is what I get:
> ix0:~130MGB/s
> mlxen0
Daniel Braniss wrote:
>
> > On Aug 17, 2015, at 1:41 PM, Christopher Forgeron
> > wrote:
> >
> > FYI, I can regularly hit 9.3 Gib/s with my Intel X520-DA2's and FreeBSD
> > 10.1. Before 10.1 it was less.
> >
>
> this is NOT iperf/3 where i do get close to wire speed,
> it’s NFS writes, i.e., a
On Mon, Aug 17, 2015 at 01:49:27PM +0200, Alban Hertroys wrote:
> On 17 August 2015 at 13:39, Slawa Olhovchenkov wrote:
>
> > In any case, for 10Gb expect about 1200MGB/s.
>
> Your usage of units is confusing. Above you claim you expect 1200
I am use as topic starter and expect MeGaBytes per s
On 17 August 2015 at 13:39, Slawa Olhovchenkov wrote:
> In any case, for 10Gb expect about 1200MGB/s.
Your usage of units is confusing. Above you claim you expect 1200
million gigabytes per second, or 1.2 * 10^18 Bytes/s. I don't think
any known network interface can do that, including highly ex
On Mon, Aug 17, 2015 at 01:35:06PM +0300, Daniel Braniss wrote:
>
> > On Aug 17, 2015, at 12:41 PM, Slawa Olhovchenkov wrote:
> >
> > On Mon, Aug 17, 2015 at 10:27:41AM +0300, Daniel Braniss wrote:
> >
> >> hi,
> >>I have a host (Dell R730) with both cards, connected to an HP8200
> >> swi
> On Aug 17, 2015, at 1:41 PM, Christopher Forgeron
> wrote:
>
> FYI, I can regularly hit 9.3 Gib/s with my Intel X520-DA2's and FreeBSD 10.1.
> Before 10.1 it was less.
>
this is NOT iperf/3 where i do get close to wire speed,
it’s NFS writes, i.e., almost real work :-)
> I used to tweak t
FYI, I can regularly hit 9.3 Gib/s with my Intel X520-DA2's and FreeBSD
10.1. Before 10.1 it was less.
I used to tweak the card settings, but now it's just stock. You may want to
check your settings, the Mellanox may just have better defaults for your
switch.
On Mon, Aug 17, 2015 at 6:41 AM, Slaw
> On Aug 17, 2015, at 12:41 PM, Slawa Olhovchenkov wrote:
>
> On Mon, Aug 17, 2015 at 10:27:41AM +0300, Daniel Braniss wrote:
>
>> hi,
>> I have a host (Dell R730) with both cards, connected to an HP8200
>> switch at 10Gb.
>> when writing to the same storage (netapp) this is what I g
On Mon, Aug 17, 2015 at 10:27:41AM +0300, Daniel Braniss wrote:
> hi,
> I have a host (Dell R730) with both cards, connected to an HP8200
> switch at 10Gb.
> when writing to the same storage (netapp) this is what I get:
> ix0:~130MGB/s
> mlxen0
hi,
I have a host (Dell R730) with both cards, connected to an HP8200
switch at 10Gb.
when writing to the same storage (netapp) this is what I get:
ix0:~130MGB/s
mlxen0 ~330MGB/s
this is via nfs/tcpv3
I can get similar (
54 matches
Mail list logo
