Re: Does FreeBSD have sendmmsg or recvmmsg system calls?

2016-01-13 Thread Konstantin Belousov 
On Tue, Jan 12, 2016 at 04:53:25PM +0200, Boris Astardzhiev wrote:
> Hello again,
> 
> In my spare time I did the following simple libc-only implementation of the
> syscalls.
> I did some tests in a VM adapting these experiments:
> https://blog.cloudflare.com/how-to-receive-a-million-packets/
> 
> Any comments about the diff are greatly appreciated.
Please find below.

This implementation has some strangeness, like NOASM and PSEUDO in makefile,
which I cannot find a purpose for.

Big issue with the implementation is the interposing stuff, why do you
need it at all ?  Is it to correctly handle cancellation, to not fall
into sleepable syscall when previous loop step was cancelled ?

If yes, you _can_ use pthread_testcancel(3) etc in libc.  Libc provides
stubs for them with trivial implementation, which is reset to the real
one if libthr is loaded.  Then you can simplify your patch significantly,
avoiding the need for interposing and writing the loops both in libc and
libthr.

BTW, do you have tests for the cancellation of the new functions ?

Again, the patch lacks man page updates.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Does FreeBSD have sendmmsg or recvmmsg system calls?

2016-01-13 Thread Sepherosa Ziehau 
On Tue, Jan 12, 2016 at 10:53 PM, Boris Astardzhiev
 wrote:
> Hello again,
>
> In my spare time I did the following simple libc-only implementation of the
> syscalls.
> I did some tests in a VM adapting these experiments:
> https://blog.cloudflare.com/how-to-receive-a-million-packets/


On Dragonfly, I could do 1.3Mtrans/s (one trans == 18B UDP reception
and then send back) w/o the {recv,send}mmsg() API on an 4C/8T
ivy-bridge i7 easily.  I think only SO_REUSEPORT and cpu hint (Dfly
has  SO_CPUHINT getsockopt) matter in their test.

Thanks,
sephe


>
> Any comments about the diff are greatly appreciated.
>
> Best regards,
> Boris Astardzhiev
>
> On Fri, Jan 8, 2016 at 7:02 PM, Adrian Chadd  wrote:
>
>> On 8 January 2016 at 03:02, Bruce Evans  wrote:
>> > On Fri, 8 Jan 2016, Adrian Chadd wrote:
>> >
>> >> On 7 January 2016 at 23:58, Mark Delany  wrote:
>> >>>
>> >>> On 08Jan16, Bruce Evans allegedly wrote:
>> 
>>  If the NIC can't reach line rate
>> >>>
>> >>>
>>  Network stack overheads are also enormous.
>> >>>
>> >>>
>> >>> Bruce makes some excellent points.
>> >>>
>> >>> I challenge anyone to get line rate UDP out of FBSD (or Linux) for a
>> >>> 1G NIC yet alone a 10G NIC listening to a single port. It was exactly
>> >>> my frustration with UDP performance that led me down the path of
>> >>> *mmsg() and netmap.
>> >>>
>> >>> Frankly this is an opportunity for FBSD as UDP performance appears to
>> >>> be a neglected area.
>> >>
>> >>
>> >> I'm there, on 16 threads.
>> >>
>> >> I'd rather we do it on two or three, as a lot of time is wasted in
>> >> producer/consumer locking. but yeah, 500k tx/rx should be doable per
>> >> CPU with only locking changes.
>>
>> .. and I did mean "kernel producer/consumer locking changes."
>>
>> >
>> > Line rate for 1 Gbps is about 1500 kpps (small packets).
>> >
>> > With I218V2 (em), I see enormous lock contention above 3 or 4 (user)
>> > threads, and 8 are slightly slower than 1.  1 doesn't saturate the NIC,
>> > and 2 is optimal.
>> >
>>
>> The RSS support in -HEAD lets you get away with parallelising UDP
>> streams very nicely.
>>
>> The framework is pretty simple (!):
>>
>> * drivers ask the RSS code for the RSS config and RSS hash to use, and
>> configure the hardware appropriately;
>> * the netisr input paths check the existence of the RSS hash and will
>> calculte it in software if reqiured;
>> * v4/v6 reassembly is done (at the IP level, /not/ at the protocol
>> level) and if it needs a new RSS hash / netisr reinjection, that'll
>> happen;
>> * the PCB lookup code for listen sockets now allows one listen socket
>> per RSS bucket - as the RSS / PCBGROUPS code already extended the PCB
>> to have one PCB table per RSS bucket (as well as a global one);
>>
>> So:
>>
>> * userland code queries RSS for the CPU and RSS bucket setup;
>> * you then create one listen socket per RSS bucket, bind it to the
>> local thread (if you want) and tell it "you're in RSS bucket X";
>> * .. and then in the UDP case for local-bound sockets, the
>> transmit/receive path does not require modifying the global PCB state,
>> so the locking is kept per-RSS bucket, and scales linearly with the
>> number of CPUs you have (until you hit the NIC queue limits.)
>>
>> https://github.com/erikarn/freebsd-rss/
>>
>> and:
>>
>>
>> http://adrianchadd.blogspot.com/2014/06/hacking-on-receive-side-scaling-rss-on.html
>>
>> http://adrianchadd.blogspot.com/2014/07/application-awareness-of-receive-side.html
>>
>> http://adrianchadd.blogspot.com/2014/08/receive-side-scaling-figuring-out-how.html
>>
>> http://adrianchadd.blogspot.com/2014/09/receive-side-scaling-testing-udp.html
>>
>> http://adrianchadd.blogspot.com/2014/10/more-rss-udp-tests-this-time-on-dell.html
>>
>>
>>
>> -adrian
>> ___
>> freebsd-net@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-net
>> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
>>
>
> ___
> freebsd-net@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"



