Status|New |Open
Summary|[vtnet] [regression]: |vtnet: Checksum offloading
|checksum offloading is |enabled reduces pf NAT
|suppressing pf NAT |performance (~100mbps
> On 16 Jun 2016, at 08:40, Dominik Schoeffmann wrote:
>
> Is the checksum offloading patch for the igb(4) driver available online?
> (I could not find it)
> I would really like to take a look at it, espacially the context
> descriptor part of it.
I would also be interested in
Is the checksum offloading patch for the igb(4) driver available online?
(I could not find it)
I would really like to take a look at it, espacially the context
descriptor part of it.
Best regards,
Dominik
On 16.06.2016 02:04, Jim Thompson wrote:
>
> Luiz Otavio O Souza (loos@) developed
ly offload checksums for different kinds
> of packets (IPv4, UDP, TCP).
> The ixgbe netmap patch was modified [2] in order to construct context
> descriptors and suitable data descriptors. This is implemented in less
> than 250 LoC (including pseudo-header calculations).
> The man
rator
>>> called MoonGen [1] in order to utilize netmap.
>>> One key component was to flexibly offload checksums for different kinds
>>> of packets (IPv4, UDP, TCP).
>>> The ixgbe netmap patch was modified [2] in order to construct context
>>> descriptors a
gt; One key component was to flexibly offload checksums for different kinds
>> of packets (IPv4, UDP, TCP).
>> The ixgbe netmap patch was modified [2] in order to construct context
>> descriptors and suitable data descriptors. This is implemented in less
>> than 250 LoC (includi
s is implemented in less
> than 250 LoC (including pseudo-header calculations).
> The man page states, that checksum offloading is available via ethtool,
> although a solution inside the netmap API might be a cleaner way for
> applications to actually use these features.
> Attached i
er to construct context
descriptors and suitable data descriptors. This is implemented in less
than 250 LoC (including pseudo-header calculations).
The man page states, that checksum offloading is available via ethtool,
although a solution inside the netmap API might be a cleaner way for
applicatio
This revision was automatically updated to reflect the committed changes.
Closed by commit rS295793: hyperv/hn: Enable IP header checksum offloading for
WIN8 (WinServ2012) (authored by sephe).
CHANGED PRIOR TO COMMIT
https://reviews.freebsd.org/D5317?vs=13408&id=13481#toc
REPOSITORY
adrian accepted this revision.
This revision has a positive review.
REVISION DETAIL
https://reviews.freebsd.org/D5317
EMAIL PREFERENCES
https://reviews.freebsd.org/settings/panel/emailpreferences/
To: sepherosa_gmail.com, delphij, royger, decui_microsoft.com,
honzhan_microsoft.com, howard0s
/hv_netvsc_drv_freebsd.c
+++ b/sys/dev/hyperv/netvsc/hv_netvsc_drv_freebsd.c
@@ -176,7 +176,7 @@
* later. UDP checksum offloading doesn't work on earlier
* Windows releases.
*/
-#define HN_CSUM_ASSIST_WIN8 (CSUM_TCP)
+#define HN_CSUM_ASSIST_WIN8 (CSUM_IP | CSUM_TCP)
#d
This revision was automatically updated to reflect the committed changes.
Closed by commit rS295298: hyperv/hn: Enable IP header checksum offloading
(authored by sephe).
CHANGED PRIOR TO COMMIT
https://reviews.freebsd.org/D5099?vs=12775&id=13032#toc
REPOSITORY
rS FreeBSD src reposi
sepherosa_gmail.com created this revision.
sepherosa_gmail.com added reviewers: network, adrian, delphij, royger,
decui_microsoft.com, honzhan_microsoft.com, howard0su_gmail.com.
sepherosa_gmail.com added a subscriber: freebsd-net-list.
REVISION SUMMARY
- TCP/IP stack will not do unnecessary IP
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=170081
Kristof Provost changed:
What|Removed |Added
CC||k...@freebsd.org
Sta
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=170081
alucard...@gmail.com changed:
What|Removed |Added
CC||alucard...@gmail.com
--- Com
On 13 May 2014, at 07:21, Yonghyeon PYUN wrote:
> On Mon, May 12, 2014 at 01:22:03PM +0200, Michael Tuexen wrote:
>> On 12 May 2014, at 03:36, Yonghyeon PYUN wrote:
>>
>>> On Fri, May 09, 2014 at 12:46:48PM +0200, Michael Tuexen wrote:
On 09 May 2014, at 03:35, Yonghyeon PYUN wrote:
014, at 03:47, Yonghyeon PYUN wrote:
>>>>
>>>>> On Thu, May 08, 2014 at 08:50:48PM +0200, Michael Tuexen wrote:
>>>>>> Dear all,
>>>>>>
>>>>>> while testing checksum offloading of UDP packets over IP with IP
>>>
; On Thu, May 08, 2014 at 08:50:48PM +0200, Michael Tuexen wrote:
> >>>> Dear all,
> >>>>
> >>>> while testing checksum offloading of UDP packets over IP with IP
> >>>> options, I figured
> >>>> out that my card
> >>&g
On Mon, May 12, 2014 at 01:22:03PM +0200, Michael Tuexen wrote:
> On 12 May 2014, at 03:36, Yonghyeon PYUN wrote:
>
> > On Fri, May 09, 2014 at 12:46:48PM +0200, Michael Tuexen wrote:
> >> On 09 May 2014, at 03:35, Yonghyeon PYUN wrote:
> >>
[...]
> > Oops, sorry. You're right. Probably I wa
_data and the flag CSUM_DATA_VALID is set. This
>>>>>>>>>>> happens
>>>>>>>>>>> for all IP packets, not only for UDP and TCP packets.
>>>>>>>>>>> 2. In case of SCTP packets, the SCTP interprets CSUM_DAT
se of SCTP packets, the SCTP interprets CSUM_DATA_VALID as
>>>>>>>>> CSUM_SCTP_VALID
>>>>>>>>> and accepts the packet. So no SCTP checksum check ever happened.
>>>>>>>>>
>>>>>>>>> Altern
;>>>> Alternatives to fix this:
>>>>>>>>
>>>>>>>> 1. Change all drivers to set CSUM_DATA_VALID only in case of UDP or
>>>>>>>> TCP packets, since
>>>>>>>> it only makes sense in these cases
On 09 May 2014, at 03:47, Yonghyeon PYUN wrote:
> On Thu, May 08, 2014 at 08:50:48PM +0200, Michael Tuexen wrote:
>> Dear all,
>>
>> while testing checksum offloading of UDP packets over IP with IP options, I
>> figured
>> out that my card
>>
>> de
On Thu, May 08, 2014 at 08:50:48PM +0200, Michael Tuexen wrote:
> Dear all,
>
> while testing checksum offloading of UDP packets over IP with IP options, I
> figured
> out that my card
>
> dev.re.1.%desc: RealTek 8168/8111 B/C/CP/D/DP/E/F/G PCIe Gigabit Ethernet
> dev.r
t; TCP packets, since
> >>>>>> it only makes sense in these cases.
> >>>>>
> >>>>> Wait, or for SCTP in cad the crc32 (I think it was) was actually
> >>>>> checked but not otherwise. This is how it should be imho. It seems
>
Dear all,
while testing checksum offloading of UDP packets over IP with IP options, I
figured
out that my card
dev.re.1.%desc: RealTek 8168/8111 B/C/CP/D/DP/E/F/G PCIe Gigabit Ethernet
dev.re.1.%driver: re
dev.re.1.%location: slot=0 function=0 handle=\_SB_.PCI0.PE1F.LAN2
dev.re.1.%pnpinfo
>>
>>>>> Wait, or for SCTP in cad the crc32 (I think it was) was actually checked
>>>>> but not otherwise. This is how it should be imho. It seems like a
>>>>> driver bug.
>>>> I went through the list of drivers and you are ri
gt;>> packets, since
> >>>> it only makes sense in these cases.
> >>>
> >>> Wait, or for SCTP in cad the crc32 (I think it was) was actually checked
> >>> but not otherwise. This is how it should be imho. It seems like a
> >>>
the list of drivers and you are right, it seems to be a bug
>> in if_smsc.c. Most of the other drivers check for UDP/TCP, a small set I
>> can't tell.
>>
>
> I'm not sure how the controller computes TCP/UDP checksum values.
> It seems the publicly available d
This is how it should be imho. It seems like a driver
> > bug.
> I went through the list of drivers and you are right, it seems to be a bug
> in if_smsc.c. Most of the other drivers check for UDP/TCP, a small set I
> can't tell.
>
I'm not sure how the controller comp
On 02 May 2014, at 16:02, Bjoern A. Zeeb wrote:
>
> On 02 May 2014, at 10:22 , Michael Tuexen
> wrote:
>
>> Dear all,
>>
>> during testing I found that FreeBSD head (on a raspberry pi) accepts SCTP
>> packet
>> with bad checksums. After debugging this I figured out that this is a
>> proble
On 02 May 2014, at 16:02, Bjoern A. Zeeb wrote:
>
> On 02 May 2014, at 10:22 , Michael Tuexen
> wrote:
>
>> Dear all,
>>
>> during testing I found that FreeBSD head (on a raspberry pi) accepts SCTP
>> packet
>> with bad checksums. After debugging this I figured out that this is a
>> proble
On 02 May 2014, at 10:22 , Michael Tuexen
wrote:
> Dear all,
>
> during testing I found that FreeBSD head (on a raspberry pi) accepts SCTP
> packet
> with bad checksums. After debugging this I figured out that this is a problem
> with
> the csum_flags defined in mbuf.h.
>
> The SCTP code on
Dear all,
during testing I found that FreeBSD head (on a raspberry pi) accepts SCTP packet
with bad checksums. After debugging this I figured out that this is a problem
with
the csum_flags defined in mbuf.h.
The SCTP code on its input path checks for CSUM_SCTP_VALID, which is defined in
mbuf.h:
The following reply was made to PR kern/170081; it has been noted by GNATS.
From: Johan Broman
To: bug-follo...@freebsd.org, h.sku...@gmail.com
Cc:
Subject: Re: kern/170081: [fxp] pf/nat/jails not working if checksum
offloading is enabled on fxp0
Date: Fri, 12 Apr 2013 10:30:50 +0200
Old Synopsis: pf/nat/jails not working if checksum offloading is enabled on fxp0
New Synopsis: [fxp] pf/nat/jails not working if checksum offloading is enabled
on fxp0
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Mon Jul 23
yzing how TCP/UDP checksum offloading works
> > to find the best way to add SCTP checksum offloading.
> >
> > sys/mbuf.h has constants:
> > #define CSUM_IP 0x0001 /* will csum IP */
> > #define CSUM_TCP0x0002
On Sat, Dec 20, 2008 at 10:31:39PM +0100, Michael T?xen wrote:
> Dear all,
>
> I'm currently analyzing how TCP/UDP checksum offloading works
> to find the best way to add SCTP checksum offloading.
>
> sys/mbuf.h has constants:
> #define CSUM_IP
Dear all,
I'm currently analyzing how TCP/UDP checksum offloading works
to find the best way to add SCTP checksum offloading.
sys/mbuf.h has constants:
#define CSUM_IP 0x0001 /* will csum IP */
#define CSUM_TCP0x0002 /* will csum TCP */
#d
um: 0xac18 [incorrect, should be 0xfbc7 (maybe caused by
> > checksum offloading?)]
> >
> > for example.
> >
> > If I understand it more or less correctly, checksum offloading is
> > performed by or with help of the NIC - only for TCP and UDP, where the
>
t; Checksum: 0xac18 [incorrect, should be 0xfbc7 (maybe caused
> > by checksum offloading?)]
> >
> > for example.
>
> Is that for incoming or outgoing packets? If it is for outgoing it is
> perfectly normal and nothing to be worried about (assuming that your
> N
On Wed, Jan 31, 2007 at 09:47:05PM +0100, C?dric Jonas wrote:
> Hi,
>
> I get TCP/UDP checksum errors with fxp(4). I noticed it after using
> Wireshark today:
>
> Checksum: 0xac18 [incorrect, should be 0xfbc7 (maybe caused by
> checksum offloading?)]
>
On Wed, Jan 31, 2007 at 09:47:05PM +0100, Cédric Jonas wrote:
> Hi,
>
> I get TCP/UDP checksum errors with fxp(4). I noticed it after using
> Wireshark today:
>
> Checksum: 0xac18 [incorrect, should be 0xfbc7 (maybe caused by
> checksum offloading?)]
>
>
Hi,
I get TCP/UDP checksum errors with fxp(4). I noticed it after using
Wireshark today:
Checksum: 0xac18 [incorrect, should be 0xfbc7 (maybe caused by
checksum offloading?)]
for example.
If I understand it more or less correctly, checksum offloading is
performed by or with
How does one specify that an mbuf/mbuf-chain needs or doesn't need
to have its IP/TCP checksum calculated?
--
-Alfred Perlstein [[EMAIL PROTECTED]]
Ok, who wrote this damn function called '??'?
And why do my programs keep crashing in it?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "uns
45 matches
Mail list logo
