On 30/07/2017 12:57, Moni Shoua wrote:
Have you considered using ip_route_output_key() for IPv4 or
ip6_route_output() for IPv6 to decide if this is a loopback?
For reference you can check the flow starting at rdma_resolve_ip()
Hi Moni,
Yes, I had looked into it, but I haven't seen how I
On 30/07/2017 12:57, Moni Shoua wrote:
Have you considered using ip_route_output_key() for IPv4 or
ip6_route_output() for IPv6 to decide if this is a loopback?
For reference you can check the flow starting at rdma_resolve_ip()
Hi Moni,
Yes, I had looked into it, but I haven't seen how I
On 27/07/2017 10:04, Moni Shoua wrote:
On Wed, Jul 26, 2017 at 10:57 PM, Yuval Shaia <yuval.sh...@oracle.com> wrote:
On Wed, Jul 26, 2017 at 05:52:48PM +0300, Marcel Apfelbaum wrote:
Currently a packet is marked for loopback only if the source and
destination address match. This is not
On 27/07/2017 10:04, Moni Shoua wrote:
On Wed, Jul 26, 2017 at 10:57 PM, Yuval Shaia wrote:
On Wed, Jul 26, 2017 at 05:52:48PM +0300, Marcel Apfelbaum wrote:
Currently a packet is marked for loopback only if the source and
destination address match. This is not enough when multiple
gids
On 27/07/2017 10:36, Leon Romanovsky wrote:
On Wed, Jul 26, 2017 at 05:52:48PM +0300, Marcel Apfelbaum wrote:
Currently a packet is marked for loopback only if the source and
destination address match. This is not enough when multiple
gids are present in rxe's gid table and the traffic is
from
On 27/07/2017 10:36, Leon Romanovsky wrote:
On Wed, Jul 26, 2017 at 05:52:48PM +0300, Marcel Apfelbaum wrote:
Currently a packet is marked for loopback only if the source and
destination address match. This is not enough when multiple
gids are present in rxe's gid table and the traffic is
from
table.
Signed-off-by: Marcel Apfelbaum <mar...@redhat.com>
---
drivers/infiniband/sw/rxe/rxe_net.c | 47 +++--
1 file changed, 45 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/sw/rxe/rxe_net.c
b/drivers/infiniband/sw/rxe/rxe_net.c
index c
table.
Signed-off-by: Marcel Apfelbaum
---
drivers/infiniband/sw/rxe/rxe_net.c | 47 +++--
1 file changed, 45 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/sw/rxe/rxe_net.c
b/drivers/infiniband/sw/rxe/rxe_net.c
index c3a140e..b76a9a3 100644
On 11/22/2015 05:54 PM, David Woodhouse wrote:
On Sun, 2015-11-22 at 15:06 +0200, Marcel Apfelbaum wrote:
I tried to generate a DMAR table that excludes some devices from
IOMMU translation, however it does not help.
The reason is, as far as I understand, that Linux kernel does
not allow any
On 11/08/2015 01:49 PM, Joerg Roedel wrote:
On Sun, Nov 08, 2015 at 12:37:47PM +0200, Michael S. Tsirkin wrote:
I have no problem with that. For example, can we teach
the DMA API on intel x86 to use PT for virtio by default?
That would allow merging Andy's patches with
full compatibility with
On 11/08/2015 01:49 PM, Joerg Roedel wrote:
On Sun, Nov 08, 2015 at 12:37:47PM +0200, Michael S. Tsirkin wrote:
I have no problem with that. For example, can we teach
the DMA API on intel x86 to use PT for virtio by default?
That would allow merging Andy's patches with
full compatibility with
On 11/22/2015 05:54 PM, David Woodhouse wrote:
On Sun, 2015-11-22 at 15:06 +0200, Marcel Apfelbaum wrote:
I tried to generate a DMAR table that excludes some devices from
IOMMU translation, however it does not help.
The reason is, as far as I understand, that Linux kernel does
not allow any
On Thu, 2014-10-23 at 09:54 -0600, Alex Williamson wrote:
> On Thu, 2014-10-23 at 18:00 +0300, Marcel Apfelbaum wrote:
> > On Thu, 2014-10-23 at 08:49 -0600, Alex Williamson wrote:
> > > On Thu, 2014-10-23 at 17:33 +0300, Marcel Apfelbaum wrote:
> > > > On Thu, 2
On Thu, 2014-10-23 at 08:49 -0600, Alex Williamson wrote:
> On Thu, 2014-10-23 at 17:33 +0300, Marcel Apfelbaum wrote:
> > On Thu, 2014-10-23 at 07:57 -0600, Alex Williamson wrote:
> > > On Thu, 2014-10-23 at 13:44 +, Stuart Yoder wrote:
> > > >
&
On Thu, 2014-10-23 at 07:57 -0600, Alex Williamson wrote:
> On Thu, 2014-10-23 at 13:44 +, Stuart Yoder wrote:
> >
> > > -Original Message-
> > > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > > Sent: Wednesday, October 22, 201
On Thu, 2014-10-23 at 13:51 +, Stuart Yoder wrote:
>
> > -Original Message-
> > From: Marcel Apfelbaum [mailto:marce...@redhat.com]
> > Sent: Thursday, October 23, 2014 7:32 AM
> > To: Alex Williamson
> > Cc: linux-...@vger.kernel.org; bhelg
On Thu, 2014-10-23 at 07:11 -0600, Alex Williamson wrote:
> On Thu, 2014-10-23 at 15:32 +0300, Marcel Apfelbaum wrote:
> > On Wed, 2014-10-22 at 12:32 -0600, Alex Williamson wrote:
> > > [cc+ stuart]
> > >
> > > On Mon, 2014-10-20 at 17:04 +0300, Marcel Apf
Mon, Oct 20, 2014 at 8:04 AM, Marcel Apfelbaum wrote:
> > Scanning a lot of devices during boot requires a lot of time.
>
> I think what takes a lot of time is the .probe() method for some
> drivers, right? I first thought you meant that it took a long time
> for the PC
On Wed, 2014-10-22 at 12:32 -0600, Alex Williamson wrote:
> [cc+ stuart]
>
> On Mon, 2014-10-20 at 17:04 +0300, Marcel Apfelbaum wrote:
> > Scanning a lot of devices during boot requires a lot of time.
> > On other scenarios there is a need to bind a driver to a specific s
On Wed, 2014-10-22 at 12:32 -0600, Alex Williamson wrote:
[cc+ stuart]
On Mon, 2014-10-20 at 17:04 +0300, Marcel Apfelbaum wrote:
Scanning a lot of devices during boot requires a lot of time.
On other scenarios there is a need to bind a driver to a specific slot.
Binding devices
:04 AM, Marcel Apfelbaum marce...@redhat.com wrote:
Scanning a lot of devices during boot requires a lot of time.
I think what takes a lot of time is the .probe() method for some
drivers, right? I first thought you meant that it took a long time
for the PCI core to enumerate a lot of devices
On Thu, 2014-10-23 at 07:11 -0600, Alex Williamson wrote:
On Thu, 2014-10-23 at 15:32 +0300, Marcel Apfelbaum wrote:
On Wed, 2014-10-22 at 12:32 -0600, Alex Williamson wrote:
[cc+ stuart]
On Mon, 2014-10-20 at 17:04 +0300, Marcel Apfelbaum wrote:
Scanning a lot of devices during
On Thu, 2014-10-23 at 13:51 +, Stuart Yoder wrote:
-Original Message-
From: Marcel Apfelbaum [mailto:marce...@redhat.com]
Sent: Thursday, October 23, 2014 7:32 AM
To: Alex Williamson
Cc: linux-...@vger.kernel.org; bhelg...@google.com;
linux-kernel@vger.kernel.org; mar
On Thu, 2014-10-23 at 07:57 -0600, Alex Williamson wrote:
On Thu, 2014-10-23 at 13:44 +, Stuart Yoder wrote:
-Original Message-
From: Alex Williamson [mailto:alex.william...@redhat.com]
Sent: Wednesday, October 22, 2014 1:33 PM
To: Marcel Apfelbaum
Cc: linux
On Thu, 2014-10-23 at 08:49 -0600, Alex Williamson wrote:
On Thu, 2014-10-23 at 17:33 +0300, Marcel Apfelbaum wrote:
On Thu, 2014-10-23 at 07:57 -0600, Alex Williamson wrote:
On Thu, 2014-10-23 at 13:44 +, Stuart Yoder wrote:
-Original Message-
From: Alex
On Thu, 2014-10-23 at 09:54 -0600, Alex Williamson wrote:
On Thu, 2014-10-23 at 18:00 +0300, Marcel Apfelbaum wrote:
On Thu, 2014-10-23 at 08:49 -0600, Alex Williamson wrote:
On Thu, 2014-10-23 at 17:33 +0300, Marcel Apfelbaum wrote:
On Thu, 2014-10-23 at 07:57 -0600, Alex Williamson
slots to specific drivers use:
pci=driver[:xx:xx.x]=foo,driver[:xx:xx.x]=bar,...
Signed-off-by: Marcel Apfelbaum
---
v3 -> v4:
- Addressed Alex Williamson's comments:
- Modified the type of driver_override_entry's fields
- Used PCI_DEVFN when appropriated
- Removed redund
In order to bind PCI slots to specific drivers use:
pci=driver[:xx:xx.x]=foo,driver[:xx:xx.x]=bar,...
Signed-off-by: Marcel Apfelbaum marce...@redhat.com
---
v3 - v4:
- Addressed Alex Williamson's comments:
- Modified the type of driver_override_entry's fields
- Used
On Wed, 2014-10-01 at 12:48 -0600, Alex Williamson wrote:
> On Tue, 2014-09-30 at 19:38 +0300, Marcel Apfelbaum wrote:
> > Scanning a lot of devices during boot requires a lot of time.
> > On other scenarios there is a need to bind a driver to a specific slot.
> >
> >
On Wed, 2014-10-01 at 12:48 -0600, Alex Williamson wrote:
On Tue, 2014-09-30 at 19:38 +0300, Marcel Apfelbaum wrote:
Scanning a lot of devices during boot requires a lot of time.
On other scenarios there is a need to bind a driver to a specific slot.
Binding devices to pci-stub driver
On Tue, 2014-10-07 at 18:02 +0300, Michael S. Tsirkin wrote:
> On Tue, Oct 07, 2014 at 05:48:32PM +0300, Marcel Apfelbaum wrote:
> > Scanning a lot of devices during boot requires a lot of time.
> > On other scenarios there is a need to bind a driver to a specific slot.
> >
slots to specific drivers use:
pci=driver[:xx:xx.x]=foo,driver[:xx:xx.x]=bar,...
Signed-off-by: Marcel Apfelbaum
---
v2 -> v3:
- Corrected subject line
v1 -> v2:
- Addressed Michael S. Tsirkin comments
- Removed 32 slots limitation
- Better handling of memory allo
slots to specific drivers use:
pci=driver[:xx:xx.x]=foo,driver[:xx:xx.x]=bar,...
Signed-off-by: Marcel Apfelbaum
---
v1 -> v2:
- Addressed Michael S. Tsirkin comments
- Removed 32 slots limitation
- Better handling of memory allocation failures
(preferred BUG_ON over er
In order to bind PCI slots to specific drivers use:
pci=driver[:xx:xx.x]=foo,driver[:xx:xx.x]=bar,...
Signed-off-by: Marcel Apfelbaum marce...@redhat.com
---
v1 - v2:
- Addressed Michael S. Tsirkin comments
- Removed 32 slots limitation
- Better handling of memory
In order to bind PCI slots to specific drivers use:
pci=driver[:xx:xx.x]=foo,driver[:xx:xx.x]=bar,...
Signed-off-by: Marcel Apfelbaum marce...@redhat.com
---
v2 - v3:
- Corrected subject line
v1 - v2:
- Addressed Michael S. Tsirkin comments
- Removed 32 slots limitation
On Tue, 2014-10-07 at 18:02 +0300, Michael S. Tsirkin wrote:
On Tue, Oct 07, 2014 at 05:48:32PM +0300, Marcel Apfelbaum wrote:
Scanning a lot of devices during boot requires a lot of time.
On other scenarios there is a need to bind a driver to a specific slot.
Binding devices to pci-stub
On Thu, 2014-10-02 at 11:12 +0300, Michael S. Tsirkin wrote:
> On Wed, Oct 01, 2014 at 12:51:03PM -0600, Alex Williamson wrote:
> > On Wed, 2014-10-01 at 10:50 +0300, Marcel Apfelbaum wrote:
> > > On Wed, 2014-10-01 at 10:30 +0300, Michael S. Tsirkin wrote:
> > > >
On Wed, 2014-10-01 at 12:48 -0600, Alex Williamson wrote:
> On Tue, 2014-09-30 at 19:38 +0300, Marcel Apfelbaum wrote:
> > Scanning a lot of devices during boot requires a lot of time.
> > On other scenarios there is a need to bind a driver to a specific slot.
> >
> >
On Wed, 2014-10-01 at 12:48 -0600, Alex Williamson wrote:
On Tue, 2014-09-30 at 19:38 +0300, Marcel Apfelbaum wrote:
Scanning a lot of devices during boot requires a lot of time.
On other scenarios there is a need to bind a driver to a specific slot.
Binding devices to pci-stub driver
On Thu, 2014-10-02 at 11:12 +0300, Michael S. Tsirkin wrote:
On Wed, Oct 01, 2014 at 12:51:03PM -0600, Alex Williamson wrote:
On Wed, 2014-10-01 at 10:50 +0300, Marcel Apfelbaum wrote:
On Wed, 2014-10-01 at 10:30 +0300, Michael S. Tsirkin wrote:
On Wed, Oct 01, 2014 at 10:06:46AM +0300
On Wed, 2014-10-01 at 10:30 +0300, Michael S. Tsirkin wrote:
> On Wed, Oct 01, 2014 at 10:06:46AM +0300, Marcel Apfelbaum wrote:
> > On Wed, 2014-10-01 at 09:52 +0300, Michael S. Tsirkin wrote:
> > > On Tue, Sep 30, 2014 at 07:38:35PM +0300, Marcel Apfelbaum wrote:
>
On Wed, 2014-10-01 at 09:52 +0300, Michael S. Tsirkin wrote:
> On Tue, Sep 30, 2014 at 07:38:35PM +0300, Marcel Apfelbaum wrote:
> > Scanning a lot of devices during boot requires a lot of time.
> > On other scenarios there is a need to bind a driver to a specific slot.
> >
On Wed, 2014-10-01 at 09:52 +0300, Michael S. Tsirkin wrote:
On Tue, Sep 30, 2014 at 07:38:35PM +0300, Marcel Apfelbaum wrote:
Scanning a lot of devices during boot requires a lot of time.
On other scenarios there is a need to bind a driver to a specific slot.
Binding devices to pci-stub
On Wed, 2014-10-01 at 10:30 +0300, Michael S. Tsirkin wrote:
On Wed, Oct 01, 2014 at 10:06:46AM +0300, Marcel Apfelbaum wrote:
On Wed, 2014-10-01 at 09:52 +0300, Michael S. Tsirkin wrote:
On Tue, Sep 30, 2014 at 07:38:35PM +0300, Marcel Apfelbaum wrote:
Scanning a lot of devices during
slot 0001:02:03.4 to pci-stub use:
driver[0001:02:03.4]=pci-stub
Signed-off-by: Marcel Apfelbaum
---
Notes:
- For the moment only 32 slots can be assigned specific driver.
- I have further ideas on top of this patch based on your reviews.
I thought of:
- Use wildcards to specify
In order to bind PCI slot 0001:02:03.4 to pci-stub use:
driver[0001:02:03.4]=pci-stub
Signed-off-by: Marcel Apfelbaum marce...@redhat.com
---
Notes:
- For the moment only 32 slots can be assigned specific driver.
- I have further ideas on top of this patch based on your reviews.
I
On Sun, 2014-05-04 at 16:48 +0300, Ronen Hod wrote:
> On 05/01/2014 05:35 PM, Marcel Apfelbaum wrote:
> > When a board is added, the shpchp driver checks if there
> > is a mismatch between the bridge's adapter and the bus speed.
> > If there is, it sets the subordinate speed (
On Thu, 2014-05-01 at 14:00 -0600, Bjorn Helgaas wrote:
> On Thu, May 1, 2014 at 12:57 PM, Marcel Apfelbaum
> wrote:
> > On Thu, 2014-05-01 at 21:13 +0300, Marcel Apfelbaum wrote:
> >> On Thu, 2014-05-01 at 12:02 -0600, Bjorn Helgaas wrote:
> >> > On Thu, May 1,
On Thu, 2014-05-01 at 14:00 -0600, Bjorn Helgaas wrote:
On Thu, May 1, 2014 at 12:57 PM, Marcel Apfelbaum
marcel.apfelb...@gmail.com wrote:
On Thu, 2014-05-01 at 21:13 +0300, Marcel Apfelbaum wrote:
On Thu, 2014-05-01 at 12:02 -0600, Bjorn Helgaas wrote:
On Thu, May 1, 2014 at 8:35 AM
On Sun, 2014-05-04 at 16:48 +0300, Ronen Hod wrote:
On 05/01/2014 05:35 PM, Marcel Apfelbaum wrote:
When a board is added, the shpchp driver checks if there
is a mismatch between the bridge's adapter and the bus speed.
If there is, it sets the subordinate speed (if there is no device
On Thu, 2014-05-01 at 14:00 -0600, Bjorn Helgaas wrote:
> On Thu, May 1, 2014 at 12:57 PM, Marcel Apfelbaum
> wrote:
> > On Thu, 2014-05-01 at 21:13 +0300, Marcel Apfelbaum wrote:
> >> On Thu, 2014-05-01 at 12:02 -0600, Bjorn Helgaas wrote:
> >> > On Thu, May 1,
On Thu, 2014-05-01 at 21:13 +0300, Marcel Apfelbaum wrote:
> On Thu, 2014-05-01 at 12:02 -0600, Bjorn Helgaas wrote:
> > On Thu, May 1, 2014 at 8:35 AM, Marcel Apfelbaum
> > wrote:
> > > When a board is added, the shpchp driver checks if there
> > > is a mism
On Thu, 2014-05-01 at 12:02 -0600, Bjorn Helgaas wrote:
> On Thu, May 1, 2014 at 8:35 AM, Marcel Apfelbaum wrote:
> > When a board is added, the shpchp driver checks if there
> > is a mismatch between the bridge's adapter and the bus speed.
> > If there is, it sets
. If the primary bus is PCI and not PCIX/PCIe,
its speed is not updated and remains 0xff. As a result hotplug fails
with error: "Speed of bus ff and adapter 0 mismatch".
Fixed that by checking the speed against the subordinate bus.
Signed-off-by: Marcel Apfelbaum
Acked-by: Michael
. If the primary bus is PCI and not PCIX/PCIe,
its speed is not updated and remains 0xff. As a result hotplug fails
with error: Speed of bus ff and adapter 0 mismatch.
Fixed that by checking the speed against the subordinate bus.
Signed-off-by: Marcel Apfelbaum marce...@redhat.com
Acked-by: Michael S
On Thu, 2014-05-01 at 12:02 -0600, Bjorn Helgaas wrote:
On Thu, May 1, 2014 at 8:35 AM, Marcel Apfelbaum marce...@redhat.com wrote:
When a board is added, the shpchp driver checks if there
is a mismatch between the bridge's adapter and the bus speed.
If there is, it sets the subordinate
On Thu, 2014-05-01 at 21:13 +0300, Marcel Apfelbaum wrote:
On Thu, 2014-05-01 at 12:02 -0600, Bjorn Helgaas wrote:
On Thu, May 1, 2014 at 8:35 AM, Marcel Apfelbaum marce...@redhat.com
wrote:
When a board is added, the shpchp driver checks if there
is a mismatch between the bridge's
On Thu, 2014-05-01 at 14:00 -0600, Bjorn Helgaas wrote:
On Thu, May 1, 2014 at 12:57 PM, Marcel Apfelbaum
marcel.apfelb...@gmail.com wrote:
On Thu, 2014-05-01 at 21:13 +0300, Marcel Apfelbaum wrote:
On Thu, 2014-05-01 at 12:02 -0600, Bjorn Helgaas wrote:
On Thu, May 1, 2014 at 8:35 AM
58 matches
Mail list logo
