Re: [Xen-devel] [PATCH v7 0/2] public/io/netif.h: support for toeplitz hashing

[Bob Liu <bob.liu@xxxxxxxxxx>]

On 02/02/2016 05:33 PM, Paul Durrant wrote:
>> -----Original Message-----
>> From: Bob Liu [mailto:bob.liu@xxxxxxxxxx]
>> Sent: 02 February 2016 05:02
>> To: Paul Durrant
>> Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx
>> Subject: Re: [Xen-devel] [PATCH v7 0/2] public/io/netif.h: support for
>> toeplitz hashing
>>
>> Hi Paul,
>>
>> On 01/12/2016 05:58 PM, Paul Durrant wrote:
>>> This series documents changes needed to support toeplitz hashing in a
>>> backend, configurable by the frontend.
>>>
>>> Patch #1 adds further clarifications to the receive and transmit wire
>>> formats.
>>>
>>> Patch #2 documents a new 'control ring' for passing bulk data between
>>> frontend and backend. This is needed for passing the hash mapping table
>>> and hash key. It also documents messages to allow a frontend to configure
>>> toeplitz hashing and a new extra info segment that can be used for passing
>>> hash values along with packets on both the transmit and receive side.
>>>
>>
>> I have a question, why not make the "netif_ctrl_request" a part of the extra
>> info segment?
>> So that can reuse the origin transmit shared ring.
> 
> That was an option but I think it's pretty hacky. Also, extra info segments 
> are pretty small. 
> The multicast control protocol uses that mechanism and it's quite inelegant. 
> I also think a dedicated ring for out-of-band control messages is likely to 
> be of further use in the future.
> 

Nod.

One more question, does request in this control ring can work synchronously 
with request in normal transmit ring?

I'm seeking a proper way to make xen-block driver can transmit some per-request 
extra-data from frontend to backend.
It seems similar mechanism like extra info segments in xen-network is more 
suitable.

Thanks,
Bob

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel