Got it, thanks a lot.
At 2020-10-14 21:55:25, "Olivier Matz" wrote:
>Hi,
>
>On Sat, Oct 10, 2020 at 09:49:35AM +0800, yang_y_yi wrote:
>> Olivier, thank you so much for helping figure out this, it does work
>> as the code you changed, so we can fix the issue without this patch
Hi,
On Sat, Oct 10, 2020 at 09:49:35AM +0800, yang_y_yi wrote:
> Olivier, thank you so much for helping figure out this, it does work
> as the code you changed, so we can fix the issue without this patch
> series. My question is can it also work for normal mbuf or indirect
> mbuf? (I mean pkt is d
Olivier, thank you so much for helping figure out this, it does work as the
code you changed, so we can fix the issue without this patch series. My
question is can it also work for normal mbuf or indirect mbuf? (I mean pkt is
direct mbuf or indirect mbuf)
At 2020-10-09 19:55:25, "Olivier Matz"
Hi,
On Fri, Oct 09, 2020 at 05:51:23PM +0800, yang_y_yi wrote:
> Olivier, thank you so much for your reply, your patch post for vhost help me
> understand your concern better, I totally agree. For GSO case, let me show
> you a simple code to explain my issue.
>
>
>
>
>
> struct rte_mbuf *pk
Olivier, thank you so much for your reply, your patch post for vhost help me
understand your concern better, I totally agree. For GSO case, let me show you
a simple code to explain my issue.
struct rte_mbuf *pkt = rte_pktmbuf_alloc(mp);
virtio_dev_extbuf_alloc(pkt, data_len)
struct rte_mbuf
Hi,
On Sun, Sep 27, 2020 at 01:55:21PM +0800, yang_y_yi wrote:
> Per GSO requirement, this is a must-have change, Jiayu, can you help review
> this series?
I can't ack this patch until I have a simple and clear test case (only
with mbuf functions, without GSO or vhost) showing the issue we have
t
Hi, folks
Per GSO requirement, this is a must-have change, Jiayu, can you help review
this series?
Olivier, if you used the old interface, maybe you need to change your code to
adapt this, I don't think we can have a better way to handle GSO case.
At 2020-08-04 09:31:19, "yang_y_yi
At 2020-08-03 20:34:25, "Olivier Matz" wrote:
>On Mon, Aug 03, 2020 at 05:42:13PM +0800, yang_y_yi wrote:
>> At 2020-08-03 16:11:39, "Olivier Matz" wrote:
>> >On Mon, Aug 03, 2020 at 09:26:40AM +0800, yang_y_yi wrote:
>> >> At 2020-08-03 04:29:07, "Olivier Matz" wrote:
>> >> >Hi,
>> >> >
>> >> >
On Mon, Aug 03, 2020 at 05:42:13PM +0800, yang_y_yi wrote:
> At 2020-08-03 16:11:39, "Olivier Matz" wrote:
> >On Mon, Aug 03, 2020 at 09:26:40AM +0800, yang_y_yi wrote:
> >> At 2020-08-03 04:29:07, "Olivier Matz" wrote:
> >> >Hi,
> >> >
> >> >On Sun, Aug 02, 2020 at 07:12:36AM +0800, yang_y_yi wr
At 2020-08-03 16:11:39, "Olivier Matz" wrote:
>On Mon, Aug 03, 2020 at 09:26:40AM +0800, yang_y_yi wrote:
>> At 2020-08-03 04:29:07, "Olivier Matz" wrote:
>> >Hi,
>> >
>> >On Sun, Aug 02, 2020 at 07:12:36AM +0800, yang_y_yi wrote:
>> >>
>> >>
>> >> At 2020-07-31 23:15:43, "Olivier Matz" wrote:
On Mon, Aug 03, 2020 at 09:26:40AM +0800, yang_y_yi wrote:
> At 2020-08-03 04:29:07, "Olivier Matz" wrote:
> >Hi,
> >
> >On Sun, Aug 02, 2020 at 07:12:36AM +0800, yang_y_yi wrote:
> >>
> >>
> >> At 2020-07-31 23:15:43, "Olivier Matz" wrote:
> >> >Hi,
> >> >
> >> >On Thu, Jul 30, 2020 at 08:08:5
At 2020-08-03 04:45:12, "Olivier Matz" wrote:
>On Sun, Aug 02, 2020 at 10:29:07PM +0200, Olivier Matz wrote:
>> Hi,
>>
>> On Sun, Aug 02, 2020 at 07:12:36AM +0800, yang_y_yi wrote:
>> >
>> >
>> > At 2020-07-31 23:15:43, "Olivier Matz" wrote:
>> > >Hi,
>> > >
>> > >On Thu, Jul 30, 2020 at 08:08
At 2020-08-03 04:29:07, "Olivier Matz" wrote:
>Hi,
>
>On Sun, Aug 02, 2020 at 07:12:36AM +0800, yang_y_yi wrote:
>>
>>
>> At 2020-07-31 23:15:43, "Olivier Matz" wrote:
>> >Hi,
>> >
>> >On Thu, Jul 30, 2020 at 08:08:59PM +0800, yang_y...@163.com wrote:
>> >> From: Yi Yang
>> >>
>> >> In GSO ca
On Sun, Aug 02, 2020 at 10:29:07PM +0200, Olivier Matz wrote:
> Hi,
>
> On Sun, Aug 02, 2020 at 07:12:36AM +0800, yang_y_yi wrote:
> >
> >
> > At 2020-07-31 23:15:43, "Olivier Matz" wrote:
> > >Hi,
> > >
> > >On Thu, Jul 30, 2020 at 08:08:59PM +0800, yang_y...@163.com wrote:
> > >> From: Yi Yan
Hi,
On Sun, Aug 02, 2020 at 07:12:36AM +0800, yang_y_yi wrote:
>
>
> At 2020-07-31 23:15:43, "Olivier Matz" wrote:
> >Hi,
> >
> >On Thu, Jul 30, 2020 at 08:08:59PM +0800, yang_y...@163.com wrote:
> >> From: Yi Yang
> >>
> >> In GSO case, segmented mbufs are attached to original
> >> mbuf whic
At 2020-07-31 23:15:43, "Olivier Matz" wrote:
>Hi,
>
>On Thu, Jul 30, 2020 at 08:08:59PM +0800, yang_y...@163.com wrote:
>> From: Yi Yang
>>
>> In GSO case, segmented mbufs are attached to original
>> mbuf which can't be freed when it is external. The issue
>> is free_cb doesn't know original
Hi,
On Thu, Jul 30, 2020 at 08:08:59PM +0800, yang_y...@163.com wrote:
> From: Yi Yang
>
> In GSO case, segmented mbufs are attached to original
> mbuf which can't be freed when it is external. The issue
> is free_cb doesn't know original mbuf and doesn't free
> it when refcnt of shinfo is 0.
>
From: Yi Yang
In GSO case, segmented mbufs are attached to original
mbuf which can't be freed when it is external. The issue
is free_cb doesn't know original mbuf and doesn't free
it when refcnt of shinfo is 0.
Original mbuf can be freed by rte_pktmbuf_free segmented
mbufs or by rte_pktmbuf_free
18 matches
Mail list logo
