Re: [Xen-devel] [DOC v6] PV Calls protocol design

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

> > > ### Data ring
> > > 
> > > Data rings are used for sending and receiving data over a connected 
> > > socket. They
> > > are created upon a successful **accept** or **connect** command.
> > > 
> > > A data ring is composed of two pieces: the interface and the **in** and 
> > > **out**
> > > buffers. The interface, represented by `struct pvcalls_ring_intf` is 
> > > shared
> > > first and resides on the page whose grant reference is passed by 
> > > **accept** and
> > > **connect** as parameter. `struct pvcalls_ring_intf` contains the list of 
> > > grant
> > > references which constitute the **in** and **out** data buffers.
> > > 
> > > #### Data ring interface
> > > 
> > >     struct pvcalls_data_intf {
> > >           PVCALLS_RING_IDX in_cons, in_prod;
> > 
> > Do you want to add some spacing between them so that you don't
> > use the same cacheline?
> 
> Let me get this straight. in_cons and in_prod should be on the same
> cacheline.  Similarly out_cons and out_prod should be on the same
> cacheline, but on a different cacheline compared to in_cons and in_prod.
> 
> So I should add padding between the two pairs of indices. Something
> like:
>             uint8_t pad[cache_line_size - 8];
> 
> Where cache_line_size is usually 64 bytes. So this would be:
> 
>             uint8_t pad[56];
> 
> Is that right?

Sounds right. But pahole will for sure confirm :-) I was too lazy to copy this 
in code and see
what it gives you.
> 
> 
> > >           PVCALLS_RING_IDX out_cons, out_prod;
> > >           int32_t in_error, out_error;
> > >     
> > >           uint32_t ring_order;
> > >           grant_ref_t ref[];
> > >     };
> > 
> > That does not look like it would be to the power of two? Perhaps
> > some padding?
> 
> I don't understand the suggestion about the padding here.

You pad[56] takes care of the issue I had.

..snipp.
> > > The binary layout of `struct pvcalls_data_intf` follows:
> > > 
> > >     0         4         8         12        16        20        24        
> > > 28
> > >     
> > > +---------+---------+---------+---------+---------+---------+----------+
> > >     | in_cons | in_prod |out_cons |out_prod |in_error 
> > > |out_error|ring_order|
> > >     
> > > +---------+---------+---------+---------+---------+---------+----------+
> > > 
> > >     28        32        36        40        4092     4096
> > >     +---------+---------+---------+----//---+---------+
> > >     |  ref[0] |  ref[1] |  ref[2] |         |  ref[N] |
> > >     +---------+---------+---------+----//---+---------+
> > 
> > Perhaps you can say:
> > 
> > **N.B** For one page, the N would be 2034.
> 
> I can do that but actually N would be (4096-28)/4 = 1017. Ring refs are
> 4 bytes each.

I somehow had uint16_t on my mind! Thanks for checking me!

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