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 can
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 are
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
#x27;s gid 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 10
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 ol
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 Apfelb
t; On 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
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
- Remo
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 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
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 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:
> &g
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.
> >
&
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
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 sp
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
> 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 mismatch
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 the s
e. 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: Mic
29 matches
Mail list logo
