On 05/09/2017 10:40 AM, Jason Wang wrote:
On 2017年05月08日 11:47, Zhang Chen wrote:
On 05/03/2017 06:42 PM, Jason Wang wrote:
On 2017年05月03日 11:43, Zhang Chen wrote:
On 05/02/2017 12:53 PM, Jason Wang wrote:
On 2017年04月28日 17:47, Zhang Chen wrote:
Address Jason Wang's comments add vnet header length to
SocketReadState.
Instead of saying this, you can add "Suggested-by: Jason Wang
<jasow...@redhat.com>" above your sign-off.
OK.
So we change net_fill_rstate() to read
struct {int size; int vnet_hdr_len; const uint8_t buf[];}.
This makes me thinking about the backward compatibility. I think
we'd better try to keep it as much as possible. E.g how about pack
vnet_hdr_len into higher bits of size?
Do you means split uint32_t size to uint16_t size and uint16_t
vnet_hdr_len ?
If yes, we also can't keep compatibility with old version.
Old code send a uint32_t size, we read it as uint16_t size is
always wrong.
Thanks
Zhang Chen
Consider it's unlikely to send or receive packet >= 64K, we can
reuse higher bits (e.g highest 8 bits). Then we can still read
uint32_t and then check its highest 8 bits. If it was zero, we know
vnet header is zero, if not it could be read as vnet header length.
I got your point, but in this way, packet size must < 64K, if size
>=64K we still can't maintain the backward compatibility,
For the packet sender that didn't know the potential packet size
limit, I think we should make code explicitly declared like
currently code. Otherwise we will make other people confused and make
code difficult to maintain.
Thanks
Zhang Chen
Yes, this is an possible issue in the future. Rethink about this, what
if we just compare vnet header? Is there any issue of doing this?
(Sorry, I remember this is a reason, but forget now).
Yes, we can compare all packet with vnet header, the compare performance
is very low. but we can't parse raw packet to tcp/udp/icmp packet,
because we didn't know the vnet_hdr_len as the offset.
Thanks
Zhang Chen
Thanks
.
--
Thanks
Zhang Chen
