Skip to contentSkip to conversation

ixgbe_recv_scattered_pkts_vec split_flags question

DISCUSSION Zoltan Kiss 2 participants 2 messages Jul 21, 2015

lore
Share & tools
lore
#0 lore raw

Hi,

I have a question regarding split_flags in this question. It's defined as an array of 1 byte unsigned ints:

uint8_t split_flags[RTE_IXGBE_VPMD_RX_BURST] = {0};

RTE_IXGBE_VPMD_RX_BURST is 32, so it will be 32 bytes. Then we cast it into a pointer for 4 byte values, and check the first 4 elements of that array

const uint32_t *split_fl32 = (uint32_t *)split_flags; if (rxq->pkt_first_seg == NULL &&

		split_fl32[0] == 0 && split_fl32[1] == 0 &&
		split_fl32[2] == 0 && split_fl32[3] == 0)

So we only check the first half of this 32 byte array. But _recv_raw_pkts_vec() seems to use the whole array. Is this a bug or a feature? Or am I mistaken in the math somewhere?

Regards,

Zoltan Kiss

#1 lore raw
Quoted 15 lines · Zoltan Kiss

Hi,

I have a question regarding split_flags in this question. It's defined as an array of 1 byte unsigned ints:

uint8_t split_flags[RTE_IXGBE_VPMD_RX_BURST] = {0};

RTE_IXGBE_VPMD_RX_BURST is 32, so it will be 32 bytes. Then we cast it into a pointer for 4 byte values, and check the first 4 elements of that array

const uint32_t *split_fl32 = (uint32_t *)split_flags; if (rxq->pkt_first_seg == NULL &&

		split_fl32[0] == 0 && split_fl32[1] == 0 &&
		split_fl32[2] == 0 && split_fl32[3] == 0)
Quoted 7 lines

So we only check the first half of this 32 byte array. But _recv_raw_pkts_vec() seems to use the whole array. Is this a bug or a feature? Or am I mistaken in the math somewhere?

Regards,

Zoltan Kiss

Yes, you are right, this does look like a bug. The uint32_t's should probably be uint64_t's. :-(

/Bruce