search for: req_prod

...) - max += MAX_SKB_FRAGS + 1; /* extra_info + frags */ - - return max; -} - int xen_netbk_rx_ring_full(struct xenvif *vif) { - RING_IDX peek = vif->rx_req_cons_peek; - RING_IDX needed = max_required_rx_slots(vif); + RING_IDX peek = vif->rx_req_cons_peek; - return ((vif->rx.sring->req_prod - peek) < needed) || - ((vif->rx.rsp_prod_pvt + XEN_NETIF_RX_RING_SIZE - peek) < needed); + return ((vif->rx.sring->req_prod < peek) || + (vif->rx.rsp_prod_pvt + XEN_NETIF_RX_RING_SIZE < peek)); } int xen_netbk_must_stop_queue(struct xenvif *vif) @@ -314,8 +302,7...

...hannel, then i wrapped writing and reading function to operate it ,but it came to oops:     struct xenstore_domain_interface {     char req[XENSTORE_RING_SIZE]; /* Requests to xenstore daemon. */     char rsp[XENSTORE_RING_SIZE]; /* Replies and async watch events. */     XENSTORE_RING_IDX req_cons, req_prod;     XENSTORE_RING_IDX rsp_cons, rsp_prod;     };     struct xenstore_domain_interface *xenstore;     xen_hvm_param_t param;     param.domid = DOMID_SELF;     param.index = HVM_PARAM_STORE_PFN;     if ( hypercall_hvm_op(HVMOP_get_param, &param) )         BUG();     xenstore = (void *) (unsigned...

hi. trying to understand the idea behind _notify in #define RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(_r, _notify) do { \ RING_IDX __old = (_r)->sring->req_prod; \ RING_IDX __new = (_r)->req_prod_pvt; \ wmb(); /* back sees requests /before/ updated producer index */ \ (_r)->sring->req_prod = __new; \ mb(); /* back sees new requests /before/...

Hi, We are running into a situation where rsp_prod index in the shared ring is not getting updated for the netfront tx ring by the netback. We see that rsp_cons is the same value as rsp_prod, with req_prod 236 slots away(tx ring is full). From looking at the netfront driver code, it looks as if xennet_tx_buf_gc processing only happens if rsp_prod is more than rsp_cons. Our understanding is that netfront sets rsp_cons to tell the netback to start processing transmits from rsp_cons index onwards ti...

Hi, We are running into a situation where rsp_prod index in the shared ring is not getting updated for the netfront tx ring by the netback. We see that rsp_cons is the same value as rsp_prod, with req_prod 236 slots away(tx ring is full). From looking at the netfront driver code, it looks as if xennet_tx_buf_gc processing only happens if rsp_prod is more than rsp_cons. Our understanding is that netfront sets rsp_cons to tell the netback to start processing transmits from rsp_cons index onwards ti...

.../xen/interface/io/ring.h @@ -208,12 +208,12 @@ struct __name##_back_ring { \ #define RING_PUSH_REQUESTS(_r) do { \ - wmb(); /* back sees requests /before/ updated producer index */ \ + virt_wmb(); /* back sees requests /before/ updated producer index */ \ (_r)->sring->req_prod = (_r)->req_prod_pvt; \ } while (0) #define RING_PUSH_RESPONSES(_r) do { \ - wmb(); /* front sees responses /before/ updated producer index */ \ + virt_wmb(); /* front sees responses /before/ updated producer index */ \ (_r)->sring->rsp_prod = (_r)->rsp_prod_pvt;...

...xen/interface/io/ring.h @@ -208,12 +208,12 @@ struct __name##_back_ring { \ #define RING_PUSH_REQUESTS(_r) do { \ - wmb(); /* back sees requests /before/ updated producer index */ \ + __smp_wmb(); /* back sees requests /before/ updated producer index */ \ (_r)->sring->req_prod = (_r)->req_prod_pvt; \ } while (0) #define RING_PUSH_RESPONSES(_r) do { \ - wmb(); /* front sees responses /before/ updated producer index */ \ + __smp_wmb(); /* front sees responses /before/ updated producer index */ \ (_r)->sring->rsp_prod = (_r)->rsp_prod_pvt;...

...reading the consumer index. * */ mb(); memcpy(dst, data, avail); data += avail; len -= avail; /* Other side must not see new producer until data is * there. */ wmb(); intf->req_prod += avail; /* Implies mb(): other side will see the updated producer. */ notify_remote_via_evtchn(xen_store_evtchn); To me, it looks like for guests compiled with CONFIG_SMP, smp_wmb and smp_mb would be sufficient, so mb() and wmb() here are only nee...

...reading the consumer index. * */ mb(); memcpy(dst, data, avail); data += avail; len -= avail; /* Other side must not see new producer until data is * there. */ wmb(); intf->req_prod += avail; /* Implies mb(): other side will see the updated producer. */ notify_remote_via_evtchn(xen_store_evtchn); To me, it looks like for guests compiled with CONFIG_SMP, smp_wmb and smp_mb would be sufficient, so mb() and wmb() here are only nee...

...n/include/public/io/ring.h --- a/xen/include/public/io/ring.h Tue Sep 01 11:36:51 2009 +0100 +++ b/xen/include/public/io/ring.h Thu Oct 01 02:11:45 2009 +0800 @@ -97,7 +97,8 @@ struct __name##_sring { struct __name##_sring { \ RING_IDX req_prod, req_event; \ RING_IDX rsp_prod, rsp_event; \ - uint8_t pad[48]; \ + uint8_t netfront_smartpoll_active; \ + uint8_t pad[47];...

...h work to do. */ vif = poll_net_schedule_list(netbk); + /* + * This can sometimes happen because the test of + * list_empty(net_schedule_list) at the top of the + * loop is unlocked. Just go back and have another + * look. + */ if (!vif) continue; + if (vif->tx.sring->req_prod - vif->tx.req_cons > + XEN_NETIF_TX_RING_SIZE) { + netdev_err(vif->dev, + "Impossible number of requests. " + "req_prod %d, req_cons %d, size %ld\n", + vif->tx.sring->req_prod, vif->tx.req_cons, + XEN_NETIF_TX_RING_SIZE); + netb...

...r because the only use made of the unmasked value is the check which prevents the prod pointer overtaking the cons pointer. A ring peer which defeats this check will suffer only lost data. However, additionally, precautions need to be taken to ensure that req_cons and req_prod are only read once in each function. Without the use of volatile or some asm construct, the compiler can "prove" that req_cons and req_prod do not change unexpectedly and is permitted to "amplify" the read of (say) req_cons into two reads at different times, giv...

In blkback driver, after I/O requests are submitted to Dom-0 block I/O subsystem, blkback goes to ''sleep'' effectively without letting blkfront know about it (req_event isn''t set appropriately). Hence blkfront doesn''t notify blkback when it submits a new I/O thus delaying the ''dispatch'' of the new I/O to Dom-0 block I/O subsystem. The new I/O is

On Thu, Dec 17, 2015 at 02:57:26PM +0100, Peter Zijlstra wrote: > On Thu, Dec 17, 2015 at 03:16:20PM +0200, Michael S. Tsirkin wrote: > > On Thu, Dec 17, 2015 at 11:52:38AM +0100, Peter Zijlstra wrote: > > > On Thu, Dec 17, 2015 at 12:32:53PM +0200, Michael S. Tsirkin wrote: > > > > +static inline void virtio_store_mb(bool weak_barriers, > > > > +

On Thu, Dec 17, 2015 at 02:57:26PM +0100, Peter Zijlstra wrote: > On Thu, Dec 17, 2015 at 03:16:20PM +0200, Michael S. Tsirkin wrote: > > On Thu, Dec 17, 2015 at 11:52:38AM +0100, Peter Zijlstra wrote: > > > On Thu, Dec 17, 2015 at 12:32:53PM +0200, Michael S. Tsirkin wrote: > > > > +static inline void virtio_store_mb(bool weak_barriers, > > > > +

OK, here's a large patchset that implements the virtio spec update that I sent earlier. It supercedes the PUBLISH_USED_IDX patches I sent out earlier. I know it's a lot to ask but please test, and please consider for 2.6.40 :) I see nice performance improvements: one run showed going from 12 to 18 Gbit/s host to guest with netperf, but I did not spend a lot of time testing performance,

OK, here's a large patchset that implements the virtio spec update that I sent earlier. It supercedes the PUBLISH_USED_IDX patches I sent out earlier. I know it's a lot to ask but please test, and please consider for 2.6.40 :) I see nice performance improvements: one run showed going from 12 to 18 Gbit/s host to guest with netperf, but I did not spend a lot of time testing performance,

...t? */ -static inline int vring_need_event(__u16 event_idx, __u16 new_idx, __u16 old) +static inline int vring_need_event(__virtio16 event_idx, __virtio16 new_idx, __virtio16 old) { /* Note: Xen has similar logic for notification hold-off * in include/xen/interface/io/ring.h with req_event and req_prod * corresponding to event_idx + 1 and new_idx respectively. * Note also that req_event and req_prod in Xen start at 1, * event indexes in virtio start at 0. */ - return (__u16)(new_idx - event_idx - 1) < (__u16)(new_idx - old); + return (__virtio16)(new_idx - event_idx - 1) < (__virti...

...t? */ -static inline int vring_need_event(__u16 event_idx, __u16 new_idx, __u16 old) +static inline int vring_need_event(__virtio16 event_idx, __virtio16 new_idx, __virtio16 old) { /* Note: Xen has similar logic for notification hold-off * in include/xen/interface/io/ring.h with req_event and req_prod * corresponding to event_idx + 1 and new_idx respectively. * Note also that req_event and req_prod in Xen start at 1, * event indexes in virtio start at 0. */ - return (__u16)(new_idx - event_idx - 1) < (__u16)(new_idx - old); + return (__virtio16)(new_idx - event_idx - 1) < (__virti...

...mb(); > > memcpy(dst, data, avail); > data += avail; > len -= avail; > > /* Other side must not see new producer until data is * there. */ > wmb(); > intf->req_prod += avail; > > /* Implies mb(): other side will see the updated producer. */ > notify_remote_via_evtchn(xen_store_evtchn); > > To me, it looks like for guests compiled with CONFIG_SMP, smp_wmb and smp_mb > would be sufficient, so mb...