>> Also note that '(b & ((u64)1 << 63)) ? 0x87 : 0x00;' is actually getting
>> compiled as '((s64)b >> 63) & 0x87', which is branchless and therefore makes
>> the
>> new version more efficient than one might expect:
>>
>> sar$0x3f,%rax
>> and$0x87,%eax
>>
>> It could even b
On 2017年03月30日 22:32, Michael S. Tsirkin wrote:
On Thu, Mar 30, 2017 at 02:00:08PM +0800, Jason Wang wrote:
On 2017年03月30日 04:48, Michael S. Tsirkin wrote:
We are going to add more parameters to find_vqs, let's wrap the call so
we don't need to tweak all drivers every time.
Signed-off-by: M
On Fri, Mar 31, 2017 at 12:04:42AM +0200, Ondrej Mosnacek wrote:
> The gf128mul_x_ble function is currently defined in gf128mul.c, because
> it depends on the gf128mul_table_be multiplication table.
>
> However, since the function is very small and only uses two values from
> the table, it is bett
The gf128mul_x_ble function is currently defined in gf128mul.c, because
it depends on the gf128mul_table_be multiplication table.
However, since the function is very small and only uses two values from
the table, it is better for it to be defined as inline function in
gf128mul.h. That way, the fun
Hi Eric,
2017-03-30 21:55 GMT+02:00 Eric Biggers :
> This is an improvement; I'm just thinking that maybe this should be done for
> all
> the gf128mul_x_*() functions, if only so that they use a consistent style and
> are all defined next to each other.
Right, that doesn't seem to be a bad idea.
Hi Ondrej,
On Thu, Mar 30, 2017 at 09:25:35PM +0200, Ondrej Mosnacek wrote:
> The gf128mul_x_ble function is currently defined in gf128mul.c, because
> it depends on the gf128mul_table_be multiplication table.
>
> However, since the function is very small and only uses two values from
> the table
The gf128mul_x_ble function is currently defined in gf128mul.c, because
it depends on the gf128mul_table_be multiplication table.
However, since the function is very small and only uses two values from
the table, it is better for it to be defined as inline function in
gf128mul.h. That way, the fun
On 2017-03-29 20:08, Tyrel Datwyler wrote:
On 03/29/2017 08:13 AM, Michal Suchánek wrote:
On Wed, 29 Mar 2017 16:51:35 +0200
Greg Kroah-Hartman wrote:
On Wed, Mar 29, 2017 at 02:56:39PM +0200, Michal Suchanek wrote:
While reviewing commit 11c6e16ee13a ("crypto: vmx - Adding asm
subroutines f
On Thu, Mar 30, 2017 at 02:00:08PM +0800, Jason Wang wrote:
>
>
> On 2017年03月30日 04:48, Michael S. Tsirkin wrote:
> > We are going to add more parameters to find_vqs, let's wrap the call so
> > we don't need to tweak all drivers every time.
> >
> > Signed-off-by: Michael S. Tsirkin
> > ---
>
>
Am Donnerstag, 16. März 2017, 10:52:48 CEST schrieb Herbert Xu:
Hi Herbert,
> More importantly, with the current code, a very large recvmsg
> would still work by doing it piecemeal. With your patch, won't
> it fail because sock_kmalloc could fail to allocate memory for
> the whole thing?
For te
On Wed, 29 Mar 2017 23:48:44 +0300
"Michael S. Tsirkin" wrote:
> We are going to add more parameters to find_vqs, let's wrap the call so
> we don't need to tweak all drivers every time.
>
> Signed-off-by: Michael S. Tsirkin
> ---
> drivers/block/virtio_blk.c | 3 +--
> drivers/
11 matches
Mail list logo
