https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=105943
--- Comment #7 from Ed Maste ---
ip_mloopback:
/*
* Make a deep copy of the packet because we're going to
* modify the pack in order to generate checksums.
*/
copym = m_dup(m, M_NOWAIT);
...
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=105943
Ed Maste changed:
What|Removed |Added
CC||ema...@freebsd.org
--- Comment #6 from
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=105943
Eitan Adler changed:
What|Removed |Added
Status|In Progress |Open
--- Comment #5 from Eitan Adler
t the amount of data in an mbuf chain
submitted to a driver?
To: "Laurie Jennings"
Cc: "FreeBSD Net"
Date: Saturday, May 18, 2013, 9:16 AM
Version numbers result from my work internally, and sometimes they
increment due to a build issue, or a bug found that needs to be correc
te:
>
>
> From: Jack Vogel
> Subject: Re: Is there any way to limit the amount of data in an mbuf chain
> submitted to a driver?
> To: "Laurie Jennings"
> Cc: "FreeBSD Net" , "Adrian Chadd" <
> adr...@freebsd.org>, "Richard Sharpe&quo
Can you outline the changes? Anything with the general processing? I have to
makea case to hold off a deployment.
and what happened to 9, 10, and 11?
Laurie
--- On Fri, 5/17/13, Jack Vogel wrote:
From: Jack Vogel
Subject: Re: Is there any way to limit the amount of data in an mbuf chain
code yet?
>
> Laurie
>
> --- On *Sat, 5/4/13, Jack Vogel * wrote:
>
>
> From: Jack Vogel
> Subject: Re: Is there any way to limit the amount of data in an mbuf chain
> submitted to a driver?
> To: "Richard Sharpe"
> Cc: "FreeBSD Net" , "Adrian Ch
Did you get to commit that new code yet?
Laurie
--- On Sat, 5/4/13, Jack Vogel wrote:
From: Jack Vogel
Subject: Re: Is there any way to limit the amount of data in an mbuf chain
submitted to a driver?
To: "Richard Sharpe"
Cc: "FreeBSD Net" , "Adrian Chadd"
Dat
On Sat, May 4, 2013 at 4:59 PM, Eric van Gyzen wrote:
> On 05/04/2013 04:19 PM, Richard Sharpe wrote:
>> On Sat, May 4, 2013 at 2:18 PM, Jack Vogel wrote:
>>> Ahh, Twinville, new hardware :) The version at the tip is 2.5.8 and I am
>>> working on version 2.5.12 internally that I hope to commit n
On 05/04/2013 04:19 PM, Richard Sharpe wrote:
> On Sat, May 4, 2013 at 2:18 PM, Jack Vogel wrote:
>> Ahh, Twinville, new hardware :) The version at the tip is 2.5.8 and I am
>> working on version 2.5.12 internally that I hope to commit next week...
>> so your version is "a bit old" :) I would do
wrote:
>> >>
>> >> On Sat, May 4, 2013 at 10:39 AM, Adrian Chadd
>> >> wrote:
>> >> > On 4 May 2013 06:52, Richard Sharpe
>> >> > wrote:
>> >> >> Hi folks,
>> >> >>
>> >> >> I understand bet
understand better why I am seeing EINVAL intermittently when
> sending
> >> >> data from Samba via SMB2.
> >> >>
> >> >> The ixgbe driver, for TSO reasons, limits the amount of data that can
> >> >> be DMA'd to 65535 bytes. It returns
:39 AM, Adrian Chadd
>>>> wrote:
>>>>
>>>>> On 4 May 2013 06:52, Richard Sharpe
>>>>>
>>>> wrote:
>>>>
>>>>> Hi folks,
>>>>>>
>>>>>> I understand better why I am seeing
data from Samba via SMB2.
The ixgbe driver, for TSO reasons, limits the amount of data that can
be DMA'd to 65535 bytes. It returns EINVAL for any mbuf chain larger
than that.
The SO_SNDBUF for that socket is set to 131972. Mostly there is less
than 64kiB of space available, so that is all TC
gt;> > On 4 May 2013 06:52, Richard Sharpe wrote:
>> >> Hi folks,
>> >>
>> >> I understand better why I am seeing EINVAL intermittently when sending
>> >> data from Samba via SMB2.
>> >>
>> >> The ixgbe driver, for TSO reasons,
seeing EINVAL intermittently when sending
>> >> data from Samba via SMB2.
>> >>
>> >> The ixgbe driver, for TSO reasons, limits the amount of data that can
>> >> be DMA'd to 65535 bytes. It returns EINVAL for any mbuf chain larger
>> >&g
ntermittently when sending
> >> data from Samba via SMB2.
> >>
> >> The ixgbe driver, for TSO reasons, limits the amount of data that can
> >> be DMA'd to 65535 bytes. It returns EINVAL for any mbuf chain larger
> >> than that.
> >>
> >> The
ons, limits the amount of data that can
>> be DMA'd to 65535 bytes. It returns EINVAL for any mbuf chain larger
>> than that.
>>
>> The SO_SNDBUF for that socket is set to 131972. Mostly there is less
>> than 64kiB of space available, so that is all TCP etc can put i
NVAL intermittently when sending
> data from Samba via SMB2.
>
> The ixgbe driver, for TSO reasons, limits the amount of data that can
> be DMA'd to 65535 bytes. It returns EINVAL for any mbuf chain larger
> than that.
>
> The SO_SNDBUF for that socket is set to 13197
On 4 May 2013 06:52, Richard Sharpe wrote:
> Hi folks,
>
> I understand better why I am seeing EINVAL intermittently when sending
> data from Samba via SMB2.
>
> The ixgbe driver, for TSO reasons, limits the amount of data that can
> be DMA'd to 65535 bytes. It returns
Hi folks,
I understand better why I am seeing EINVAL intermittently when sending
data from Samba via SMB2.
The ixgbe driver, for TSO reasons, limits the amount of data that can
be DMA'd to 65535 bytes. It returns EINVAL for any mbuf chain larger
than that.
The SO_SNDBUF for that socket i
On 06/04/12 13:33, Colin Percival wrote:
On 06/03/12 20:14, Lawrence Stewart wrote:
On 06/04/12 02:51, Colin Percival wrote:
I've attached a new patch which:
1. adds a IFCAP_TSO_MSS "capability" and a if_tx_tso_mss field to struct ifnet,
A minor thing, but I don't like the overloading of the
On 06/03/12 20:14, Lawrence Stewart wrote:
> On 06/04/12 02:51, Colin Percival wrote:
>> I've attached a new patch which:
>> 1. adds a IFCAP_TSO_MSS "capability" and a if_tx_tso_mss field to struct
>> ifnet,
>
> A minor thing, but I don't like the overloading of the term MSS. Perhaps
> s/MSS/CHUN
On 06/04/12 02:51, Colin Percival wrote:
On 05/30/12 08:30, Andrew Gallatin wrote:
On 05/30/12 10:59, Colin Percival wrote:
The Xen virtual network interface has an issue (ok, really the issue is with
the linux back-end, but that's what most people are using) where it can't
handle scatter-gathe
On 06/03/12 15:56, Bjoern A. Zeeb wrote:
> On 3. Jun 2012, at 16:51 , Colin Percival wrote:
>> I've attached a new patch which:
>> 1. adds a IFCAP_TSO_MSS "capability" and a if_tx_tso_mss field to struct
>> ifnet,
>> 2. sets these in netfront when the IFCAP_TSO4 flag is set,
>> 3. extends tcp_maxm
On 3. Jun 2012, at 16:51 , Colin Percival wrote:
> On 05/30/12 08:30, Andrew Gallatin wrote:
>> On 05/30/12 10:59, Colin Percival wrote:
>>> The Xen virtual network interface has an issue (ok, really the issue is with
>>> the linux back-end, but that's what most people are using) where it can't
>
On 06/03/12 12:05, Andrew Gallatin wrote:
> On 06/03/12 12:51, Colin Percival wrote:
>> I've attached a new patch which:
>> 1. adds a IFCAP_TSO_MSS "capability" and a if_tx_tso_mss field to struct
>> ifnet,
>> 2. sets these in netfront when the IFCAP_TSO4 flag is set,
>> 3. extends tcp_maxmtu to r
On 06/03/12 12:51, Colin Percival wrote:
On 05/30/12 08:30, Andrew Gallatin wrote:
On 05/30/12 10:59, Colin Percival wrote:
The Xen virtual network interface has an issue (ok, really the issue is with
the linux back-end, but that's what most people are using) where it can't
handle scatter-gathe
On 05/30/12 08:30, Andrew Gallatin wrote:
> On 05/30/12 10:59, Colin Percival wrote:
>> The Xen virtual network interface has an issue (ok, really the issue is with
>> the linux back-end, but that's what most people are using) where it can't
>> handle scatter-gather writes with lots of pieces, aka.
On 05/30/12 18:35, Colin Percival wrote:
On 05/30/12 08:30, Andrew Gallatin wrote:
On 05/30/12 10:59, Colin Percival wrote:
The Xen virtual network interface has an issue (ok, really the issue is with
the linux back-end, but that's what most people are using) where it can't
handle scatter-gathe
On 05/30/12 08:30, Andrew Gallatin wrote:
> On 05/30/12 10:59, Colin Percival wrote:
>> The Xen virtual network interface has an issue (ok, really the issue is with
>> the linux back-end, but that's what most people are using) where it can't
>> handle scatter-gather writes with lots of pieces, aka.
On Wed, May 30, 2012 at 8:30 AM, Andrew Gallatin wrote:
> On 05/30/12 10:59, Colin Percival wrote:
>
>> Hi all,
>>
>> The Xen virtual network interface has an issue (ok, really the issue is
>> with
>> the linux back-end, but that's what most people are using) where it can't
>> handle scatter-gathe
On 05/30/12 10:59, Colin Percival wrote:
Hi all,
The Xen virtual network interface has an issue (ok, really the issue is with
the linux back-end, but that's what most people are using) where it can't
handle scatter-gather writes with lots of pieces, aka. long mbuf chains.
This currently bites us
doesn't
exactly fit here, but this is where we look up interface properties...),
(4) adds a tx_chain_limit field to struct tcpcb,
(5) makes tcp_mss_update set tx_chain_limit using tcp_maxmtu,
(6) adds a new m_copy_nbufs function which truncates the copied mbuf chain
after a specified number of
Synopsis: [panic] m_copym, length > size of mbuf chain
Responsible-Changed-From-To: kmacy->freebsd-net
Responsible-Changed-By: gavin
Responsible-Changed-When: Sun May 29 22:04:26 UTC 2011
Responsible-Changed-Why:
kmacy has asked for his PRs to be reassigned
http://www.freebsd.org/cgi
Synopsis: Network stack may modify read-only mbuf chain copies
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Sun Apr 29 09:15:10 UTC 2007
Responsible-Changed-Why:
This should probably be assigned to -net.
http://www.freebsd.
[...]
> I don't believe that mbuf fragments have any relationship to IP
> fragmentation.
>
> And while you mention it, the IP fragmentation handling code is another
> place where we need to add mbuf merging/chaining.
>
> I've been thinking about this, actually. How many IP fragments will a
> pac
On Wed, 25 Sep 2002, Giorgos Keramidas wrote:
> On 2002-09-24 13:57, Prafulla Deuskar <[EMAIL PROTECTED]> wrote:
> > All,
> >
> > Is there a pre-set limit on maximum number of fragments in a
> > mbuf chain ?
>
> Not as a limit of the mbuf chain code, but a
Luigi Rizzo writes:
| On Wed, Sep 25, 2002 at 12:39:45PM -0700, Doug Ambrisko wrote:
| ...
| > Various drivers have code to deal with this when the structure
| > it is putting the frags into runs out :-( See a recent bug fix to
| > the ste(4) gleaned from the fxp(4). This type of problem is prob
On Wed, Sep 25, 2002 at 12:39:45PM -0700, Doug Ambrisko wrote:
...
> Various drivers have code to deal with this when the structure
> it is putting the frags into runs out :-( See a recent bug fix to
> the ste(4) gleaned from the fxp(4). This type of problem is probably
> lurking in other driver
Luigi Rizzo writes:
| On Tue, Sep 24, 2002 at 04:15:56PM -0700, Prafulla Deuskar wrote:
| > Sorry for the cross-posting.
| >
| >
| > All,
| >
| > Is there a pre-set limit on maximum number of fragments in a
| > mbuf chain ?
| >
| &
On Tue, Sep 24, 2002 at 04:15:56PM -0700, Prafulla Deuskar wrote:
> Sorry for the cross-posting.
>
>
> All,
>
> Is there a pre-set limit on maximum number of fragments in a
> mbuf chain ?
>
> I see 64 fragments with jumboframes (
Sorry for the cross-posting.
All,
Is there a pre-set limit on maximum number of fragments in a
mbuf chain ?
I see 64 fragments with jumboframes (mtu 9000) using nttcp.
Thanks,
Prafulla
- End forwarded message -
To Unsubscribe: send mail to [EMAIL
43 matches
Mail list logo
