Balance the irqs of the inside secure driver over all
available cpus.
Currently all interrupts are handled by the first CPU.
From my testing with IPSec AES-GCM 256
on my MCbin with 4 Cores I get a 50% speed increase:
Before the patch: 99.73 Kpps
With the patch: 151.25 Kpps
Signed-off-by: Sven Auhagen <[email protected]>
---
drivers/crypto/inside-secure/safexcel.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/inside-secure/safexcel.c b/drivers/crypto/inside-secure/safexcel.c
index 2cb53fbae841..f206084be08e 100644
--- a/drivers/crypto/inside-secure/safexcel.c
+++ b/drivers/crypto/inside-secure/safexcel.c
@@ -1135,11 +1135,12 @@ static irqreturn_t safexcel_irq_ring_thread(int irq, void *data)
static int safexcel_request_ring_irq(void *pdev, int irqid,
int is_pci_dev,
+ int ring_id,
irq_handler_t handler,
irq_handler_t threaded_handler,
struct safexcel_ring_irq_data *ring_irq_priv)
{
- int ret, irq;
+ int ret, irq, cpu;
struct device *dev;
if (IS_ENABLED(CONFIG_PCI) && is_pci_dev) {
@@ -1177,6 +1178,10 @@ static int safexcel_request_ring_irq(void *pdev, int irqid,
return ret;
}
+ // Set affinity
+ cpu = ring_id % num_online_cpus();
+ irq_set_affinity_hint(irq, get_cpu_mask(cpu));
+
return irq;
}
@@ -1611,6 +1616,7 @@ static int safexcel_probe_generic(void *pdev,
irq = safexcel_request_ring_irq(pdev,
EIP197_IRQ_NUMBER(i, is_pci_dev),
is_pci_dev,
+ i,
safexcel_irq_ring,
safexcel_irq_ring_thread,
ring_irq);
--
2.20.1
Sven Auhagen <[email protected]> wrote:
>
> + // Set affinity
> + cpu = ring_id % num_online_cpus();
> + irq_set_affinity_hint(irq, get_cpu_mask(cpu));
> +
This doesn't look right. There is no guarantee that the online
CPUs are the lowest bits in the bitmask. Also, what are you going
to do when the CPUs go down (or up)?
Cheers,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
> -----Original Message-----
> From: [email protected] <[email protected]> On Behalf Of Herbert Xu
> Sent: Thursday, July 16, 2020 9:22 AM
> To: Sven Auhagen <[email protected]>
> Cc: [email protected]
> Subject: Re: [PATCH 1/1] inside-secure irq balance
>
> <<< External Email >>>
> Sven Auhagen <[email protected]> wrote:
> >
> > + // Set affinity
> > + cpu = ring_id % num_online_cpus();
> > + irq_set_affinity_hint(irq, get_cpu_mask(cpu));
> > +
>
> This doesn't look right. There is no guarantee that the online
> CPUs are the lowest bits in the bitmask. Also, what are you going
> to do when the CPUs go down (or up)?
>
Ok, I was just about to test this patch with my hardware, but I suppose I can spare myself the
trouble if it doesn't make sense. I already had a hunch it was too simplistic for general use.
However, he does get a very significant speed boost out of this, which makes sense as having
the interrupts properly distributed AND pinned to a fixed CPU ensures proper workload
distribution and cache locality. In fact, this was the whole idea behind having multiple rings
and interrupts.
So is there a better way to achieve the same goal from the driver? Or is this really something
you cannot fix in the crypto driver itself?
> Cheers,
> --
> Email: Herbert Xu <[email protected]>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Regards,
Pascal van Leeuwen
Silicon IP Architect Multi-Protocol Engines, Rambus Security
Rambus ROTW Holding BV
+31-73 6581953
Note: The Inside Secure/Verimatrix Silicon IP team was recently acquired by Rambus.
Please be so kind to update your e-mail address book with my new e-mail address.
** This message and any attachments are for the sole use of the intended recipient(s). It may contain information that is confidential and privileged. If you are not the intended recipient of this message, you are prohibited from printing, copying, forwarding or saving it. Please delete the message and attachments and notify the sender immediately. **
Rambus Inc.<http://www.rambus.com>
On Thu, Jul 16, 2020 at 08:44:23AM +0000, Van Leeuwen, Pascal wrote:
> > -----Original Message-----
> > From: [email protected] <[email protected]> On Behalf Of Herbert Xu
> > Sent: Thursday, July 16, 2020 9:22 AM
> > To: Sven Auhagen <[email protected]>
> > Cc: [email protected]
> > Subject: Re: [PATCH 1/1] inside-secure irq balance
> >
> > <<< External Email >>>
> > Sven Auhagen <[email protected]> wrote:
> > >
> > > + // Set affinity
> > > + cpu = ring_id % num_online_cpus();
> > > + irq_set_affinity_hint(irq, get_cpu_mask(cpu));
> > > +
> >
> > This doesn't look right. There is no guarantee that the online
> > CPUs are the lowest bits in the bitmask. Also, what are you going
> > to do when the CPUs go down (or up)?
> >
You are correct, let me have a look at how to get the cpu bit correctly.
Well everything runs on the first CPU now, what do you do if that does down or up?
I think there is no mechanism in general at the moment for the current or my implementation.
>
> Ok, I was just about to test this patch with my hardware, but I suppose I can spare myself the
> trouble if it doesn't make sense. I already had a hunch it was too simplistic for general use.
> However, he does get a very significant speed boost out of this, which makes sense as having
> the interrupts properly distributed AND pinned to a fixed CPU ensures proper workload
> distribution and cache locality. In fact, this was the whole idea behind having multiple rings
> and interrupts.
>
> So is there a better way to achieve the same goal from the driver? Or is this really something
> you cannot fix in the crypto driver itself?
>
> > Cheers,
> > --
> > Email: Herbert Xu <[email protected]>
> > Home Page: https://eur03.safelinks.protection.outlook.com/?url=http:%2F%2Fgondor.apana.org.au%2F~herbert%2F&data=02%7C01%7Csven.auhagen%40voleatech.de%7C42783499b8fa4d11a9c608d8296474d2%7Cb82a99f679814a7295344d35298f847b%7C0%7C0%7C637304858734739951&sdata=GNleSUVRQe56P%2BkG6OQ3JH7AkXzKve6UP6ai5dKpN0M%3D&reserved=0
> > PGP Key: https://eur03.safelinks.protection.outlook.com/?url=http:%2F%2Fgondor.apana.org.au%2F~herbert%2Fpubkey.txt&data=02%7C01%7Csven.auhagen%40voleatech.de%7C42783499b8fa4d11a9c608d8296474d2%7Cb82a99f679814a7295344d35298f847b%7C0%7C0%7C637304858734739951&sdata=nqUVTBAMn1ifyR6lj9nyxBFQZNR9Au8r0aUJR44ziyc%3D&reserved=0
>
> Regards,
> Pascal van Leeuwen
> Silicon IP Architect Multi-Protocol Engines, Rambus Security
> Rambus ROTW Holding BV
> +31-73 6581953
>
> Note: The Inside Secure/Verimatrix Silicon IP team was recently acquired by Rambus.
> Please be so kind to update your e-mail address book with my new e-mail address.
>
>
> ** This message and any attachments are for the sole use of the intended recipient(s). It may contain information that is confidential and privileged. If you are not the intended recipient of this message, you are prohibited from printing, copying, forwarding or saving it. Please delete the message and attachments and notify the sender immediately. **
>
> Rambus Inc.<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rambus.com%2F&data=02%7C01%7Csven.auhagen%40voleatech.de%7C42783499b8fa4d11a9c608d8296474d2%7Cb82a99f679814a7295344d35298f847b%7C0%7C0%7C637304858734739951&sdata=gCBXI0rNikA%2FG2ME7RxWwwmkuUNl9wRlyQqDGbFoGHk%3D&reserved=0>
On Thu, Jul 16, 2020 at 08:44:23AM +0000, Van Leeuwen, Pascal wrote:
> > -----Original Message-----
> > From: [email protected] <[email protected]> On Behalf Of Herbert Xu
> > Sent: Thursday, July 16, 2020 9:22 AM
> > To: Sven Auhagen <[email protected]>
> > Cc: [email protected]
> > Subject: Re: [PATCH 1/1] inside-secure irq balance
> >
> > <<< External Email >>>
> > Sven Auhagen <[email protected]> wrote:
> > >
> > > + // Set affinity
> > > + cpu = ring_id % num_online_cpus();
> > > + irq_set_affinity_hint(irq, get_cpu_mask(cpu));
> > > +
> >
> > This doesn't look right. There is no guarantee that the online
> > CPUs are the lowest bits in the bitmask. Also, what are you going
> > to do when the CPUs go down (or up)?
> >
After some further reading this is only a hint.
If the CPU is not online a different one will be used.
If the CPU goes offline the cpu hotplug code makes sure to move the irq
to a different CPU or remove the hint completely.
This should be safe to use and btw other crypto drivers do it the same way.
For example cavium nitrox or cavium cpt.
Best
Sven
>
> Ok, I was just about to test this patch with my hardware, but I suppose I can spare myself the
> trouble if it doesn't make sense. I already had a hunch it was too simplistic for general use.
> However, he does get a very significant speed boost out of this, which makes sense as having
> the interrupts properly distributed AND pinned to a fixed CPU ensures proper workload
> distribution and cache locality. In fact, this was the whole idea behind having multiple rings
> and interrupts.
>
> So is there a better way to achieve the same goal from the driver? Or is this really something
> you cannot fix in the crypto driver itself?
>
> > Cheers,
> > --
> > Email: Herbert Xu <[email protected]>
> > Home Page: https://eur03.safelinks.protection.outlook.com/?url=http:%2F%2Fgondor.apana.org.au%2F~herbert%2F&data=02%7C01%7Csven.auhagen%40voleatech.de%7C42783499b8fa4d11a9c608d8296474d2%7Cb82a99f679814a7295344d35298f847b%7C0%7C0%7C637304858734739951&sdata=GNleSUVRQe56P%2BkG6OQ3JH7AkXzKve6UP6ai5dKpN0M%3D&reserved=0
> > PGP Key: https://eur03.safelinks.protection.outlook.com/?url=http:%2F%2Fgondor.apana.org.au%2F~herbert%2Fpubkey.txt&data=02%7C01%7Csven.auhagen%40voleatech.de%7C42783499b8fa4d11a9c608d8296474d2%7Cb82a99f679814a7295344d35298f847b%7C0%7C0%7C637304858734739951&sdata=nqUVTBAMn1ifyR6lj9nyxBFQZNR9Au8r0aUJR44ziyc%3D&reserved=0
>
> Regards,
> Pascal van Leeuwen
> Silicon IP Architect Multi-Protocol Engines, Rambus Security
> Rambus ROTW Holding BV
> +31-73 6581953
>
> Note: The Inside Secure/Verimatrix Silicon IP team was recently acquired by Rambus.
> Please be so kind to update your e-mail address book with my new e-mail address.
>
>
> ** This message and any attachments are for the sole use of the intended recipient(s). It may contain information that is confidential and privileged. If you are not the intended recipient of this message, you are prohibited from printing, copying, forwarding or saving it. Please delete the message and attachments and notify the sender immediately. **
>
> Rambus Inc.<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rambus.com%2F&data=02%7C01%7Csven.auhagen%40voleatech.de%7C42783499b8fa4d11a9c608d8296474d2%7Cb82a99f679814a7295344d35298f847b%7C0%7C0%7C637304858734739951&sdata=gCBXI0rNikA%2FG2ME7RxWwwmkuUNl9wRlyQqDGbFoGHk%3D&reserved=0>
On Thu, Jul 16, 2020 at 11:21:36AM +0200, Sven Auhagen wrote:
>
> You are correct, let me have a look at how to get the cpu bit correctly.
> Well everything runs on the first CPU now, what do you do if that does down or up?
> I think there is no mechanism in general at the moment for the current or my implementation.
Unless the driver changed it the default affinity should be all
CPUs, no? In which case if the first CPU goes down it'll just move
to the second CPU.
Cheers,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Thu, Jul 16, 2020 at 10:04:20PM +1000, Herbert Xu wrote:
> On Thu, Jul 16, 2020 at 11:21:36AM +0200, Sven Auhagen wrote:
> >
> > You are correct, let me have a look at how to get the cpu bit correctly.
> > Well everything runs on the first CPU now, what do you do if that does down or up?
> > I think there is no mechanism in general at the moment for the current or my implementation.
>
> Unless the driver changed it the default affinity should be all
> CPUs, no? In which case if the first CPU goes down it'll just move
> to the second CPU.
Alright, that makes sense, thank you.
As I said in my second email yesterday, it is just a hint and not binding.
I run some tests and here is what happens when I disable CPU3 on my 4 Core MCBin:
[641628.819934] crypto-safexcel f2800000.crypto: EIP197:241(0,1,4,4)-HIA:230(2,6,6),PE:133/332,alg:7ffdf000
[641628.823954] crypto-safexcel f2800000.crypto: TRC init: 15360d,80a (48r,256h)
[641628.825326] crypto-safexcel f2800000.crypto: firmware: direct-loading firmware inside-secure/eip197b/ifpp.bin
[641628.825693] crypto-safexcel f2800000.crypto: firmware: direct-loading firmware inside-secure/eip197b/ipue.bin
[641629.033302] alg: No test for authenc(hmac(sha224),cbc(aes)) (safexcel-authenc-hmac-sha224-cbc-aes)
[641629.044442] alg: No test for authenc(hmac(sha384),cbc(aes)) (safexcel-authenc-hmac-sha384-cbc-aes)
[641629.057356] alg: No test for authenc(hmac(sha224),rfc3686(ctr(aes))) (safexcel-authenc-hmac-sha224-ctr-aes)
[641698.795895] IRQ 38: no longer affine to CPU3
[641698.795917] IRQ 54: no longer affine to CPU3
[641698.795928] IRQ 59: no longer affine to CPU3
[641698.795942] IRQ69: set affinity failed(-22).
[641698.795950] IRQ70: set affinity failed(-22).
[641698.795959] IRQ73: set affinity failed(-22).
[641698.795969] IRQ 77: no longer affine to CPU3
[641698.796131] CPU3: shutdown
[641698.796156] psci: CPU3 killed (polled 0 ms)
74: 1363 0 0 ICU-NSR 88 Level f2800000.crypto
75: 0 1772 0 ICU-NSR 89 Level f2800000.crypto
76: 0 0 1427 ICU-NSR 90 Level f2800000.crypto
77: 0 0 0 ICU-NSR 91 Level f2800000.crypto
IRQ 77 was bound to CPU3 via the hint is no longer affine now
and actually bound to CPU0.
When I disable CPU1 and CPU3 and load the module I get:
74: 4089 0 ICU-NSR 88 Level f2800000.crypto
75: 1772 0 ICU-NSR 89 Level f2800000.crypto
76: 1427 2854 ICU-NSR 90 Level f2800000.crypto
77: 2824 0 ICU-NSR 91 Level f2800000.crypto
where you can see that the affinity hint is ignored for CPU1
which is selected because of number of cpus online is 2 now.
Does that answer your question?
Best
Sven
>
> Cheers,
> --
> Email: Herbert Xu <[email protected]>
> Home Page: https://eur03.safelinks.protection.outlook.com/?url=http:%2F%2Fgondor.apana.org.au%2F~herbert%2F&data=02%7C01%7Csven.auhagen%40voleatech.de%7C0790b23c7a61493c8bfe08d82980621d%7Cb82a99f679814a7295344d35298f847b%7C0%7C1%7C637304978692090806&sdata=QZUqtMuwN8vOxUK1tjFiENuwPD6gIxHpTvntLdbqTqg%3D&reserved=0
> PGP Key: https://eur03.safelinks.protection.outlook.com/?url=http:%2F%2Fgondor.apana.org.au%2F~herbert%2Fpubkey.txt&data=02%7C01%7Csven.auhagen%40voleatech.de%7C0790b23c7a61493c8bfe08d82980621d%7Cb82a99f679814a7295344d35298f847b%7C0%7C1%7C637304978692090806&sdata=Z3GYc1YWWeenCLYZUKXxzwWDQnrmvEuBHStIcPFcOp0%3D&reserved=0
On Fri, Jul 17, 2020 at 07:01:34AM +0200, Sven Auhagen wrote:
>
> Alright, that makes sense, thank you.
>
> As I said in my second email yesterday, it is just a hint and not binding.
> I run some tests and here is what happens when I disable CPU3 on my 4 Core MCBin:
I don't think we should be adding policy logic like this into
individual drivers. If the kernel should be doing this at all
it should be done in the IRQ layer. The alternative is to do
it in user-space through irqbalance.
Cheers,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Fri, Jul 17, 2020 at 03:20:50PM +1000, Herbert Xu wrote:
> On Fri, Jul 17, 2020 at 07:01:34AM +0200, Sven Auhagen wrote:
> >
> > Alright, that makes sense, thank you.
> >
> > As I said in my second email yesterday, it is just a hint and not binding.
> > I run some tests and here is what happens when I disable CPU3 on my 4 Core MCBin:
>
> I don't think we should be adding policy logic like this into
> individual drivers. If the kernel should be doing this at all
> it should be done in the IRQ layer. The alternative is to do
> it in user-space through irqbalance.
I disagree as this is common practice among other kernel drivers
like ethernet.
Also this is also beeing done in other crypto drivers not to say
that the speed improvements are pretty significant.
irqbalance can of course also do the job but there is no downside
of adding the irq hint in the driver.
Best
Sven
>
> Cheers,
> --
> Email: Herbert Xu <[email protected]>
> Home Page: https://eur03.safelinks.protection.outlook.com/?url=http:%2F%2Fgondor.apana.org.au%2F~herbert%2F&data=02%7C01%7Csven.auhagen%40voleatech.de%7C85a3fd0bef964ac07a1d08d82a112f12%7Cb82a99f679814a7295344d35298f847b%7C0%7C0%7C637305600595365880&sdata=E%2FnccG%2FNnIivbW0A2mE%2B9k89tWEWA%2B%2FcljshtLi29TI%3D&reserved=0
> PGP Key: https://eur03.safelinks.protection.outlook.com/?url=http:%2F%2Fgondor.apana.org.au%2F~herbert%2Fpubkey.txt&data=02%7C01%7Csven.auhagen%40voleatech.de%7C85a3fd0bef964ac07a1d08d82a112f12%7Cb82a99f679814a7295344d35298f847b%7C0%7C0%7C637305600595365880&sdata=e3f%2FXrlr0k9c1Cdv5kBo6zp5gtkPtkBNMNTJhB2Dg8c%3D&reserved=0
On Fri, Jul 17, 2020 at 08:35:04AM +0200, Sven Auhagen wrote:
>
> I disagree as this is common practice among other kernel drivers
> like ethernet.
> Also this is also beeing done in other crypto drivers not to say
> that the speed improvements are pretty significant.
>
> irqbalance can of course also do the job but there is no downside
> of adding the irq hint in the driver.
If you're going to do this please at least use the function
cpumask_local_spread.
Thanks,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Fri, Jul 17, 2020 at 04:57:38PM +1000, Herbert Xu wrote:
> On Fri, Jul 17, 2020 at 08:35:04AM +0200, Sven Auhagen wrote:
> >
> > I disagree as this is common practice among other kernel drivers
> > like ethernet.
> > Also this is also beeing done in other crypto drivers not to say
> > that the speed improvements are pretty significant.
> >
> > irqbalance can of course also do the job but there is no downside
> > of adding the irq hint in the driver.
>
> If you're going to do this please at least use the function
> cpumask_local_spread.
I do not have access to a numa node inside the inside secure
driver and can only use -1 as the cpumask_local_spread numa node.
Is that what you are looking for?
Best
Sven
>
> Thanks,
> --
> Email: Herbert Xu <[email protected]>
> Home Page: https://eur03.safelinks.protection.outlook.com/?url=http:%2F%2Fgondor.apana.org.au%2F~herbert%2F&data=02%7C01%7Csven.auhagen%40voleatech.de%7C11ec864588ea43cb2b5508d82a1eb424%7Cb82a99f679814a7295344d35298f847b%7C0%7C1%7C637305658666145675&sdata=U0TRKq1keey2jogZyelLwvwfSpj4SavJAhumM63phs0%3D&reserved=0
> PGP Key: https://eur03.safelinks.protection.outlook.com/?url=http:%2F%2Fgondor.apana.org.au%2F~herbert%2Fpubkey.txt&data=02%7C01%7Csven.auhagen%40voleatech.de%7C11ec864588ea43cb2b5508d82a1eb424%7Cb82a99f679814a7295344d35298f847b%7C0%7C1%7C637305658666155670&sdata=FDSkrK3t9OMTaA%2FRxMcgKgqU4wVBx%2BomSA%2BUlZtNgBU%3D&reserved=0
> -----Original Message-----
> From: Sven Auhagen <[email protected]>
> Sent: Friday, July 17, 2020 9:54 AM
> To: Herbert Xu <[email protected]>
> Cc: Van Leeuwen, Pascal <[email protected]>; [email protected]
> Subject: Re: [PATCH 1/1] inside-secure irq balance
>
> <<< External Email >>>
> On Fri, Jul 17, 2020 at 04:57:38PM +1000, Herbert Xu wrote:
> > On Fri, Jul 17, 2020 at 08:35:04AM +0200, Sven Auhagen wrote:
> > >
> > > I disagree as this is common practice among other kernel drivers
> > > like ethernet.
> > > Also this is also beeing done in other crypto drivers not to say
> > > that the speed improvements are pretty significant.
> > >
> > > irqbalance can of course also do the job but there is no downside
> > > of adding the irq hint in the driver.
> >
> > If you're going to do this please at least use the function
> > cpumask_local_spread.
>
> I do not have access to a numa node inside the inside secure
> driver and can only use -1 as the cpumask_local_spread numa node.
> Is that what you are looking for?
>
Now I am no expert on all this kernel IRQ balancing stuff, so I'm not going to
comment on how to do it or what is appropriate.
But I do want to emphasize that this patch is in line with how the hardware
was intended to be used i.e. have each ring handled by a dedicated CPU.
Also, you have to keep in mind that this driver does not have to run on
every possible system out there, it ONLY needs to run on those particular
SOC's that actually embed this hardware IP. And I know exactly which ones,
since it all has to go through me first :-) It only ever runs on embedded
CPU clusters (ARM, MIPS, Atom and C-Sky), no need to worry about NUMA
nodes.
> Best
> Sven
>
> >
> > Thanks,
> > --
> > Email: Herbert Xu <[email protected]>
> > Home Page:
> https://eur03.safelinks.protection.outlook.com/?url=http:%2F%2Fgondor.apana.org.au%2F~herbert%2F&data=02%7C01%7Csve
> n.auhagen%40voleatech.de%7C11ec864588ea43cb2b5508d82a1eb424%7Cb82a99f679814a7295344d35298f847b%7C0%7C1%7C6373056
> 58666145675&sdata=U0TRKq1keey2jogZyelLwvwfSpj4SavJAhumM63phs0%3D&reserved=0
> > PGP Key:
> https://eur03.safelinks.protection.outlook.com/?url=http:%2F%2Fgondor.apana.org.au%2F~herbert%2Fpubkey.txt&data=02%7
> C01%7Csven.auhagen%40voleatech.de%7C11ec864588ea43cb2b5508d82a1eb424%7Cb82a99f679814a7295344d35298f847b%7C0%7C1
> %7C637305658666155670&sdata=FDSkrK3t9OMTaA%2FRxMcgKgqU4wVBx%2BomSA%2BUlZtNgBU%3D&reserved=0
Regards,
Pascal van Leeuwen
Silicon IP Architect Multi-Protocol Engines, Rambus Security
Rambus ROTW Holding BV
+31-73 6581953
Note: The Inside Secure/Verimatrix Silicon IP team was recently acquired by Rambus.
Please be so kind to update your e-mail address book with my new e-mail address.
** This message and any attachments are for the sole use of the intended recipient(s). It may contain information that is confidential and privileged. If you are not the intended recipient of this message, you are prohibited from printing, copying, forwarding or saving it. Please delete the message and attachments and notify the sender immediately. **
Rambus Inc.<http://www.rambus.com>
On Fri, Jul 17, 2020 at 09:53:34AM +0200, Sven Auhagen wrote:
>
> I do not have access to a numa node inside the inside secure
> driver and can only use -1 as the cpumask_local_spread numa node.
> Is that what you are looking for?
Yes, at least it won't be giving us CPUs that are off-line.
Cheers,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt