On Mon, Oct 22, 2007 at 10:03:47PM +0200, Yakov Lerner wrote:
> I want to add my custom destructor to the skb, the function pointer
> to be called at skb destruction time. Will the following work: if I
> push address of my_destructor to the
> sk-buff->destructor field, and then when my_destructor
On Mon, Jul 09, 2007 at 12:06:40AM -0700, David Miller wrote:
> > That works, but isn't optimal when you have an isolation-capable
> > IOMMU and you want the full isolation properties of the IOMMU. If
> > you only flush the IOTLB when the allocator wraps around, a stale
> > entry in the IOTLB can
On Fri, Jul 06, 2007 at 12:20:19PM -0700, David Miller wrote:
> From: "Williams, Mitch A" <[EMAIL PROTECTED]>
> Date: Fri, 6 Jul 2007 10:14:56 -0700
>
> > In my opinion, IOMMU table locking is the major issue with this
> > type of architecture. Since both Intel and AMD are touting IOMMUs
> > for
On Fri, Jul 06, 2007 at 10:14:56AM -0700, Williams, Mitch A wrote:
> David Miller wrote:
> >> Okay, but then using SG lists makes skbuff's much bigger.
> >>
> >>fraglistscatterlistper skbuff
> >> 32 bit 8 20 +12 * 18 = +216!
> >> 64 bi
On Sun, May 13, 2007 at 08:27:35PM -0300, Arnaldo Carvalho de Melo wrote:
> Well, the fix is easy, can you provide a patch?
Sure, but I was hoping you had a follow-on patch to get rid of the
ugly ifdefs in .c files that would make it irrelevant? if not I'll
whip out the obvious patch.
Cheers,
Mu
On Fri, Apr 27, 2007 at 05:03:44PM +, Linux Kernel Mailing List wrote:
> Gitweb:
> http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4305b541357ddbd205aa145dc378926b7cb12283
> Commit: 4305b541357ddbd205aa145dc378926b7cb12283
> Parent: 27a884dc3cb63b93
On Sun, Apr 08, 2007 at 08:36:14AM +0300, Avi Kivity wrote:
> That is not the common case. Nor is it true when there is a
> mismatch between the card's capabilties and guest expectations and
> constraints. For example, guest memory is not physically contiguous
> so a NIC that won't do scatter/ga
On Tue, Mar 27, 2007 at 03:21:59PM +0200, Thomas Graf wrote:
> The results of FIB rules lookups are cached in the routing cache
> except for IPv6 as no such cache exists. So far, it was the
> responsibility of the user to flush the cache after modifying any
> rules. This lead to many false bug rep
On Thu, Dec 07, 2006 at 11:48:14AM +0530, Amit S. Kale wrote:
> On the x86_64 boxes that don't feature iommu functionality (because the
> motherboard disables it or because Linux can't handle it) Linux bounce buffer
> framework automatically comes into picture. Could we have the same framework
On Wed, Dec 06, 2006 at 10:16:44AM -0800, Stephen Hemminger wrote:
> I think it is really only an issue for drivers that turn on HIGH_DMA
> and have limited mask values. The majority of drivers either only
> handle 32 bit (!HIGH_DMA) or do full 64 bit mapping. I don't know
> the details of how we
On Mon, Dec 04, 2006 at 10:39:49AM -0800, Stephen Hemminger wrote:
> I notice that no current network driver handles dma mapping errors.
> Might that be part of the problem. On i386, this never happens, and
> it would be rare on most others.
IOMMUs are already available on x86-64 and are going t
On Sat, Aug 12, 2006 at 11:30:35AM +0200, Lennert Buytenhek wrote:
> Nope. Unfortunately, the line that made that clear didn't fall inside
> the patch context:
Ah, I see. Thanks.
Cheers,
Muli
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL
On Sat, Aug 12, 2006 at 10:55:07AM +0200, Lennert Buytenhek wrote:
> Enabling PXA DMA for the smc91x on the logicpd pxa270 produces
> unacceptable interference with the TFT panel, so disable it.
Doesn't this disable it for all users, though? are there any other
users? should this be changed from a
On Wed, Jun 07, 2006 at 10:29:50AM -0700, Stephen Hemminger wrote:
> Be careful about global namespace issues. Stick to one prefix like ehea_
> for all non static function names. Consider putting all in one file, or
> use #include to cause it to be one compilation unit.
I thought including .c fil
14 matches
Mail list logo
