> From: Honnappa Nagarahalli [mailto:honnappa.nagaraha...@arm.com]
> Sent: Friday, 1 July 2022 21.31
>
>
>
> > > > >
> > > > > 16/05/2022 07:10, Feifei Wang пишет:
> > > > > >
> > > > > >>> Currently, the transmit side frees the buffers into the
> > > lcore
> > > > > >>> ca
> > > >
> > > > 16/05/2022 07:10, Feifei Wang пишет:
> > > > >
> > > > >>> Currently, the transmit side frees the buffers into the
> > lcore
> > > > >>> cache and the receive side allocates buffers from the
> > > > >>> lcore
> > > > cache.
> > > > >>> The transmit si
> From: Honnappa Nagarahalli [mailto:honnappa.nagaraha...@arm.com]
> Sent: Wednesday, 29 June 2022 23.58
>
>
>
> > >
> > > 16/05/2022 07:10, Feifei Wang пишет:
> > > >
> > > >>> Currently, the transmit side frees the buffers into the
> lcore
> > > >>> cache and the receive
> > >>>
> >
> > [konstantin.v.anan...@yandex.ru appears similar to someone who
> > previously sent you email, but may not be that person. Learn why
> > this
> > could be a risk at
> > https://aka.ms/LearnAboutSenderIdentification.]
> >
> > 16/05/2022 07:10, Feif
> -邮件原件-
> 发件人: Konstantin Ananyev
> 发送时间: Tuesday, May 24, 2022 9:26 AM
> 收件人: Feifei Wang
> 抄送: nd ; dev@dpdk.org; Ruifeng Wang
> ; Honnappa Nagarahalli
>
> 主题: Re: [PATCH v1 0/5] Direct re-arming of buffers on receive side
>
> [konstantin.v.anan..
> From: Konstantin Ananyev [mailto:konstantin.v.anan...@yandex.ru]
> Sent: Saturday, 4 June 2022 01.32
>
> >
> >>>
>
> [konstantin.v.anan...@yandex.ru appears similar to someone who
> previously sent you email, but may not be that person. Learn why
> this
> could be a risk at
[konstantin.v.anan...@yandex.ru appears similar to someone who
previously sent you email, but may not be that person. Learn why this
could be a risk at https://aka.ms/LearnAboutSenderIdentification.]
16/05/2022 07:10, Feifei Wang пишет:
Currently, the transmit side frees the buffers in
> >
> >>
> >> [konstantin.v.anan...@yandex.ru appears similar to someone who
> >> previously sent you email, but may not be that person. Learn why this
> >> could be a risk at https://aka.ms/LearnAboutSenderIdentification.]
> >>
> >> 16/05/2022 07:10, Feifei Wang пишет:
> >>>
> > Currently, th
24/05/2022 21:14, Honnappa Nagarahalli пишет:
[konstantin.v.anan...@yandex.ru appears similar to someone who
previously sent you email, but may not be that person. Learn why this could
be a risk at https://aka.ms/LearnAboutSenderIdentification.]
16/05/2022 07:10, Feifei Wang пишет:
Curren
>
> [konstantin.v.anan...@yandex.ru appears similar to someone who
> previously sent you email, but may not be that person. Learn why this could
> be a risk at https://aka.ms/LearnAboutSenderIdentification.]
>
> 16/05/2022 07:10, Feifei Wang пишет:
> >
> >>> Currently, the transmit side frees t
> From: Konstantin Ananyev [mailto:konstantin.v.anan...@yandex.ru]
> Sent: Tuesday, 24 May 2022 03.26
> > Furtrhermore, I think this is a tradeoff between performance and
> > flexibility.
> > Our goal is to achieve best performance, this means we need to give
> up some
> > flexibility decisively.
16/05/2022 07:10, Feifei Wang пишет:
Currently, the transmit side frees the buffers into the lcore cache and
the receive side allocates buffers from the lcore cache. The transmit
side typically frees 32 buffers resulting in 32*8=256B of stores to
lcore cache. The receive side allocates 32 buffe
Currently, the transmit side frees the buffers into the lcore cache and
the receive side allocates buffers from the lcore cache. The transmit
side typically frees 32 buffers resulting in 32*8=256B of stores to
lcore cache. The receive side allocates 32 buffers and stores them in
the receive sid
Currently, the transmit side frees the buffers into the lcore cache and
the receive side allocates buffers from the lcore cache. The transmit
side typically frees 32 buffers resulting in 32*8=256B of stores to
lcore cache. The receive side allocates 32 buffers and stores them in
the receive side so
14 matches
Mail list logo
