Ferruh Yigit <ferruh.yi...@intel.com> writes: > On 11/17/2020 10:06 AM, Joyce Kong wrote: >> + /** >> + * Update data length and packet length for descriptor. >> + * structure of pkt_mb: >> + * -------------------------------------------------------------------- >> + * |32 bits pkt_type|32 bits pkt_len|16 bits data_len|16 bits vlan_tci| >> + * -------------------------------------------------------------------- >> + */ >> + pkt_mb[0] = vreinterpretq_u64_u8(vqtbl1q_u8( >> + vreinterpretq_u8_u64(desc[0]), shuf_msk1)); >> + pkt_mb[1] = vreinterpretq_u64_u8(vqtbl1q_u8( >> + vreinterpretq_u8_u64(desc[0]), shuf_msk2)); >> + pkt_mb[2] = vreinterpretq_u64_u8(vqtbl1q_u8( >> + vreinterpretq_u8_u64(desc[1]), shuf_msk1))' > > s\'\; > > I will fix in next-net but my concern is why this has been not caught > by any of our automated builds?
That series was flagged for error with Travis: http://mails.dpdk.org/archives/test-report/2020-November/167602.html Unfortunately, the build seems to have been purged (since it's from November). But Travis did flag the build as failing. With github actions we hope to pull the full logs into the email. > In patchwork only test report seems from the 'checkpatch': > https://patches.dpdk.org/patch/84260/ At least the 0-day robot does not submit each patch for separate build. We did that at first, and the robot's queue reached a week of backlog because the build takes a while. Especially when we get 20+ patch series followed by v2-v4 fixing build errors or compile errors.
