Juli is correct, the FIFO is not partitioned by the driver queues as they
exist in the current driver, its only seperated into the 3 parts I
mentioned.
Jack
On Mon, May 7, 2012 at 9:55 PM, Juli Mallett wrote:
> On Mon, May 7, 2012 at 9:42 PM, Vijay Singh wrote:
> >> normal net traffic. But fo
On Mon, May 7, 2012 at 9:42 PM, Vijay Singh wrote:
>> normal net traffic. But for now in FreeBSD its just one which is divided
>> into 3 parts: TX, RX, and FDIR (flow director).
>
> Jack, does the sw driver control in any way the partitioning of the
> FIFO? I guess enabling 2 hw queues splits the
> normal net traffic. But for now in FreeBSD its just one which is divided
> into 3 parts: TX, RX, and FDIR (flow director).
Jack, does the sw driver control in any way the partitioning of the
FIFO? I guess enabling 2 hw queues splits the FIFO in half. But
otherwise does the driver control this in
On Mon, May 7, 2012 at 5:31 PM, Juli Mallett wrote:
> While we're on the subject, I've had some confusion for some time now:
>
> On Mon, May 7, 2012 at 5:25 PM, Jack Vogel wrote:
> > Packets are missed when the receive FIFO has insufficient space to store
> the
> > incoming packet.
>
> This mean
Hm, I guess I can't read. It was bwn, not bwi. Working now.
On Mon, May 7, 2012 at 5:57 PM, Adam Vande More wrote:
> I have a laptop trying to install on. This appears to be the only hangup:
>
> none1@pci0:4:0:0: class=0x028000 card=0x000c1028 chip=0x431514e4
> rev=0x01 hdr=0x00
> ve
While we're on the subject, I've had some confusion for some time now:
On Mon, May 7, 2012 at 5:25 PM, Jack Vogel wrote:
> Packets are missed when the receive FIFO has insufficient space to store the
> incoming packet.
This means the on-card FIFO, i.e. the fixed-size FIFO that is divided
into re
This is 'missed packet count', the index has actually been misinterpreted
in the
code for a while, it was mistakenly associated with queues, but its really
per
packet buffer, and there are only more than one when there are multiple
traffic
classes (ala DCB). Even so, only MPC(0) should get incremen
Hi, a question for jfv@ or whoever else is familiar with the ixgbe
driver - I am looking at a system where the adapter reports a large
number of ierrors that I traced to this stat. What does this mean?
Intuitively it seems like the receive ring isn't being drained fast
enough but wanted to confirm
I have a laptop trying to install on. This appears to be the only hangup:
none1@pci0:4:0:0: class=0x028000 card=0x000c1028 chip=0x431514e4
rev=0x01 hdr=0x00
vendor = 'Broadcom Corporation'
device = 'BCM4312 802.11b/g LP-PHY'
class = network
>From what I can tell, b
Old Synopsis: IP fragment reassembly's broken: file transfer over NFSv3/UDP
fails for default NFS packet size
New Synopsis: [ip] IP fragment reassembly's broken: file transfer over
NFSv3/UDP fails for default NFS packet size
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Chan
Old Synopsis: IPv6 TCP connection hangs/drops when time/clock on the client is
stepped backwards
New Synopsis: [ip6] IPv6 TCP connection hangs/drops when time/clock on the
client is stepped backwards
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsib
.. I think you're misunderstanding how PMTU discovery works.
The _point_ is that you refuse to send said frame in the first place.
Any number of intermediary L2 devices may decide to drop your jumbo
TX'ed frame and not generate an ICMP error message, thus breaking PMTU
discovery anyway.
In any ca
On Friday, May 04, 2012 6:18:19 pm Konstantin Belousov wrote:
> On Fri, May 04, 2012 at 11:30:22AM -0400, John Baldwin wrote:
> > On Tuesday, May 01, 2012 12:21:21 pm Konstantin Belousov wrote:
> > > On Thu, Apr 12, 2012 at 09:38:49PM +0300, Konstantin Belousov wrote:
> > > > On Mon, Apr 09, 2012 a
Synopsis: [em] [lagg] Problem on 8.0-STABLE with em and lagg
Responsible-Changed-From-To: net->freebsd-net
Responsible-Changed-By: jhb
Responsible-Changed-When: Mon May 7 14:02:11 UTC 2012
Responsible-Changed-Why:
Make responsible canonical.
http://www.freebsd.org/cgi/query-pr.cgi?pr=142518
Note: to view an individual PR, use:
http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).
The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.
S Tracker
Note: to view an individual PR, use:
http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).
The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.
S Tracker
16 matches
Mail list logo