>>> "Xu, Quan" <quan...@intel.com> 05/19/16 3:35 AM >>> >On May 19, 2016 8:33 AM, Tian, Kevin <kevin.t...@intel.com> wrote: >> > From: Jan Beulich [mailto:jbeul...@suse.com] >> > Sent: Wednesday, May 18, 2016 11:05 PM >> > >>> On 18.05.16 at 14:53, <quan...@intel.com> wrote: >> > The patch can imo remain as is only if the new default timeout is >> > large enough for all possible cases (including those users who are >> > adventurous enough to turn on ATS). > >I only have an ATS device (MYRICOM Inc. Myri-10G Dual-Protocol NIC). 1 ms is >large enough for invalidation so far. >Any suggestion for this new default timeout?
Unless you have theoretical proof that a lower than the current value would suffice (as you do for the IOMMU side flushes), I think the default needs to remain the same as it is right now (which iirc is already _much_ lower than the real theoretical one). >> A single default value for both IOMMU-side and device-side is anyway not >> optimal. What about introducing a new knob e.g. vtd_qi_device_timeout >> specifically for device-side flush while using vtd_qi_timeout for other >> places? If >> device-side timeout is not specified, it is then default to vtd_qi_timeout. There should imo be a single command line option, allowing for two values to be passed (e.g. comma-separated). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
