Dear Members,
I am part of Panasas. I am evaluating 'Lagg-LACP performance and
robustness' over Intel Fortville NIC (IXL) on Intel Taylor Pass platform
with FreeBSD-HOL [11-CURRENT] installed. Lagg-LACP feature works fine
(with satisfactory performance) when Promiscuous mode is enabled on the
lstewart added a comment.
Ok, but that's anecdotal and gives us reviewers nothing to go on - without any
methodology or raw data who knows whether the LRO change is solely responsible
for the improvement and if it introduced any undesired side effects. It's also
possible that with tuning, the s
hselasky added a comment.
lawrence: It is someone well known to be using FreeBSD. This patch makes such a
big difference when applied to +10Gbit/s connections that we can run 2 TCP
streams totalling 37.5 GBit/s on a single 2.x GHz CPU core instead of only one.
REPOSITORY
rS FreeBSD src repos
lstewart added a comment.
I hope I didn't delete it... from what I could see online, the "Abandon"
Phabricator action is the means by which a reviewer indicates they have
permanently rejected the patch (as opposed to suggesting changes).
As to people using the patch, can you say who and why?
hselasky added a comment.
lstewart: OK, just don't delete this patch, because some people are using it.
REPOSITORY
rS FreeBSD src repository
REVISION DETAIL
https://reviews.freebsd.org/D1761
EMAIL PREFERENCES
https://reviews.freebsd.org/settings/panel/emailpreferences/
To: hselasky, rrs
lstewart abandoned this revision.
lstewart added a comment.
Hans,
Just because some hardware is capable of coalescing more than 64k of data
doesn't mean we should feel obligated to support the functionality. I'd be
curious to understand the anticipated use cases that led to hardware support
be
As Ryan said, its there to keep queues marked as "hung" from
getting more work scheduled on them. I really don't know what
to make of it if commenting it out is somehow improving things :)
I would suggest more careful analysis of what is going wrong
before committing anything like deleting this.
Notice to Appear,
This is to inform you to appear in the Court on the June 22 for your case
hearing.
You are kindly asked to prepare and bring the documents relating to the case to
Court on the specified date.
Note: The case will be heard by the judge in your absence if you do not come.
You can
On Wed, Jun 17, 2015 at 7:00 AM, Lakshmi Narasimhan Sundararajan <
lakshm...@msystechnologies.com> wrote:
> [lakshmis@mau-bsd-10a ~/fortville/hol/sys/dev/ixl]$ diff -c5pt ixl_txrx.c
> ixl_txrx.c.mod
> *** ixl_txrx.c Fri Jun 12 06:56:51 2015
> --- ixl_txrx.c.mod Fri Jun 12 06:56:33 2015
> *
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200379
--- Comment #18 from Michael Tuexen ---
(In reply to Craig Rodrigues from comment #17)
Ahh. Thanks for the hint. Will do.
Best regards
Michael
--
You are receiving this mail because:
You are on the CC list for the bug.
__
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200379
--- Comment #17 from Craig Rodrigues ---
(In reply to Michael Tuexen from comment #16)
Thanks for working on this. Next time you commit a fix for this PR via MFC,
remember to put in the following in the commit log message, so that the
com
On 06/17/15 at 03:10P, Jean-Francois HREN wrote:
> Hello, while investigating a freeze on a modified FreeBSD 9.3 I stumbled upon
> a potential bug in netinet/tcp_output.c
>
> If an error occurs while processing a TCP segment with some data and the FIN
> flag,
> the back out of the sequence number
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200379
--- Comment #16 from Michael Tuexen ---
(In reply to Alan Somers from comment #15)
Yes, you can failover from one ISP to another. Currently this is done by having
corresponding entries in a single routing table for the multiple peer
address
It sounds like a promisc bug in the driver, just as you say, but just to
test it some more:
I see that you are running both in PPROMISC and PROMISC.
What happen if you remove the PPROMISC and only let tcpdump set it's own
PROMISC?
Running in monitor mode is the correct way to sniff traffi
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200379
--- Comment #15 from Alan Somers ---
(In reply to Michael Tuexen from comment #14)
You're right about the interface FIB. It will take incoming packets with a
certain FIB. But it's not completely general; it's possible to have outbound
tr
Tried disabling all offloadings available, doesn't help.
Sorry, in that case I don't know what it might be.
Have you tried disabling "adapter intelligence"? rxcsum, txcsum, lro, etc?
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/
On Jun 17, 2015, at 2:58 PM, Sergey Akhmatov wrote:
> I've tried 10.1-RELEASE, then 10-STABLE and finaly 11-CURRENT with the same
> result.
Sorry, in that case I don't know what it might be.
Have you tried disabling "adapter intelligence"? rxcsum, txcsum, lro, etc?
Borja.
___
Hello, while investigating a freeze on a modified FreeBSD 9.3 I stumbled upon
a potential bug in netinet/tcp_output.c
If an error occurs while processing a TCP segment with some data and the FIN
flag,
the back out of the sequence number advance does not take into account
the increase by 1 due to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200379
--- Comment #14 from Michael Tuexen ---
(In reply to Alan Somers from comment #13)
I think interfaces can assign fibs to packets, it is a field in the mbuf packet
header. It makes sense to use this information in case you have no socket to
I've tried 10.1-RELEASE, then 10-STABLE and finaly 11-CURRENT with the
same result.
Beware
The driver was unusable until fixes were applied on 21st December.
http://svnweb.freebsd.org/base/stable/10/sys/dev/oce/?view=log
Better use a recent 10-STABLE if possible.
_
Hi FreeBSD folks,
I am part of Panasas and working on evaluating IXL over FreeBSD
[11-CURRENT] on Intel Taylor Pass platform for our next product.
In that regard, while evaluating performance, we found the Tx performance
to be very poor. We found it to be so because the tx interrupts are spread
ov
On Jun 17, 2015, at 11:48 AM, Sergey Akhmatov wrote:
> Hi,
>
> I’ve got problems with HP NC550SFP NIC
> (http://www.emulex.com/products/ethernet-networking-storage-connectivity/ethernet-networking-adapters/hp-branded/nc550sfp/overview/
> )
Beware
The driver was unusable until fixes were appl
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200323
--- Comment #14 from commit-h...@freebsd.org ---
A commit references this bug:
Author: eri
Date: Wed Jun 17 12:23:05 UTC 2015
New revision: 284512
URL: https://svnweb.freebsd.org/changeset/base/284512
Log:
If there is a system with a bpf
Hi,
I’ve got problems with HP NC550SFP NIC
(http://www.emulex.com/products/ethernet-networking-storage-connectivity/ethernet-networking-adapters/hp-branded/nc550sfp/overview/
)
Setup information:
I’m intended to use this system for traffic monitoring:
switchport configured for traffic mirror
24 matches
Mail list logo
