Old Synopsis: tcp_lro_rx() should make use of hardware IP cksum assistance when
available
New Synopsis: [netinet] [patch] tcp_lro_rx() should make use of hardware IP
cksum assistance when available
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible
> We are still missing other things I think not mentioned elswhere like
> partial checksum recalculation.
Please send me your specific issues; I haven't seen any comments about
"partial checksum recalculations".
I've never heard of this term used before with regard to NAT-T ( and
neither has
> I noticed this too. But the only situation that I could think of where a
> valid ISAKMP packet will be smaller than this is a NAT-T keep-alive.
> These are handled previously in the code path so I don't think there is
> an issue from a functional standpoint.
That's what I also supposed when I n
On Mon, Jul 21, 2008 at 10:36:34PM +, Jens Rehsack wrote:
> Brooks Davis wrote:
>> On Mon, Jul 21, 2008 at 09:30:39PM +, Jens Rehsack wrote:
>>> Brooks Davis wrote:
> Hi,
>
> maybe this question is better asked in this list ...
>
> I was searching why ports/net/p5-Net-
Brooks Davis wrote:
On Mon, Jul 21, 2008 at 09:30:39PM +, Jens Rehsack wrote:
Brooks Davis wrote:
Hi,
maybe this question is better asked in this list ...
I was searching why ports/net/p5-Net-Interface was not working as
expected and found some reasons. Most of them I can answer by implem
On Mon, Jul 21, 2008 at 09:30:39PM +, Jens Rehsack wrote:
> Brooks Davis wrote:
>>> Hi,
>>>
>>> maybe this question is better asked in this list ...
>>>
>>> I was searching why ports/net/p5-Net-Interface was not working as
>>> expected and found some reasons. Most of them I can answer by impl
Brooks Davis wrote:
Hi,
maybe this question is better asked in this list ...
I was searching why ports/net/p5-Net-Interface was not working as
expected and found some reasons. Most of them I can answer by implementing
some test code as attached, but now I'm wondering why em0 is shown twice
and
On Mon, Jul 21, 2008 at 10:36 AM, David Christensen
<[EMAIL PROTECTED]> wrote:
> I'm working on implementing multi-queue support for a 10Gb
> device on FreeBSD and I wanted to find out the current state
> of the OS with regards to supporting this. It seems that
> support for multiple receive queue
> Hi,
>
> maybe this question is better asked in this list ...
>
> I was searching why ports/net/p5-Net-Interface was not working as
> expected and found some reasons. Most of them I can answer by implementing
> some test code as attached, but now I'm wondering why em0 is shown twice
> and lo0 is
Hi,
maybe this question is better asked in this list ...
I was searching why ports/net/p5-Net-Interface was not working as
expected and found some reasons. Most of them I can answer by implementing
some test code as attached, but now I'm wondering why em0 is shown twice
and lo0 is not included.
On Mon, 21 Jul 2008, Sam Leffler wrote:
Hi Sam,
We are still missing other things I think not mentioned elswhere like
partial checksum recalculation.
Please send me your specific issues; I haven't seen any comments about
"partial checksum recalculations".
So what has kept you from reading
On Mon, Jul 21, 2008 at 01:27:05PM -0500, Matthew Grooms wrote:
> On Mon, Jul 21, 2008 at 10:31:10AM +0200, VANHULLEBUS Yvan wrote:
>>
>> After some more testing, I found another issue: in udp4_espdecap(),
>> when payload <= sizeof(uint64_t) + sizeof(struct esp), packet should
>> not be discarded,
On Mon, Jul 21, 2008 at 10:31:10AM +0200, VANHULLEBUS Yvan wrote:
After some more testing, I found another issue: in udp4_espdecap(),
when payload <= sizeof(uint64_t) + sizeof(struct esp), packet should
not be discarded, but just returned for normal processing.
I noticed this too. But the onl
I'm working on implementing multi-queue support for a 10Gb
device on FreeBSD and I wanted to find out the current state
of the OS with regards to supporting this. It seems that
support for multiple receive queues can be done today since
most of the routing is done in hardware but the transmit
side
VANHULLEBUS Yvan wrote:
[Larry, I kept you in an explicit CC, even if I guess you suscribed to
the list]
On Mon, Jul 21, 2008 at 09:26:15AM +, Bjoern A. Zeeb wrote:
On Wed, 16 Jul 2008, Sam Leffler wrote:
Hi,
Hi.
[...]
My main concern at the moment is the API (pfkey stuff)
VANHULLEBUS Yvan wrote:
On Mon, Jul 21, 2008 at 10:31:10AM +0200, VANHULLEBUS Yvan wrote:
On Wed, Jul 16, 2008 at 09:10:18PM -0700, Sam Leffler wrote:
[...]
Please test/review the following patch against HEAD:
http://people.freebsd.org/~sam/nat_t-20080616.patch
I have tested th
Bjoern A. Zeeb wrote:
On Wed, 16 Jul 2008, Sam Leffler wrote:
Hi,
Please test/review the following patch against HEAD:
http://people.freebsd.org/~sam/nat_t-20080616.patch
This adds only the kernel portion of the NAT-T support; you must
provide the user-level code from another place.
The m
[Larry, I kept you in an explicit CC, even if I guess you suscribed to
the list]
On Mon, Jul 21, 2008 at 09:26:15AM +, Bjoern A. Zeeb wrote:
> On Wed, 16 Jul 2008, Sam Leffler wrote:
>
> Hi,
Hi.
[...]
> My main concern at the moment is the API (pfkey stuff) to userland as
> Yvan had stated
On Mon, Jul 21, 2008 at 10:31:10AM +0200, VANHULLEBUS Yvan wrote:
> On Wed, Jul 16, 2008 at 09:10:18PM -0700, Sam Leffler wrote:
> [...]
> > Please test/review the following patch against HEAD:
> >
> > http://people.freebsd.org/~sam/nat_t-20080616.patch
>
> I have tested the RELENG7 version of th
Old Synopsis: carp stuck in init when using bridge interface
New Synopsis: [carp] [bridge] carp stuck in init when using bridge interface
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: gavin
Responsible-Changed-When: Mon Jul 21 13:53:12 UTC 2008
Responsible-Changed-
On Wed, 16 Jul 2008, Sam Leffler wrote:
Hi,
Please test/review the following patch against HEAD:
http://people.freebsd.org/~sam/nat_t-20080616.patch
This adds only the kernel portion of the NAT-T support; you must provide the
user-level code from another place.
The main difference from the
On Wed, Jul 16, 2008 at 09:10:18PM -0700, Sam Leffler wrote:
[...]
> Please test/review the following patch against HEAD:
>
> http://people.freebsd.org/~sam/nat_t-20080616.patch
I have tested the RELENG7 version of the patch, and it works well.
But I noticed a misplaced #endif at the beginning
22 matches
Mail list logo