-- 
Tomorrow Will Never Die
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Kernel panic from lagg_ioctl and lagg_port_ioctl

2016-01-13 Thread Hans Petter Selasky 

On 01/12/16 22:13, Lewis, Fred wrote:

In earlier versions of lagg_ioctl() (e.g. stable/10/r171247) all of the callout
vectors are set to NULL which I think will prevent the problem. Similar NULLing 
code
is also in stable/7. I didn't check other releases.


Don't forget to drain the callouts before NULL-ing them!

--HPS
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Kernel panic from lagg_ioctl and lagg_port_ioctl

2016-01-13 Thread Lakshmi Narasimhan Sundararajan 
Hi Hans,
Yes, we understand that piece of code.

But Panasas wants this change to MFC to 10.3. This issue is not seen in 11.
Would that happen? I have not seen acknowledgement of this issue or
confirmation of MFC to 10.3. That information will help us plan.

Regards,
LN

On Wed, Jan 13, 2016 at 6:02 PM, Hans Petter Selasky 
wrote:

> On 01/12/16 22:13, Lewis, Fred wrote:
>
>> In earlier versions of lagg_ioctl() (e.g. stable/10/r171247) all of the
>> callout
>> vectors are set to NULL which I think will prevent the problem. Similar
>> NULLing code
>> is also in stable/7. I didn't check other releases.
>>
>
> Don't forget to drain the callouts before NULL-ing them!
>
> --HPS
>

-- 


DISCLAIMER

The information in this e-mail is confidential and may be subject to legal 
privilege. It is intended solely for the addressee. Access to this e-mail 
by anyone else is unauthorized. If you have received this communication in 
error, please address with the subject heading "Received in error," send to 
i...@msystechnologies.com,  then delete the e-mail and destroy any copies of 
it. If you are not the intended recipient, any disclosure, copying, 
distribution or any action taken or omitted to be taken in reliance on it, 
is prohibited and may be unlawful. The views, opinions, conclusions and 
other information expressed in this electronic mail and any attachments are 
not given or endorsed by the company unless otherwise indicated by an 
authorized representative independent of this message.
MSys cannot guarantee that e-mail communications are secure or error-free, 
as information could be intercepted, corrupted, amended, lost, destroyed, 
arrive late or incomplete, or contain viruses, though all reasonable 
precautions have been taken to ensure no viruses are present in this e-mail. 
As our company cannot accept responsibility for any loss or damage arising 
from the use of this e-mail or attachments we recommend that you subject 
these to your virus checking procedures prior to use
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Kernel panic from lagg_ioctl and lagg_port_ioctl

