2015-05-29 17:37, Gonzalez Monroy, Sergio:
> On 20/05/2015 12:02, Simon Kagstrom wrote:
> > We use sequence numbers from a generator which has potentially started
> > long before the receiver. Therefore, the first number will typically
> > be > 0. The rte_reorder code will not work in this case, si
On 20/05/2015 12:02, Simon Kagstrom wrote:
> We use sequence numbers from a generator which has potentially started
> long before the receiver. Therefore, the first number will typically
> be > 0. The rte_reorder code will not work in this case, since the
> packet is seen as outside of the buffer.
On 28/05/2015 09:15, Simon K?gstr?m wrote:
> Thanks for the review, Sergio!
>
> On 2015-05-28 09:49, Gonzalez Monroy, Sergio wrote:
>>> @@ -325,6 +327,12 @@ rte_reorder_insert(struct rte_reorder_buffer *b,
>>> struct rte_mbuf *mbuf)
>>>uint32_t offset, position;
>>>struct cir_buffer
Thanks for the review, Sergio!
On 2015-05-28 09:49, Gonzalez Monroy, Sergio wrote:
>> @@ -325,6 +327,12 @@ rte_reorder_insert(struct rte_reorder_buffer *b,
>> struct rte_mbuf *mbuf)
>> uint32_t offset, position;
>> struct cir_buffer *order_buf = &b->order_buf;
>> +if (!b->is_init
Sorry for the delay :)
On 20/05/2015 12:02, Simon Kagstrom wrote:
> We use sequence numbers from a generator which has potentially started
> long before the receiver. Therefore, the first number will typically
> be > 0. The rte_reorder code will not work in this case, since the
> packet is seen as
We use sequence numbers from a generator which has potentially started
long before the receiver. Therefore, the first number will typically
be > 0. The rte_reorder code will not work in this case, since the
packet is seen as outside of the buffer.
The patch instead records the first sequence numbe
6 matches
Mail list logo
