[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] ioreq_broadcast(): accept partial broadcast success
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: "Per Bilse (3P)" <Per.Bilse@xxxxxxxxxx>
- Date: Tue, 6 Dec 2022 10:43:46 +0000
- Accept-language: en-US
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=vAWf+ifIjwxHSFIPq0aoWYCUpeD4/zwsmJJWYemYdhM=; b=VubZeE1NTl4WKGtRFwcInWrB/CIjmWJGQbXXFISIIlXz/DdAY+pqDFw8hx3ZO6ems1u/QKm2zpL+RISoyLyHXCojUZWM1W8FRoOMDAChoKycP22W3FgdD5LR7IJChXFRlamUyolath0LUAgnuc2cUi4cPHgcfvXSDc0v3Q/MwG2av/7QBtpfb6fGEzfdBE1+/bPyGYaCpCmeNIRMMCDvh+i/pg/3lDP1ZB55n69J6tqN8tFfcGMFvBUkLLPpHGKzMGzZgukYkl4p42ry0foVq7NIttoybOYo4fPh1X6VNN6hv2s79SpOcngB6P5u1GjoWylUAwHJ239YeHei0ABf3Q==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Lug4Mk13t02kYbz4PjczHXeg5BpkoUBVJcXC6Wu9VY0V1zd3RwacHcl+TOZMQyIW8Wj3oH9vl1WRDwJTKalSh0spJ2igX0Op1QqUmyBGxKyusXEGYhaqyQYtQ8IcPSq/weefC0NchJi3Do448V6tVDn4Z/8h0XuPOVhHVBXkwk0bhzp5igS6/4cDLjrS2xeyunfY3Ei1pfiLOI9FqwzNEBbojVDJ2dijhAgjVp+wU+gsE5m9/EoBt2CpioqkEfaI/wLBYrICcQy60NRZBlDXoPg81dVSo3AlpNz0bE2eaZXK4d//xySHxQHBQvglzgZ5TdAXjUHUQZdh03nkXpLYsw==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: Paul Durrant <paul@xxxxxxx>, Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>, Roger Pau Monne <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Julien Grall <julien@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Tue, 06 Dec 2022 10:43:55 +0000
- Ironport-data: A9a23:gJAE6aqafSoL3aq8preQEtWlz1ZeBmLdZBIvgKrLsJaIsI4StFCzt garIBmCaanYN2byc94nPIvk9x8C6sfSnIUwQQVu+CA9RHsU+ZuZCYyVIHmrMnLJJKUvbq7FA +Y2MYCccZ9uHhcwgj/3b9ANeFEljfngqoLUUbKCYWYpAFc+E0/NsDo788YhmIlknNOlNA2Ev NL2sqX3NUSsnjV5KQr40YrawP9UlKm06W1wUmAWP6gR5gaEzydNVvrzGInqR5fGatgMdgKFb 76rIIGRpgvx4xorA9W5pbf3GmVirmn6ZFXmZtJ+AsBOszAazsAA+v9T2Mk0MC+7vw6hjdFpo OihgLTrIesf0g8gr8xGO/VQO3kW0aSrY9YrK1Dn2SCY5xWun3cBX5yCpaz5VGEV0r8fPI1Ay RAXACsmVQuNqumw+p7hY+lhuOc+dNHXPbpK7xmMzRmBZRonabbqZvySoPN9gnI3jM0IGuvCb c0EbzYpdA7HfxBEJlYQDtQ5gfusgX78NTZfrTp5p4JuuzSVkFM3jeiraYKIEjCJbZw9ckKwn m/cuU74BgoXHNee1SCE4jSngeqncSbTCNxCTOPor6QCbFu75EAiBTM5dmGH/rrnkXyVBZFFI n025X97xUQ13AnxJjXnZDW6qnOZuh8XW/JLDvY3rgqKz8L8+w+EAkAUQzgHb8Yp3OcpQRQ62 1nPmMnmbRRtrbmURHS15rqS6zSoNkA9PWIEICMJUwYBy93iu50oyALCSM55F6y4hcGzHiv/q w1mtwA7jrQXyMIOiaOy+Amfhyr2/8CUCAko+g/QQ2SpqBtjY5KobJCp7l6d6utcKIGeTR+Ku 31sd9Wi0d3ixKqlzESlKNjh1pnzjxpZGFUwWWJSIqQ=
- Ironport-hdrordr: A9a23:8ZIFpKM4RP6EYsBcTvyjsMiBIKoaSvp033AB3UoZc20zTiX+ra yTdZUguiMc7Qx7ZJhOo7690cW7IE80l6QFgrX5TI3DYOCOggLBRuxfBODZsl/d8kPFh4pg/J YlX69iCMDhSXhW5PyKhjVQyuxQpeW6zA==
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
- Thread-index: AQHZCV+dQ5gC8MSrQkutQViuEWIcyQ==
- Thread-topic: [PATCH] ioreq_broadcast(): accept partial broadcast success
On 28/11/2022 08:21, Jan Beulich wrote:
> In addition I think ignoring failure (and, as said by Julien, only because
> of no bufioreq being registered) is (kind of implicitly) valid only for
> buffered requests. Hence I'm unconvinced of the need of a new boolean
> function parameter. Instead I think we need a new IOREQ_STATUS_... value
> representing the "not registered" case. And that could then be used by
> ioreq_broadcast() to skip incrementing of "failed".
I think I have been thinking about this the wrong way. My thinking has
been that dropping an update (buffered or not) would be correct only
in special cases such as timeoffset, and it would therefore generally
be an error if a buffered update was directed to a handler that hadn't
registered for buffered updates. The thinking in this proposal suggests
that handlers are generally free to choose whether or not to accept
buffered updates. I wouldn't have suspected this, but I assume then
that this is perfectly reasonable in the context of Xen IO handling, so
I'll go with that.
Best,
-- Per
|