2016-01-13 Thread Hans Petter Selasky 

On 01/13/16 14:15, Lewis, Fred wrote:

Hi Hans,

Can you give an example of draining the callouts?



Hi,

man 9 callout_drain

and

man 9 callout_async_drain (11-current)

callout_drain() might sleep and needs a context which allows for that. 
Else use callout_async_drain().


--HPS
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Kernel panic from lagg_ioctl and lagg_port_ioctl

2016-01-13 Thread Lewis, Fred 
Hi Hans,

Can you give an example of draining the callouts?

Thanks,
-Fred

On 1/13/16 7:33 AM, "Lakshmi Narasimhan Sundararajan" 
mailto:lakshm...@msystechnologies.com>> wrote:

Hi Hans,
Yes, we understand that piece of code.

But Panasas wants this change to MFC to 10.3. This issue is not seen in 11. 
Would that happen? I have not seen acknowledgement of this issue or 
confirmation of MFC to 10.3. That information will help us plan.

Regards,
LN

On Wed, Jan 13, 2016 at 6:02 PM, Hans Petter Selasky 
mailto:h...@selasky.org>> wrote:
On 01/12/16 22:13, Lewis, Fred wrote:
In earlier versions of lagg_ioctl() (e.g. stable/10/r171247) all of the callout
vectors are set to NULL which I think will prevent the problem. Similar NULLing 
code
is also in stable/7. I didn't check other releases.

Don't forget to drain the callouts before NULL-ing them!

--HPS



DISCLAIMER

The information in this e-mail is confidential and may be subject to legal 
privilege. It is intended solely for the addressee. Access to this e-mail by 
anyone else is unauthorized. If you have received this communication in error, 
please address with the subject heading "Received in error," send to 
i...@msystechnologies.com,  then delete the 
e-mail and destroy any copies of it. If you are not the intended recipient, any 
disclosure, copying, distribution or any action taken or omitted to be taken in 
reliance on it, is prohibited and may be unlawful. The views, opinions, 
conclusions and other information expressed in this electronic mail and any 
attachments are not given or endorsed by the company unless otherwise indicated 
by an authorized representative independent of this message.

MSys cannot guarantee that e-mail communications are secure or error-free, as 
information could be intercepted, corrupted, amended, lost, destroyed, arrive 
late or incomplete, or contain viruses, though all reasonable precautions have 
been taken to ensure no viruses are present in this e-mail. As our company 
cannot accept responsibility for any loss or damage arising from the use of 
this e-mail or attachments we recommend that you subject these to your virus 
checking procedures prior to use
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

ipfw NAT, igb and hardware checksums

2016-01-13 Thread Karim Fodil-Lemelin 

Hi,

I've hit a very interesting problem with ipfw-nat and local TCP traffic 
that has enough TCP options to hit a special case in m_megapullup(). 
Here is the story:


I am using the following NIC:

igb0@pci0:4:0:0:class=0x02 card=0x8086 chip=0x150e8086 
rev=0x01 hdr=0x00


And when I do ipfw nat to locally emitted packets I see packets not 
being processed in the igb driver for HW checksum. Now a quick search 
for m_pullup in the igb driver code will show that our igb driver 
expects a contiguous ethernet + ip header in igb_tx_ctx_setup(). Now the 
friendly m_megapullup() in alias.c doesn't reserve any space before the 
ip header for the ethernet header after its call to m_getcl like 
tcp_output.c (see m->m_data += max_linkhdr in tcp_output.c).


So the call to M_PREPEND() in ether_output() is forced to prepend a new 
mbuf for the ethernet header, leading to a non contiguous ether + ip. 
This in turn leads to a failure to properly read the IP protocol in the 
igb driver and apply the proper HW checksum function. Particularly this 
call in igb_tcp_ctx_setup(): ip = (struct ip *)(mp->m_data + ehdrlen);


To reproduce the issue I simply create a NAT rule for an igb interface 
and initiate a TCP connection locally going out through that interface 
(it should go through NAT obviously) something like:


