> cxgb's silicon supports TSO+IPv6, so I'm not sure why things are the
> way they are. If the stack's tso6 works, then this is a bug in
> cxgb.
>
It may not have supported it when the driver was ported - I know it
didn't do v6 RSS.
-Kip
___
freebsd-net
Synopsis: [fxp] fxp(4) driver failed to initialize device Intel 82801DB
Responsible-Changed-From-To: freebsd-net->yongari
Responsible-Changed-By: yongari
Responsible-Changed-When: Sat Jun 13 01:11:35 UTC 2009
Responsible-Changed-Why:
Grab.
http://www.freebsd.org/cgi/query-pr.cgi?pr=125195
__
Michael Tuexen wrote:
> I'm not sure if we need additional IFCAP_RXCSUM6 IFCAP_TXCSUM6
> capabilities... Why would we want to enable IPv4 offloading and
> not IPv6 or vice versa?
I'd assume that some older hardware supports IPv4 offloads, but
might not have support for IPv6 offloads.
Drew
_
On Jun 12, 2009, at 12:56 PM, Bjoern A. Zeeb wrote:
On Fri, 12 Jun 2009, Pyun YongHyeon wrote:
Hi,
Yeah, there are no checksum offloading support for IPv6 under
FreeBSD so there are no cases the frames are IPv6 when
CSUM_IP/CSUM_TCP/CSUM_UDP/CSUM_TSO was set.
The thing that scared me was s
The following reply was made to PR kern/125195; it has been noted by GNATS.
From: Ted Mittelstaedt
To: bug-follo...@freebsd.org, francisgendr...@videotron.ca
Cc:
Subject: Re: kern/125195: [fxp] fxp(4) driver failed to initialize device
Intel 82801DB
Date: Fri, 12 Jun 2009 13:07:50 -0700
Some
On Fri, 12 Jun 2009, Navdeep Parhar wrote:
Hi,
cxgb(4)
will not let you enable IFCAP_TSO6 on the interface. It has always
been disallowed as far as I can tell.
Yes, you have it in the logic bu you define it to 0;)
#define IFCAP_TSO6 0x0
Not quite. TSO_SUPPORTED is defined and so c
On Fri, 12 Jun 2009, Andrew Gallatin wrote:
Bjoern A. Zeeb wrote:
On Fri, 12 Jun 2009, Navdeep Parhar wrote:
On Fri, Jun 12, 2009 at 10:56:31AM +, Bjoern A. Zeeb wrote:
On Fri, 12 Jun 2009, Pyun YongHyeon wrote:
Hi,
Yeah, there are no checksum offloading support for IPv6 under
FreeBSD
On Fri, Jun 12, 2009 at 05:38:46PM +, Bjoern A. Zeeb wrote:
> On Fri, 12 Jun 2009, Navdeep Parhar wrote:
>
> >On Fri, Jun 12, 2009 at 10:56:31AM +, Bjoern A. Zeeb wrote:
> >>On Fri, 12 Jun 2009, Pyun YongHyeon wrote:
> >>
> >>Hi,
> >>
> >>>Yeah, there are no checksum offloading support for
Bjoern A. Zeeb wrote:
>>> if there is no INET there should be no LRO for now, the capabilities
>>> not advertised, etc. Be prepared in case LRO will arrive for IPv6.
>>
>> As to LRO & IPV6... I was going to port our LRO for IPv6,
>> but discovered the state of IPv6 in FreeBSD is so disgraceful
>
Bjoern A. Zeeb wrote:
On Fri, 12 Jun 2009, Navdeep Parhar wrote:
On Fri, Jun 12, 2009 at 10:56:31AM +, Bjoern A. Zeeb wrote:
On Fri, 12 Jun 2009, Pyun YongHyeon wrote:
Hi,
Yeah, there are no checksum offloading support for IPv6 under
FreeBSD so there are no cases the frames are IPv6 whe
On Fri, 12 Jun 2009, Andrew Gallatin wrote:
Hi,
Bjoern A. Zeeb wrote:
if_mxge:
mxge_rx_csum() has one in_pseudo(). The function and callers
already seem to know how do deal with results in case the csum can't
be validated. So this should be a simple #i
On Fri, 12 Jun 2009, Andrew Gallatin wrote:
Bjoern A. Zeeb wrote:
As a sort of side-note, what about feature parity for INET6 for
existing IPV4 features like TSO? Who is working on that?
Ok, maybe we should write down the big list now. What all can we have?
What do we already have? What do
On Fri, 12 Jun 2009, Navdeep Parhar wrote:
On Fri, Jun 12, 2009 at 10:56:31AM +, Bjoern A. Zeeb wrote:
On Fri, 12 Jun 2009, Pyun YongHyeon wrote:
Hi,
Yeah, there are no checksum offloading support for IPv6 under
FreeBSD so there are no cases the frames are IPv6 when
CSUM_IP/CSUM_TCP/CSUM
I wanted to circulate a document from our technical marketing group that
details a problem with the family of
adapters called ES2LAN. These are most commonly seen as LOMs (on
motherboard) in SuperMicro and
other servers, the most common device ID is 0x1096 but also may be 0x1098,
0x10BA, or 0x10BB.
On Fri, Jun 12, 2009 at 10:56:31AM +, Bjoern A. Zeeb wrote:
> On Fri, 12 Jun 2009, Pyun YongHyeon wrote:
>
> Hi,
>
> >Yeah, there are no checksum offloading support for IPv6 under
> >FreeBSD so there are no cases the frames are IPv6 when
> >CSUM_IP/CSUM_TCP/CSUM_UDP/CSUM_TSO was set.
>
> The
(apologies if this is the second copy you get, I've been having
email issues)
Bjoern A. Zeeb wrote:
>> As a sort of side-note, what about feature parity for INET6 for
>> existing IPV4 features like TSO? Who is working on that?
>
> Ok, maybe we should write down the big list now. What all can we
Bjoern A. Zeeb wrote:
if_mxge:
mxge_rx_csum() has one in_pseudo(). The function and callers
already seem to know how do deal with results in case the csum can't
be validated. So this should be a simple #ifdef INET wrapping here;
side note: the tcpudp_csum
Bjoern A. Zeeb wrote:
As a sort of side-note, what about feature parity for INET6 for
existing IPV4 features like TSO? Who is working on that?
Ok, maybe we should write down the big list now. What all can we have?
What do we already have? What do we need? What needs to be changed?
IPv4 CSUM
On Fri, 12 Jun 2009, Pyun YongHyeon wrote:
Hi,
Yeah, there are no checksum offloading support for IPv6 under
FreeBSD so there are no cases the frames are IPv6 when
CSUM_IP/CSUM_TCP/CSUM_UDP/CSUM_TSO was set.
The thing that scared me was sys/netinet/tcp_subr.c:tcp_maxmtu6().
What I had missed
The following reply was made to PR kern/135222; it has been noted by GNATS.
From: Michael
To: Cc: freebsd-gnats-sub...@freebsd.org
Subject: Re: kern/135222: [igb] low speed routing between two igb interfaces
Date: Fri, 12 Jun 2009 11:45:47 +0200
The original poster reported that the suggested f
Synopsis: [fxp] no wol capability in fxp-driver for 82801-based chipset after
upgrade to 7.2 [regression]
State-Changed-From-To: open->feedback
State-Changed-By: yongari
State-Changed-When: Fri Jun 12 07:32:18 UTC 2009
State-Changed-Why:
Would you try the following patch and let me know how it g
21 matches
Mail list logo
