> On Apr 9, 2020, at 7:19 PM, SAITOH Masanobu wrote:
>
> You're welcome.
> Some drivers still have no m_defrag() code, so we should add it
> to them().
Others do something different than m_defrag() do essentially the same effect.
Personally, I am not a huge fan of the m_defrag() API.
-- th
On 2020/04/10 2:42, David Young wrote:
On Thu, Apr 09, 2020 at 03:25:32PM +0900, SAITOH Masanobu wrote:
On 2020/04/09 11:08, David Young wrote:
On Wed, Apr 08, 2020 at 11:01:52PM +, Jaromir Dolecek wrote:
on I219 I observe about 35% transmit performance drop when tso4 enabled
This sounds
On Thu, Apr 09, 2020 at 03:25:32PM +0900, SAITOH Masanobu wrote:
> On 2020/04/09 11:08, David Young wrote:
> > On Wed, Apr 08, 2020 at 11:01:52PM +, Jaromir Dolecek wrote:
> > > on I219 I observe about 35% transmit performance drop when tso4 enabled
> >
> > This sounds familiar. There was a b
On Thu, Apr 09, 2020 at 09:52:37PM +0900, Tetsuya Isaki wrote:
> At Fri, 3 Apr 2020 17:51:21 +0200,
> Joerg Sonnenberger wrote:
> > It seems perfectly
> > sensible to me that the final output device can provide a lower limit as
> > well as having one derived from HZ and using whatever is higher.
>
HI,
I am not sur whether it is the commit below, but 2 out 4 times my
xen-DOMU from today (20200409/9.99.55)
panics with following locking botch:
[ 29.9301379] panic: kernel diagnostic assertion "IFNET_LOCKED(ifp)"
failed: file "/usr/src/sys/arch/xen/xen/if_xennet_xenbu
At Fri, 3 Apr 2020 17:51:21 +0200,
Joerg Sonnenberger wrote:
> It seems perfectly
> sensible to me that the final output device can provide a lower limit as
> well as having one derived from HZ and using whatever is higher.
Sorry, I could not translate well and I didn't understand.
Could you write