ipfw nat 1 config igb0 reset
ipfw add 10 nat 1 via igb0

 Although you need to make sure you fill enough of the SYN packet to 
trigger the allocation of new memory in m_megapullup. You can do this by 
using enough TCP options so its filling up almost all of the 256 mbuf or 
make RESERVE something like 300 bytes in alias.c.


The fix I propose is very simple and faster for all drivers, including 
the ones that do perform a check for ether + ip to be contiguous upon 
accessing the IP header. If the leading space is available it doesn't 
allocate any extra space (as it should for most cases) but if for some 
reason the mbuf used doesn't have 100 bytes (RESERVE in megapullup) of 
free space it will reserve some at the front too. If the leading space 
isn't necessary then it won't cause any harm.



-Subproject commit cfe39807fe9b1a23c13f73aabde302046736fa1c
+Subproject commit cfe39807fe9b1a23c13f73aabde302046736fa1c-dirty
diff --git a/freebsd/sys/netinet/libalias/alias.c 
b/freebsd/sys/netinet/libalias/alias.c

index 876e958..dc424a6 100644
--- a/freebsd/sys/netinet/libalias/alias.c
+++ b/freebsd/sys/netinet/libalias/alias.c
@@ -1757,7 +1757,8 @@ m_megapullup(struct mbuf *m, int len) {
 * writable and has some extra space for expansion.
 * XXX: Constant 100bytes is completely empirical. */
 #defineRESERVE 100
-   if (m->m_next == NULL && M_WRITABLE(m) && M_TRAILINGSPACE(m) >= RESERVE)
+ if (m->m_next == NULL && M_WRITABLE(m) &&
+ M_TRAILINGSPACE(m) >= RESERVE && M_LEADINGSPACE(m) >= 
max_linkhdr)

return (m);

if (len <= MCLBYTES - RESERVE) {
@@ -1779,6 +1780,7 @@ m_megapullup(struct mbuf *m, int len) {
goto bad;

m_move_pkthdr(mcl, m);
+ mcl->m_data += max_linkhdr;
m_copydata(m, 0, len, mtod(mcl, caddr_t));
mcl->m_len = mcl->m_pkthdr.len = len;
m_freem(m);

It would be nice if some FBSD comitter could review and hopefully add 
this patch to FBSD.


Thank you,

Karim.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 203524] TCP checksum failed on igb network adapter

2016-01-13 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203524

fodillemlinka...@gmail.com changed:

   What|Removed |Added

 CC||fodillemlinka...@gmail.com

--- Comment #2 from fodillemlinka...@gmail.com ---
Hi,

I believe I have fixed something like this recently please see a post I just
made:

Hi,

I've hit a very interesting problem with ipfw-nat and local TCP traffic that
has enough TCP options to hit a special case in m_megapullup(). Here is the
story:

I am using the following NIC:

igb0@pci0:4:0:0:class=0x02 card=0x8086 chip=0x150e8086 rev=0x01
hdr=0x00

And when I do ipfw nat to locally emitted packets I see packets not being
processed in the igb driver for HW checksum. Now a quick search for m_pullup in
the igb driver code will show that our igb driver expects a contiguous ethernet
+ ip header in igb_tx_ctx_setup(). Now the friendly m_megapullup() in alias.c
doesn't reserve any space before the ip header for the ethernet header after
its call to m_getcl like tcp_output.c (see m->m_data += max_linkhdr in
tcp_output.c).

So the call to M_PREPEND() in ether_output() is forced to prepend a new mbuf
for the ethernet header, leading to a non contiguous ether + ip. This in turn
leads to a failure to properly read the IP protocol in the igb driver and apply
the proper HW checksum function. Particularly this call in igb_tcp_ctx_setup():
ip = (struct ip *)(mp->m_data + ehdrlen);

To reproduce the issue I simply create a NAT rule for an igb interface and
initiate a TCP connection locally going out through that interface (it should
go through NAT obviously) something like:

ipfw nat 1 config igb0 reset
ipfw add 10 nat 1 via igb0

 Although you need to make sure you fill enough of the SYN packet to trigger
the allocation of new memory in m_megapullup. You can do this by using enough
TCP options so its filling up almost all of the 256 mbuf or make RESERVE
something like 300 bytes in alias.c.

The fix I propose is very simple and faster for all drivers, including the ones
that do perform a check for ether + ip to be contiguous upon accessing the IP
header. If the leading space is available it doesn't allocate any extra space
(as it should for most cases) but if for some reason the mbuf used doesn't have
100 bytes (RESERVE in megapullup) of free space it will reserve some at the
front too. If the leading space isn't necessary then it won't cause any harm.


-Subproject commit cfe39807fe9b1a23c13f73aabde302046736fa1c
+Subproject commit cfe39807fe9b1a23c13f73aabde302046736fa1c-dirty
diff --git a/freebsd/sys/netinet/libalias/alias.c
b/freebsd/sys/netinet/libalias/alias.c
index 876e958..dc424a6 100644
--- a/freebsd/sys/netinet/libalias/alias.c
+++ b/freebsd/sys/netinet/libalias/alias.c
@@ -1757,7 +1757,8 @@ m_megapullup(struct mbuf *m, int len) {
 * writable and has some extra space for expansion.
 * XXX: Constant 100bytes is completely empirical. */
 #defineRESERVE 100
-   if (m->m_next == NULL && M_WRITABLE(m) && M_TRAILINGSPACE(m) >= RESERVE)
+ if (m->m_next == NULL && M_WRITABLE(m) &&
+ M_TRAILINGSPACE(m) >= RESERVE && M_LEADINGSPACE(m) >=
max_linkhdr)
return (m);

if (len <= MCLBYTES - RESERVE) {
@@ -1779,6 +1780,7 @@ m_megapullup(struct mbuf *m, int len) {
goto bad;

m_move_pkthdr(mcl, m);
+ mcl->m_data += max_linkhdr;
m_copydata(m, 0, len, mtod(mcl, caddr_t));
mcl->m_len = mcl->m_pkthdr.len = len;
m_freem(m);

It would be nice if some FBSD comitter could review and hopefully add this
patch to FBSD.

Thank you,

Karim.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: ipfw NAT, igb and hardware checksums

2016-01-13 Thread Adrian Chadd 
This looks mostly sensible. hm!



-a


On 13 January 2016 at 11:55, Karim Fodil-Lemelin
 wrote:
> Hi,
>
> I've hit a very interesting problem with ipfw-nat and local TCP traffic that
> has enough TCP options to hit a special case in m_megapullup(). Here is the
> story:
>
> I am using the following NIC:
>
> igb0@pci0:4:0:0:class=0x02 card=0x8086 chip=0x150e8086
> rev=0x01 hdr=0x00
>
> And when I do ipfw nat to locally emitted packets I see packets not being
> processed in the igb driver for HW checksum. Now a quick search for m_pullup
> in the igb driver code will show that our igb driver expects a contiguous
> ethernet + ip header in igb_tx_ctx_setup(). Now the friendly m_megapullup()
> in alias.c doesn't reserve any space before the ip header for the ethernet
> header after its call to m_getcl like tcp_output.c (see m->m_data +=
> max_linkhdr in tcp_output.c).
>
> So the call to M_PREPEND() in ether_output() is forced to prepend a new mbuf
> for the ethernet header, leading to a non contiguous ether + ip. This in
> turn leads to a failure to properly read the IP protocol in the igb driver
> and apply the proper HW checksum function. Particularly this call in
> igb_tcp_ctx_setup(): ip = (struct ip *)(mp->m_data + ehdrlen);
>
> To reproduce the issue I simply create a NAT rule for an igb interface and
> initiate a TCP connection locally going out through that interface (it
> should go through NAT obviously) something like:
>
> ipfw nat 1 config igb0 reset
> ipfw add 10 nat 1 via igb0
>
>  Although you need to make sure you fill enough of the SYN packet to trigger
> the allocation of new memory in m_megapullup. You can do this by using
> enough TCP options so its filling up almost all of the 256 mbuf or make
> RESERVE something like 300 bytes in alias.c.
>
> The fix I propose is very simple and faster for all drivers, including the
> ones that do perform a check for ether + ip to be contiguous upon accessing
> the IP header. If the leading space is available it doesn't allocate any
> extra space (as it should for most cases) but if for some reason the mbuf
> used doesn't have 100 bytes (RESERVE in megapullup) of free space it will
> reserve some at the front too. If the leading space isn't necessary then it
> won't cause any harm.
>
>
> -Subproject commit cfe39807fe9b1a23c13f73aabde302046736fa1c
> +Subproject commit cfe39807fe9b1a23c13f73aabde302046736fa1c-dirty
> diff --git a/freebsd/sys/netinet/libalias/alias.c
> b/freebsd/sys/netinet/libalias/alias.c
> index 876e958..dc424a6 100644
> --- a/freebsd/sys/netinet/libalias/alias.c
> +++ b/freebsd/sys/netinet/libalias/alias.c
> @@ -1757,7 +1757,8 @@ m_megapullup(struct mbuf *m, int len) {
>  * writable and has some extra space for expansion.
>  * XXX: Constant 100bytes is completely empirical. */
>  #defineRESERVE 100
> -   if (m->m_next == NULL && M_WRITABLE(m) && M_TRAILINGSPACE(m) >= RESERVE)
> + if (m->m_next == NULL && M_WRITABLE(m) &&
> + M_TRAILINGSPACE(m) >= RESERVE && M_LEADINGSPACE(m) >=
> max_linkhdr)
> return (m);
>
> if (len <= MCLBYTES - RESERVE) {
> @@ -1779,6 +1780,7 @@ m_megapullup(struct mbuf *m, int len) {
> goto bad;
>
> m_move_pkthdr(mcl, m);
> + mcl->m_data += max_linkhdr;
> m_copydata(m, 0, len, mtod(mcl, caddr_t));
> mcl->m_len = mcl->m_pkthdr.len = len;
> m_freem(m);
>
> It would be nice if some FBSD comitter could review and hopefully add this
> patch to FBSD.
>
> Thank you,
>
> Karim.
> ___
> freebsd-net@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: ipfw NAT, igb and hardware checksums

2016-01-13 Thread Alexander V . Chernikov 
13.01.2016, 22:56, "Karim Fodil-Lemelin" :
> Hi,
>
> I've hit a very interesting problem with ipfw-nat and local TCP traffic
> that has enough TCP options to hit a special case in m_megapullup().
> Here is the story:
>
> I am using the following NIC:
>
> igb0@pci0:4:0:0: class=0x02 card=0x8086 chip=0x150e8086
> rev=0x01 hdr=0x00
>
> And when I do ipfw nat to locally emitted packets I see packets not
> being processed in the igb driver for HW checksum. Now a quick search
> for m_pullup in the igb driver code will show that our igb driver
> expects a contiguous ethernet + ip header in igb_tx_ctx_setup(). Now the
> friendly m_megapullup() in alias.c doesn't reserve any space before the
> ip header for the ethernet header after its call to m_getcl like
> tcp_output.c (see m->m_data += max_linkhdr in tcp_output.c).
>
> So the call to M_PREPEND() in ether_output() is forced to prepend a new
> mbuf for the ethernet header, leading to a non contiguous ether + ip.
> This in turn leads to a failure to properly read the IP protocol in the
> igb driver and apply the proper HW checksum function. Particularly this
> call in igb_tcp_ctx_setup(): ip = (struct ip *)(mp->m_data + ehdrlen);
Thanks for the detailed explanation. Looks reasonable. I'll do several more 
tests on that and commit.
>
> It would be nice if some FBSD comitter could review and hopefully add
> this patch to FBSD.
>
> Thank you,
>
> Karim.
> ___
> freebsd-net@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 206186] [patch][netgraph] New netgraph node for calculate IP IP6 TCP UDP checksums

2016-01-13 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206186

Mark Linimon  changed:

   What|Removed |Added

   Assignee|freebsd-b...@freebsd.org|freebsd-net@FreeBSD.org

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 206185] [netgraph][patch] refactoring ng_patch

2016-01-13 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206185

Mark Linimon  changed:

   What|Removed |Added

   Assignee|freebsd-b...@freebsd.org|freebsd-net@FreeBSD.org

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"