64K is the max, and I believe that is taking into account the headers.
What size are you seeing that is larger? Even if an mbuf chain comes
down that large, it does NOT form a single packet, it is packetized by
the hardware into MTU size, as I said, on the wire, ie as the receiver
sees it, its ju
On 2/25/07, Kip Macy <[EMAIL PROTECTED]> wrote:
The stack will send down chains where pkthdr.len > 65536 bytes - I'm
also seeing it send down mbuf chains of 66 mbufs or more. I don't
think all cards can handle an arbitrary number of descriptors being
used for a single packet.
64K is the max, a
On 2/25/07, Andre Oppermann <[EMAIL PROTECTED]> wrote:
Kip Macy wrote:
> On 2/25/07, Andre Oppermann <[EMAIL PROTECTED]> wrote:
>> Kip Macy wrote:
>> > Evidently FreeBSD violates the LSO spec by sending down up to socket
>> > buffer sized TSO segments to the network card. Is there a way to set
>>
LSO is MicroSlop's term for TSO :) As usual, they rename it, and
next they do something non-standard to er 'differentiate' as the
euphemism goes...
Kinda what Sun's lawsuit back in the 90s against their Java
strategy was all about :)
Nevertheless, I don't understand Kip either, when we do TSO th
Sam Leffler recently added a new entry in -CURRENT for the part. I
think the change needs to MFC'd. Perhaps someone (Max?) could do that.
-Kip
On 2/25/07, Vincent Howell <[EMAIL PROTECTED]> wrote:
Hello,
I'm trying to get my Broadcom (BCM43XX-based) WNIC working in FreeBSD 6.2 but
am un
Hello,
I'm trying to get my Broadcom (BCM43XX-based) WNIC working in FreeBSD 6.2 but
am unsuccessful.
I've tried numerous Windows drivers with Ndisgen and none of them generate
working kernel modules. I've tried csuping my install to 6.2-STABLE to get the
latest NDIS patch (produced by someone
Hello.
I posted the following message to questions and Kris (which I thank)
kindly suggested I should ask here wether someone is working on this.
I'll also forward it for inclusion on the list at
http://sources.zabbadoz.net/freebsd/lor.html.
BTW, I don't think the hangs I'm experiencing depen
Whups. That needs 'int s' or the spl calls removed.
I am under the weather today (dry flu type virus)...
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Synopsis: [netisr] suggestion to fix suboptimal network polling
State-Changed-From-To: feedback->open
State-Changed-By: bms
State-Changed-When: Sun Feb 25 16:18:13 UTC 2007
State-Changed-Why:
Back to the net pool
Responsible-Changed-From-To: bms->net
Responsible-Changed-By: bms
Responsible-Chan
Hi,
Please try the attached patch which should hopefully fix this issue
(untested).
Regards,
BMS
? .swp
Index: if_pfsync.c
===
RCS file: /home/ncvs/src/sys/contrib/pf/net/if_pfsync.c,v
retrieving revision 1.32
diff -u -p -r1.3
Kip Macy wrote:
On 2/25/07, Andre Oppermann <[EMAIL PROTECTED]> wrote:
Kip Macy wrote:
> Evidently FreeBSD violates the LSO spec by sending down up to socket
> buffer sized TSO segments to the network card. Is there a way to set
> this other than reducing net.inet.tcp.sendbuf_max to a compliant
Kip Macy wrote:
Evidently FreeBSD violates the LSO spec by sending down up to socket
buffer sized TSO segments to the network card. Is there a way to set
this other than reducing net.inet.tcp.sendbuf_max to a compliant value
(64k)? And is there a way to for a device to communicate to the stack
th
On 2/25/07, Andre Oppermann <[EMAIL PROTECTED]> wrote:
Kip Macy wrote:
> Evidently FreeBSD violates the LSO spec by sending down up to socket
> buffer sized TSO segments to the network card. Is there a way to set
> this other than reducing net.inet.tcp.sendbuf_max to a compliant value
> (64k)? An
Yes, Im not surprised really,
New PCI DEVICE ID's is used all the time. The "Sun Ultra 20 M2" is
just a few months old.
Its a new motherboard compared to the "Sun Ultra20" which has been
around for a year and is already obsolete.
Maybe the real question is:
When any new Motherboar
14 matches
Mail list logo
